This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Revision 2: Handle string constant initializers for array of char16_t or char32_t


On Tue, Apr 22, 2008 at 07:01:18PM +0000, Joseph S. Myers wrote:
> On Tue, 22 Apr 2008, Kris Van Hees wrote:
> 
> > On Tue, Apr 22, 2008 at 01:25:22PM -0400, Jakub Jelinek wrote:
> > > On Tue, Apr 22, 2008 at 01:09:48PM -0400, Kris Van Hees wrote:
> > > > According to the ISO/IEC JTC1 SC22 WG14 N1040 technical report for C (covering
> > > > the new character data types for char16_t and char32_t), typedefs are
> > > > introduced for char16_t and char32_t, which would imply that they are not
> > > > fundamental types in C.  On the other hand, ISO/IEC JTC1 SC22 WG21 N2249
> > > > specifically identifies char16_t and char32_t as fundamental types in C++.
> > > 
> > > Wouldn't it be desirable to predefine __CHAR16_TYPE__ and __CHAR32_TYPE__
> > > macros for C though, similarly how is c_stddef_cpp_builtins predefines
> > > __WCHAR_TYPE__ or __SIZE_TYPE__?
> > 
> > That is a very good point.  I'll do that.
> 
> These types should always be the same as __UINT_LEAST16_TYPE__ and 
> __UINT_LEAST32_TYPE__.  See PR 448 and discussions on the gcc list.  
> Since it may be a while before GCC has proper knowledge of all the 
> <stdint.h> types everywhere, defining __CHAR16_TYPE__ and __CHAR32_TYPE__ 
> (as well as eventually defining macros for everything in <stdint.h>) may 
> make sense.  However, please make clear in the documentation that the 
> choice of these types (among multiple types with the same precision, e.g. 
> unsigned int and unsigned long) is subject to change in order to agree 
> with <stdint.h> as required by the C TR, and as such they should not be 
> used in C++ interfaces (because of the effects on mangling); the 
> fundamental types char16_t and char32_t should be used in C++ instead.

The definition of the two macros for __CHAR16_TYPE__ and __CHAR32_TYPE__ is
definitely something that I'll send a patch for, but since that is not really
related to the patch this thread came out of, I'd like to suggest we do not
hold back this patch for that?  It seems to be two issues that are sufficiently
separate.

	Cheers,
	Kris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]