search for: wint_t

Hi, While installing libeidt in Ubuntu 12.0 I am getting the following message. I am not even able to edit the curses.h and stddef.h file. Kindly help. /usr/lib/gcc/i686-linux-gnu/4.6/include/stddef.h:353:23: error: conflicting types for 'wint_t' /usr/include/curses.h:241:18: note: previous declaration of 'wint_t' was here make[3]: *** [terminal.lo] Error 1 make[3]: Leaving directory `/home/egguser/fmbt/fmbt-0.11.2-1/libedit-20130712-3.1/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/egguser/fmbt/fmbt-0.1...

.../ glibc compatibility issues people have been having with 3.4: r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER is defined) r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, wint_t}. The changes look safe to merge but I'd like to hear a second opinion from Chandler or Nico. Alp. -- http://www.nuanti.com the browser experts

...r/include/asterisk/channel.h:34, from chan_capi.c:16: /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/stddef.h:325: error: storage class specified for parameter `wchar_t'/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/stddef.h:354: error:storage class specified for parameter `wint_t'In file included from /usr/include/_G_config.h:24, from /usr/include/libio.h:32, from /usr/include/stdio.h:72, from /usr/include/asterisk/monitor.h:4, from /usr/include/asterisk/channel.h:34, from chan_capi.c:1...

...s.m4: Likewise. * m4/po.m4: Likewise. * m4/printf-posix.m4: Likewise. * m4/progtest.m4: Likewise. * m4/signed.m4: Likewise. * m4/size_max.m4: Likewise. * m4/stdint_h.m4: Likewise. * m4/uintmax_t.m4: Likewise. * m4/ulonglong.m4: Likewise. * m4/visibility.m4: Likewise. * m4/wchar_t.m4: Likewise. * m4/wint_t.m4: Likewise. * m4/xsize.m4: Likewise. --- m4/.gitignore | 27 +++ m4/codeset.m4 | 23 --- m4/gettext.m4 | 487 ---------------------------------------------- m4/glibc2.m4 | 30 --- m4/glibc21.m4 | 32 --- m4/iconv.m4 | 103 ---------- m4/intdiv0.m4...

...aving with 3.4: >> >> r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) >> r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER >> is defined) >> r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, >> wint_t}. >> >> The changes look safe to merge but I'd like to hear a second opinion from >> Chandler or Nico. >> > > I believe all of these are very safe, but I respect Tom's position here. > As he is managing the release, he gets to say "not in this one"...

...re self-inflicted. But would be good to know what environment you are using. Thanks for looking - and finding!!! Michael >> On 01 Jan 2016, at 22:06 , Simon Urbanek<simon.urbanek at r-project.org> wrote: >> >> Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it wor...

...16-bits - but I remember when short was meant to help when moving from 16-bit to 32-bit and the "word" size changed - i.e., int became 32-bit same as long. nd for a long (no pun intended) long was 32-bit and long long was 64-bit. Those definitions are extinct. imho - the standard for wint_t is wrong as well - based on an assumption about how "short" is defined. And, I consider it poor practice that there are som many cases of type cast switches between ushort and int. Michael On 04-Jan-16 01:26, Simon Urbanek wrote: > Michael, > > I'm using xlc + xlf - the e...

...-bit and long long was 64-bit. Those definitions are extinct. > I'm not sure what you refer here - the issue with TRE has nothing to do with short - it can take any int type and like I said most platforms use unsigned int which is big enough on all platforms. > imho - the standard for wint_t is wrong as well - based on an assumption about how "short" is defined. And, I consider it poor practice that there are som many cases of type cast switches between ushort and int. > Not really - it doesn't care about short at all - note that the short typedef is never actually u...

Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it wor...

...++_r F77=xlf_r FC=xlf95_r LIBS='-L/opt/freeware/lib /opt/freeware/lib/libiconv.a -lpthread' --prefix=/opt/freeware CPPFLAGS=-I/opt/freeware/include with export OBJECT_MODE=64 in the env (and libiconv from perzl.org RPMs - iconv is a serious pain). I have changed the TRE typedef from "wint_t" to "unsigned int" since that is what the other platforms use anyway. On my AIX7 VM I'm running out of memory in xz when lazy-loading is enabled which his odd - the VM has 4Gb which one would think should be enough. The symptom is that installing MASS fails when creating lazy-lo...

...tre-internal.h R-3.2.3.1/src/extra/tre/tre-internal.h --- R-3.2.3.dist/src/extra/tre/tre-internal.h 2014-06-13 22:15:07.000000000 +0000 +++ R-3.2.3.1/src/extra/tre/tre-internal.h 2016-01-03 16:08:31.000000000 +0000 @@ -47,7 +47,7 @@ #ifdef TRE_WCHAR /* Wide characters. */ - typedef wint_t tre_cint_t; + typedef uint16_t tre_cint_t; #define TRE_CHAR_MAX WCHAR_MAX #ifdef TRE_MULTIBYTE @@ -78,7 +78,7 @@ #else /* !TRE_WCHAR */ /* 8 bit characters. */ - typedef short tre_cint_t; + typedef uint16_t tre_cint_t; #define TRE_CHAR_MAX 255 #define TRE_MB_CUR_MAX 1 @@ -118,7...

...ng to provide ::max_align_t in C11 and > > C++11 modes) > > r202911: Headers: Provide an ABI compatible max_align_t when > > _MSC_VER is defined) > > r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, > > ptrdiff_t, wint_t}. > > > > The changes look safe to merge but I'd like to hear a second > > opinion from Chandler or Nico. > > > > > > I believe all of these are very safe, but I respect Tom's position > > here. As he is managing the release,...

Nice catch you two!!! Happy New Year -pd > On 01 Jan 2016, at 22:06 , Simon Urbanek <simon.urbanek at r-project.org> wrote: > > Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it wor...

...from /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/errno.h:116, from ../../../../../newlib-1.16.0/newlib/libc/argz/argz_add.c:7: /usr/src/xen-3.3.0/stubdom/newlib-1.16.0/newlib/libc/include/sys/_types.h:76: erreur: expected specifier-qualifier-list before ''wint_t '' In file included from /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/posix/time.h:6, from /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/mini-os/time.h:52, from /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/mini-os/sched.h:5,...

On 02/05/2014 20:45, Tuncer Ayaz wrote: > Bump. > > Is it really unsupported to build llvm from scratch with gcc 4.9 and > libstdc++ 4.9? Should I file a bugzilla ticket instead? Obviously LLVM/clang should compile out of the box using the current stable GCC version, and failure to do so would be a potential release blocker. Please file a PR Tom, do you know about this issue? Alp.

....m4 /unistd_h.m4 /unistd-safer.m4 @@ -261,7 +227,6 @@ /unlinkdir.m4 /unlink.m4 /usleep.m4 -/utimbuf.m4 /utimecmp.m4 /utime_h.m4 /utime.m4 @@ -276,20 +241,16 @@ /warnings.m4 /warn-on-use.m4 /wchar_h.m4 -/wchar.m4 /wchar_t.m4 /wcrtomb.m4 /wctob.m4 /wctomb.m4 /wctype_h.m4 -/wctype.m4 /wint_t.m4 /write.m4 /xalloc.m4 /xgetcwd.m4 /xsize.m4 -/xstrndup.m4 -/xstrtol.m4 /xstrtol.m4 /xvasprintf.m4 /yield.m4 -- 2.21.0

Hi, I am using Winelib and no mfc to get a company app to run on Linux. It is a cuiexe as well. However, I get a lot of errors when I include <msvcrt/io.h>. e.g., /usr/include/wine/msvcrt/stdio.h:66: syntax error before '(' This line is: typedef struct MSVCRT(_iobuf) Is it possible to do this with C/C++? I am assuming it is a Windows thing. My version of wine is:

...t;> > >> I'm not sure what you refer here - the issue with TRE has nothing to >> do with short - it can take any int type and like I said most >> platforms use unsigned int which is big enough on all platforms. >> >> >>> >imho - the standard for wint_t is wrong as well - based on an >>> assumption about how "short" is defined. And, I consider it poor >>> practice that there are som many cases of type cast switches between >>> ushort and int. >>> > >> Not really - it doesn't care about...

Quite a complex fix in the end, see the comment in the second commit. Rich.

...t; /usleep.m4 > -/utimbuf.m4 > /utimecmp.m4 > /utime_h.m4 > /utime.m4 > @@ -276,20 +241,16 @@ > /warnings.m4 > /warn-on-use.m4 > /wchar_h.m4 > -/wchar.m4 > /wchar_t.m4 > /wcrtomb.m4 > /wctob.m4 > /wctomb.m4 > /wctype_h.m4 > -/wctype.m4 > /wint_t.m4 > /write.m4 > /xalloc.m4 > /xgetcwd.m4 > /xsize.m4 > -/xstrndup.m4 > -/xstrtol.m4 > /xstrtol.m4 > /xvasprintf.m4 > /yield.m4 > -- > 2.21.0 > > _______________________________________________ > Libguestfs mailing list > Libguestfs@redhat.com &...