[LLVMdev] DataTypes.h for Visual C

[Óscar Fuentes]

[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 ...
>
> #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?

>>> 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.