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 3: Handle string constant initializers for arrays of char16_t or char32_t


Quick comment on the patch (forgot to mention)... a few of the included
tests are *not* making use of the __CHAR(16|32)_TYPE__ macros, while they
really could.  That was a deliberate choice, because I am planning a
followup patch to correct exactly that in all previous test cases I added
with the char16/32_t patches.  I figured it is cleaner to do all tests in
a single patch, rather than three here, and then a few more later.

	Kris

On Tue, Jul 15, 2008 at 07:30:16PM -0400, Kris Van Hees wrote:
> Oracle has a full copyright assignment in place with the FSF.
> 
> This patch addresses the problem reported by Holger Hopp and Jakub Jelinek:
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01444.html
> 	http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01454.html
> 
> and the first review sparking this revision:
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01553.html
> 
> This patch replaces the second version.  It addresses the problem that the
> char16_t/char32_t support failed to ensure that the use of string constant
> initializers for arrays of char16_t and char32_t were handled correctly,
> both in C and C++.  It also addresses the feedback Joseph Myers concerning
> incremental initializers.  In addition, it ensures that the char16_t/char32_t
> typeinfo is included in the standard C++ library.  Finally, it implements the
> definition of __CHAR16_TYPE__ and __CHAR32_TYPE__ macros.  These macros are
> meant to provide the underlying type that is used for the char16_t and char32_t
> types.
> 
> The fix for the incremental initializer handling removes a gcc_assert for
> the bitsize of the elements in the initializer string constant.  This is
> safe and correct, because with char16_t and char32_t added in, non-char
> doesn't mean wchar_t anymore.  It is safe to not have the assert there,
> because other code earlier in the code paths leading here ensures that the
> string constant is of the right type.
> 
> The problems don't seem to be logged in bugzilla as bugs, hence the lack of
> reference to bugzilla bug ids.

<< truncated >>


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