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>
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 github of the documented names will find uses. Where exactly is the conflict happening? Is the problem that something in llvm is including windows.h? Or that some std lib C/C++ header is being included and the OS provided std header is including windows.h? -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/a911cb65/attachment.html>
Right now, we have:
In COFF.h:
class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0,
... }; };
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 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 github of the documented names will
> find uses.
>
> Where exactly is the conflict happening? Is the problem that something
> in llvm is including windows.h? Or that some std lib C/C++ header is being
> included and the OS provided std header is including windows.h?
>
> -Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/46b0908a/attachment.html>