Hello,
I noticed that if include\llvm\Support is included alongside Windows.h,
there will be many define conflict leading to compilation errors, such as:
COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ...
};
and
winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0
Of course I could try to avoid to include both (but it's rather difficult
and would require lot of refactoring -- we have this clash currently in
LLDB MinGW32 port).
I was wondering if instead it was possible to simply rename those enum
little bit differently in COFF.h so that it doesn't clash?
I know windows.h is quite invasive, so maybe it's better not try to collide
with any of its weird define.
If that makes sense I'm fine with doing the patch.
If yes, feel free to propose an alternative naming prefix or scheme.
Note that if tools depend on COFFDumper::printFileHeaders output, it might
still need to print as it was before -- so the easiest choice might be to
maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't
matter). Is it important?
Thanks,
Virgile
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/7ac44c8f/attachment.html>
IMO the fact that it uses the standard names from the COFF documentation is a feature, not a bug. The elf and macho headers in the same directory use the standard enumeration names, correct? On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote:> Hello, > > I noticed that if include\llvm\Support is included alongside Windows.h, > there will be many define conflict leading to compilation errors, such as: > > COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... > }; > > and > > winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > Of course I could try to avoid to include both (but it's rather difficult > and would require lot of refactoring -- we have this clash currently in > LLDB MinGW32 port). > I was wondering if instead it was possible to simply rename those enum > little bit differently in COFF.h so that it doesn't clash? > I know windows.h is quite invasive, so maybe it's better not try to > collide with any of its weird define. > > If that makes sense I'm fine with doing the patch. > If yes, feel free to propose an alternative naming prefix or scheme. > > Note that if tools depend on COFFDumper::printFileHeaders output, it might > still need to print as it was before -- so the easiest choice might be to > maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't > matter). Is it important? > > Thanks, > Virgile > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130827/24ab9a79/attachment.html>
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 macho headers in the same directory use the standard > enumeration names, correct? > > > On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > >> Hello, >> >> I noticed that if include\llvm\Support is included alongside Windows.h, >> there will be many define conflict leading to compilation errors, such as: >> >> COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, >> ... }; >> >> and >> >> winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> Of course I could try to avoid to include both (but it's rather difficult >> and would require lot of refactoring -- we have this clash currently in >> LLDB MinGW32 port). >> I was wondering if instead it was possible to simply rename those enum >> little bit differently in COFF.h so that it doesn't clash? >> I know windows.h is quite invasive, so maybe it's better not try to >> collide with any of its weird define. >> >> If that makes sense I'm fine with doing the patch. >> If yes, feel free to propose an alternative naming prefix or scheme. >> >> Note that if tools depend on COFFDumper::printFileHeaders output, it >> might still need to print as it was before -- so the easiest choice might >> be to maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't >> matter). Is it important? >> >> Thanks, >> Virgile >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/f6eea1aa/attachment.html>
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.