Hi! In DataTypes.h (generated from DataTypes.cmake) there is an extra code path for Visual C. This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. since other headers may also define them. Therefore please protect the macros like INT8_C etc. Also it would be nice if the auto-generated HAVE_STDINT_H and HAVE_INTTYPES_H would be used also for Visual C since it is possible to add them to the global header directory (e.g. http://msinttypes.googlecode.com/svn/trunk) -Jochen
Jochen Wilhelmy <j.wilhelmy at arcor.de> writes:> In DataTypes.h (generated from DataTypes.cmake) there is an extra > code path for Visual C.What's that extra code path?> This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. > since other headers may also define them. Therefore please > protect the macros like INT8_C etc. > > Also it would be nice if the auto-generated HAVE_STDINT_H > and HAVE_INTTYPES_H would be used also for Visual C since it > is possible to add them to the global header directory > (e.g. http://msinttypes.googlecode.com/svn/trunk)This can be done, but I have some reservations about it. My experience with those files which are provided by third parties for acting as system headers are left forgotten somewhere on the system, or installed by some piece of code without notice, and then some package such as LLVM tests for their presence and uses them, much grief and pain may follow.
[please CC the llvm mailing list] Jochen Wilhelmy <j.wilhelmy at arcor.de> writes:>> What's that extra code path? >> > > #ifndef _MSC_VER > ... > #else /* _MSC_VER */ > /* Visual C++ doesn't provide standard integer headers, but it does provide > built-in data types. */ > > ... extra code path ... > > #endifSorry, that doesn't show an extra code path. DataTypes.h contains stuff specific for MSVC and stuff for the rest of compilers. The #ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef?>>> This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. >>> since other headers may also define them. Therefore please >>> protect the macros like INT8_C etc. >>> >>> Also it would be nice if the auto-generated HAVE_STDINT_H >>> and HAVE_INTTYPES_H would be used also for Visual C since it >>> is possible to add them to the global header directory >>> (e.g. http://msinttypes.googlecode.com/svn/trunk) >>> >> This can be done, but I have some reservations about it. >> >> My experience with those files which are provided by third parties for >> acting as system headers are left forgotten somewhere on the system, or >> installed by some piece of code without notice, and then some package >> such as LLVM tests for their presence and uses them, much grief and pain >> may follow. >> > > OK I understand this but then please at least protect the #defines > since other libs also may define > them when they assume the absence of stdint.h. > > Perhaps you could provide a variable that forces the use of stdint.h > and inttypes.h and then I can > define this on the command line. With this solution the user is > responsible for having working > 3rd party headers.Adding just another config option (and one that is speficic of one compiler) seems overkill to me and would constitute a precedent for similar cases on the future. I try to keep the config option list as short as possible. Protecting the defines, OTOH, is okay.
>>> What's that extra code path? >>> >>> >> #ifndef _MSC_VER >> ... >> #else /* _MSC_VER */ >> /* Visual C++ doesn't provide standard integer headers, but it does provide >> built-in data types. */ >> >> ... extra code path ... >> >> #endif >> > Sorry, that doesn't show an extra code path. DataTypes.h contains stuff > specific for MSVC and stuff for the rest of compilers. The > #ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef? >I just wanted to show you what I mean by the extra code path (the compiler takes one part of code or another dependent on a define), but obviously you don't call it code path. How do you call it?> Adding just another config option (and one that is speficic of one > compiler) seems overkill to me and would constitute a precedent for > similar cases on the future. I try to keep the config option list as > short as possible. > > Protecting the defines, OTOH, is okay. >Yes, protecting the defines will be enough. - Jochen