search for: machintypes

...; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will become: enum MachinTypes { 0 = 0x0 }; On Thu, Aug 29, 2013 at 6:03 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> > wrote: > > Yes of course I understand it was done on purpose. > It's just that it makes it impo...

...ACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will become: > enum MachinTypes { 0 = 0x0 }; Sorry, I was not clear. Why is Windows.h being included at all? That header does not exist on some OS’s so the code would not build be portable. If this use is in the one or two files of llvm that implement platform support, why is COFF.h being included in those instances? -Nick...

...INE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include Windows.h and then COFF.h, COFF.h won't work > because it's enum will become: > enum MachinTypes { 0 = 0x0 }; > > Sorry, I was not clear. Why is Windows.h being included at all? That > header does not exist on some OS’s so the code would not build be portable. > If this use is in the one or two files of llvm that implement platform > support, why is COFF.h being included in t...

...gt; * If you first include COFF.h and then windows.h, >> COFF::IMAGE_FILE_MACHINE_UNKNOWN >> will be preprocessed into >> COFF:0. >> >> * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will become: >> enum MachinTypes { 0 = 0x0 }; > Sorry, I was not clear. Why is Windows.h being included at all? That header does not exist on some OS’s so the code would not build be portable. If this use is in the one or two files of llvm that implement platform support, why is COFF.h being included in those instances? >...

...COFF.h and then windows.h, >>> COFF::IMAGE_FILE_MACHINE_UNKNOWN >>> will be preprocessed into >>> COFF:0. >>> >>> * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will become: >>> enum MachinTypes { 0 = 0x0 }; >>> >> Sorry, I was not clear. Why is Windows.h being included at all? That header does not exist on some OS’s so the code would not build be portable. If this use is in the one or two files of llvm that implement platform support, why is COFF.h being included...

On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Yes of course I understand it was done on purpose. > It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). I too am in the camp that it is a feature to use the standard names. For instance doing a search it google or

Yes of course I understand it was done on purpose. It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). On Wed, Aug 28, 2013 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote: > IMO the fact that it uses the standard names from the COFF documentation > is a feature, not a bug. > > The elf and