Reid Kleckner <rnk at google.com> writes:> IMO the fact that it uses the standard names from the COFF > documentation is a feature, not a bug.*defining* (not *using*) symbols already defined on a platform header is definitely a bug.
On Wed, Aug 28, 2013 at 2:43 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:> Reid Kleckner <rnk at google.com> writes: > > > IMO the fact that it uses the standard names from the COFF > > documentation is a feature, not a bug. > > *defining* (not *using*) symbols already defined on a platform header is > definitely a bug.We have to provide definitions so that we can produce COFF on platforms that do not have winnt.h. Ours are nicely namespaced under ::llvm::, but winnt's are global macros, which is crummy. That said, I don't actually feel strongly about this. It would be nice if Support/ELF.h, COFF.h, and MachO.h all provided the enums named in their respective specifications, but if you send a patch to remove the IMAGE_ prefix, it's probably for the best. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/e4414b14/attachment.html>
Reid Kleckner <rnk at google.com> writes:> We have to provide definitions so that we can produce COFF on platforms > that do not have winnt.h.Surely there is no need to use the exact same names.> Ours are nicely namespaced under ::llvm::, but > winnt's are global macros, which is crummy.Windows headers do terrible things, but some of those atrocities are there because they must work for C too.> That said, I don't actually feel strongly about this. It would be nice if > Support/ELF.h, COFF.h, and MachO.h all provided the enums named in their > respective specifications, but if you send a patch to remove the IMAGE_ > prefix, it's probably for the best.For the case where no winnt.h is included the names could be defined: #ifndef IMAGE_whatever #define IMAGE_whatever ... I'm not sure that putting those COFF names as enums in a namespace is a good idea, because someone could use them as such and that would break on Windows. #defining then duplicates the crumminess and hence is the safe option, IMHO. Just a suggestion to the OP who volunteered to provide a patch. I have no official saying on this issue.