| Message ID | 1477568774-4817-1-git-send-email-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 27 October 2016 at 12:46, Gerd Hoffmann <kraxel@redhat.com> wrote: > --- > ui/Makefile.objs | 3 +++ > 1 file changed, 3 insertions(+) Missing commit message and signed-off-by line... > diff --git a/ui/Makefile.objs b/ui/Makefile.objs > index dc936f1..62f4cf3 100644 > --- a/ui/Makefile.objs > +++ b/ui/Makefile.objs > @@ -17,6 +17,9 @@ common-obj-$(CONFIG_CURSES) += curses.o > common-obj-$(CONFIG_VNC) += $(vnc-obj-y) > common-obj-$(CONFIG_GTK) += gtk.o x_keymap.o > > +# needed to make gcc accept wide unicode chars without warning > +curses.o-cflags := -std=gnu99 > + > ifeq ($(CONFIG_SDLABI),1.2) > sdl.mo-objs := sdl.o sdl_zoom.o > endif > -- > 1.8.3.1 I'm not sure about this. Do we really want gnu99 and not c99? Should we just enable std=c99 for all source files, given that we already assume C99 anyway? It would also be helpful if the commit message quoted the compiler warning that you get otherwise, so it's easier to see why we're doing this. thanks -- PMM
Hi, > > +# needed to make gcc accept wide unicode chars without warning > > +curses.o-cflags := -std=gnu99 > > + > > ifeq ($(CONFIG_SDLABI),1.2) > > sdl.mo-objs := sdl.o sdl_zoom.o > > endif > > -- > > 1.8.3.1 > > I'm not sure about this. > > Do we really want gnu99 and not c99? Should we just enable > std=c99 for all source files, given that we already assume > C99 anyway? -std=c99 doesn't fly, throws errors on (gcc-specific) asm. So we have to use -std=gnu99. Tried to do that tree-wide by patching configure but got build errors then (somewhere in iscsi code). > It would also be helpful if the commit message quoted the > compiler warning that you get otherwise, so it's easier > to see why we're doing this. With the wide char curses patches by samuel applied I get errors like this one: /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal character names are only valid in C++ and C99 [-Werror] case L'\u23bd': ^ I'm open to better ideas to handle this. Failing that I can cut+paste this reply into the commit message to clarify things. cheers, Gerd
Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: > /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal > character names are only valid in C++ and C99 [-Werror] > case L'\u23bd': Another way could be to assume unicode encoding of wchar_t characters (which looks very reasonable to me) and just write "case 0x23bd:". Samuel
On 27 October 2016 at 16:58, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: >> /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal >> character names are only valid in C++ and C99 [-Werror] >> case L'\u23bd': > > Another way could be to assume unicode encoding of wchar_t characters > (which looks very reasonable to me) and just write "case 0x23bd:". Does this still work if you're using curses on mingw32? thanks -- PMM
Peter Maydell, on Thu 27 Oct 2016 17:14:52 +0100, wrote: > On 27 October 2016 at 16:58, Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: > >> /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal > >> character names are only valid in C++ and C99 [-Werror] > >> case L'\u23bd': > > > > Another way could be to assume unicode encoding of wchar_t characters > > (which looks very reasonable to me) and just write "case 0x23bd:". > > Does this still work if you're using curses on mingw32? Windows' wchar_t uses unicode encoding, yes (and its limitation to 16bit doesn't pose problem to the values we care about). Samuel
On 27 October 2016 at 17:36, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Peter Maydell, on Thu 27 Oct 2016 17:14:52 +0100, wrote: >> On 27 October 2016 at 16:58, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> > Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: >> >> /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal >> >> character names are only valid in C++ and C99 [-Werror] >> >> case L'\u23bd': >> > >> > Another way could be to assume unicode encoding of wchar_t characters >> > (which looks very reasonable to me) and just write "case 0x23bd:". >> >> Does this still work if you're using curses on mingw32? > > Windows' wchar_t uses unicode encoding, yes (and its limitation to 16bit > doesn't pose problem to the values we care about). On the other hand apparently FreeBSD and Solaris have a wchar_t whose encoding is locale-dependent: http://www.thecodingforums.com/threads/wchar_t-is-useless.806149/#post-4398211 thanks -- PMM
Peter Maydell, on Thu 27 Oct 2016 17:52:17 +0100, wrote: > On 27 October 2016 at 17:36, Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Peter Maydell, on Thu 27 Oct 2016 17:14:52 +0100, wrote: > >> On 27 October 2016 at 16:58, Samuel Thibault <samuel.thibault@gnu.org> wrote: > >> > Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: > >> >> /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal > >> >> character names are only valid in C++ and C99 [-Werror] > >> >> case L'\u23bd': > >> > > >> > Another way could be to assume unicode encoding of wchar_t characters > >> > (which looks very reasonable to me) and just write "case 0x23bd:". > >> > >> Does this still work if you're using curses on mingw32? > > > > Windows' wchar_t uses unicode encoding, yes (and its limitation to 16bit > > doesn't pose problem to the values we care about). > > On the other hand apparently FreeBSD and Solaris have a wchar_t > whose encoding is locale-dependent: > > http://www.thecodingforums.com/threads/wchar_t-is-useless.806149/#post-4398211 UURrgll... So we can't use L'\u23bd' on such systems, it would just not work either, we have to use iconv to get these right... Samuel
Samuel Thibault <samuel.thibault@gnu.org> writes: > Peter Maydell, on Thu 27 Oct 2016 17:52:17 +0100, wrote: >> On 27 October 2016 at 17:36, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> > Peter Maydell, on Thu 27 Oct 2016 17:14:52 +0100, wrote: >> >> On 27 October 2016 at 16:58, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> >> > Gerd Hoffmann, on Thu 27 Oct 2016 17:55:47 +0200, wrote: >> >> >> /home/kraxel/projects/qemu/ui/curses.c:627:18: error: universal >> >> >> character names are only valid in C++ and C99 [-Werror] >> >> >> case L'\u23bd': >> >> > >> >> > Another way could be to assume unicode encoding of wchar_t characters >> >> > (which looks very reasonable to me) and just write "case 0x23bd:". >> >> >> >> Does this still work if you're using curses on mingw32? >> > >> > Windows' wchar_t uses unicode encoding, yes (and its limitation to 16bit >> > doesn't pose problem to the values we care about). >> >> On the other hand apparently FreeBSD and Solaris have a wchar_t >> whose encoding is locale-dependent: >> >> http://www.thecodingforums.com/threads/wchar_t-is-useless.806149/#post-4398211 > > UURrgll... So we can't use L'\u23bd' on such systems, it would just not > work either, we have to use iconv to get these right... I guess we can if they actually bother to conform to C99. 6.4.3 Universal character names: The universal character name \Unnnnnnnn designates the character whose eight-digit short identifier (as specified by ISO/IEC 10646) is nnnnnnnn. Similarly, the universal character name \unnnn designates the character whose four-digit short identifier is nnnn (and whose eight-digit short identifier is 0000nnnn). Note that it doesn't say here that L'\u23bd' should be equal to 0x23bd.
Markus Armbruster, on Fri 28 Oct 2016 08:51:20 +0200, wrote: > Samuel Thibault <samuel.thibault@gnu.org> writes: > > > Peter Maydell, on Thu 27 Oct 2016 17:52:17 +0100, wrote: > >> http://www.thecodingforums.com/threads/wchar_t-is-useless.806149/#post-4398211 > > > > UURrgll... So we can't use L'\u23bd' on such systems, it would just not > > work either, we have to use iconv to get these right... > > I guess we can if they actually bother to conform to C99. 6.4.3 > Universal character names: > > The universal character name \Unnnnnnnn designates the character > whose eight-digit short identifier (as specified by ISO/IEC 10646) > is nnnnnnnn. Similarly, the universal character name \unnnn > designates the character whose four-digit short identifier is nnnn > (and whose eight-digit short identifier is 0000nnnn). > > Note that it doesn't say here that L'\u23bd' should be equal to 0x23bd. I know, but as discussed in the thread, that could only work if gcc embeds something like calls to nl_langinfo and iconv to properly convert from the unicode value to the proper wchar_t according to the locale. I wouldn't be surprised that they don't. Samuel
Samuel Thibault <samuel.thibault@gnu.org> writes: > Markus Armbruster, on Fri 28 Oct 2016 08:51:20 +0200, wrote: >> Samuel Thibault <samuel.thibault@gnu.org> writes: >> >> > Peter Maydell, on Thu 27 Oct 2016 17:52:17 +0100, wrote: >> >> http://www.thecodingforums.com/threads/wchar_t-is-useless.806149/#post-4398211 >> > >> > UURrgll... So we can't use L'\u23bd' on such systems, it would just not >> > work either, we have to use iconv to get these right... >> >> I guess we can if they actually bother to conform to C99. 6.4.3 >> Universal character names: >> >> The universal character name \Unnnnnnnn designates the character >> whose eight-digit short identifier (as specified by ISO/IEC 10646) >> is nnnnnnnn. Similarly, the universal character name \unnnn >> designates the character whose four-digit short identifier is nnnn >> (and whose eight-digit short identifier is 0000nnnn). >> >> Note that it doesn't say here that L'\u23bd' should be equal to 0x23bd. > > I know, but as discussed in the thread, that could only work if gcc > embeds something like calls to nl_langinfo and iconv to properly convert > from the unicode value to the proper wchar_t according to the locale. I > wouldn't be surprised that they don't. Before we uglify our code to work around (egregious!) defects in certain compilers, we should find out whether and where exactly these defects exist, and whether it's worth targeting the defective compilers.
Hi, > Before we uglify our code to work around (egregious!) defects in certain > compilers, we should find out whether and where exactly these defects > exist, and whether it's worth targeting the defective compilers. Using iconv is on the table _anyway_, to properly support "-display curses,charset=$something", so using that for the cp437 table too actually simplifies things and avoids hard-coding tables using \uxxxx as side effect. cheers, Gerd
diff --git a/ui/Makefile.objs b/ui/Makefile.objs index dc936f1..62f4cf3 100644 --- a/ui/Makefile.objs +++ b/ui/Makefile.objs @@ -17,6 +17,9 @@ common-obj-$(CONFIG_CURSES) += curses.o common-obj-$(CONFIG_VNC) += $(vnc-obj-y) common-obj-$(CONFIG_GTK) += gtk.o x_keymap.o +# needed to make gcc accept wide unicode chars without warning +curses.o-cflags := -std=gnu99 + ifeq ($(CONFIG_SDLABI),1.2) sdl.mo-objs := sdl.o sdl_zoom.o endif