After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 555576 - name clash in fileinfo.h with winbase.h from VS2005
name clash in fileinfo.h with winbase.h from VS2005
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: giomm
unspecified
Other Windows
: Normal minor
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2008-10-08 16:49 UTC by Julien Langer
Modified: 2008-10-10 22:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.30 KB, patch)
2008-10-09 10:22 UTC, Armin Burgmeier
committed Details | Review

Description Julien Langer 2008-10-08 16:49:29 UTC
Hi,

in giomm2.4/fileinfo.h line 53 there's the following enum:
enum FileType
{
   FILE_TYPE_UNKNOWN,
   ...
};

the FILE_TYPE_UNKNOWN unfortunately clashes with a macro using the same name from winbase.h:800 (shipped with Visual Studio 2005)
Comment 1 Armin Burgmeier 2008-10-09 10:22:03 UTC
Created attachment 120257 [details] [review]
Proposed patch

This patch renames the enum value to FILE_TYPE_NOT_KNOWN, but keeps the old value if it is not already defined for compatibility.
Comment 2 Jonathon Jongsma 2008-10-09 10:48:20 UTC
Nice, I wasn't aware of that search/replace trick in _WRAP_ENUM.  

I wonder how many of these sorts of conflicts we're going to run into.  Are we sure that FILE_TYPE_NOT_KNOWN is not going to conflict with some other header?  I'm a little reluctant to change too many of these names for every broken header that #defines a common symbol without a namespace, but I guess this is a pretty important one...
Comment 3 Armin Burgmeier 2008-10-09 11:00:04 UTC
> Are we sure that FILE_TYPE_NOT_KNOWN is not going to conflict with some other header?

It works on Windows when including both windows.h and giomm.h (which is what I tested). codesearch.google.com suggests that FILE_TYPE_NOT_KNOWN is only used in a single other project, and is properly namespaced there. Although that's not a guarantee, it's still a good hint that we are rather safe with FILE_TYPE_NOT_KNOWN.
Comment 4 Jonathon Jongsma 2008-10-09 11:27:36 UTC
OK, so in order to get it to work on windows, the user will still need to #undef FILE_TYPE_UNKNOWN, right?  Because you didn't remove that symbol.  Do we want to add a workaround like the one I added to error.hg? (save and undefine the symbol at the beginning of the header and restore it at the end so that the program will at least compile?)
Comment 5 Armin Burgmeier 2008-10-09 11:40:21 UTC
With the attached patch, it compiles on Windows without further action such as #undef FILE_TYPE_UNKNOWN. I did remove it from the enumeration by telling _WRAP_ENUM to replace it with FILE_TYPE_NOT_KNOWN.

Below the enumeration, FILE_TYPE_UNKNOWN is created again for compatibility, but only if FILE_TYPE_UNKNOWN is not already defined.
Comment 6 Murray Cumming 2008-10-09 16:18:49 UTC
The patch looks good to me. Please commit if Jonathan has no objections.
Comment 7 Armin Burgmeier 2008-10-10 22:06:35 UTC
Patch committed:

2008-10-09  Armin Burgmeier  <armin@openismus.com>

        * gio/src/fileinfo.hg: Rename FILE_TYPE_UNKNOWN to FILE_TYPE_NOT_KNOWN
        because the former is a #define on Windows in winbase.h, included from
        windows.h. Keep FILE_TYPE_UNKNOWN for compatibility if it is not
        already defined.