Re: [PATCH] stdint: port intptr_t to more-recent MinGW

Following up on this patch, here's a brief explanation. In we were battling with a problem building Emacs under 32-bit MinGW. The problem was that Gnulib stdint.in.h did this: # if !((defined __KLIBC__ && defined _INTPTR_T_DECLARED) \ || (defined __MINGW32__ &&

Re: /*unsigned*/ int level3 in gen-uni-tables.c

* Bruno Haible: >> This kind of narrowing initialization is no longer valid C++. > > Indeed, GCC 10.2.0 and clang give errors about this code when uses as C++ > code: > > $ gcc -Wall -O -S -x c++ foo.c > foo.c:156:1: error: narrowing conversion of '4294967295' from 'unsigned int' > to 'int'

[PATCH] stdint: port intptr_t to more-recent MinGW

Problem reported by Eli Zaretskii in . * lib/stdint.in.h (intptr_t, uintptr_t): Do not define on MinGW, even if _INTPTR_T_DEFINED and _UINTPTR_T_DEFINED are not defined. Apparently those two macros were removed in mingwrt-3.22 dated 2016-07-14. --- ChangeLog

Re: /*unsigned*/ int level3 in gen-uni-tables.c

On 8/12/20 12:12 PM, Bruno Haible wrote: why would this matter? This is C code, not C++ code. My guess is that it matters with picky implementations intended for debugging. The C standard allows implementations to trap when an out-of-range value is converted to a signed integer, and some

Re: gnulib and C++ compilers

Florian Weimer wrote: > Since gnulib is a copylib, it doesn't have much control over how it is > built. It's one of the issues that came up while trying to build > things with a C++ compiler instead of a C compiler. gnulib code is meant to be compiled with a C compiler. The header files are

Re: /*unsigned*/ int level3 in gen-uni-tables.c

Paul Eggert wrote: > My guess is that it matters with picky implementations intended for > debugging. > The C standard allows implementations to trap when an out-of-range value is > converted to a signed integer, and some debugging implementations do that. > See, > clang's new

Re: new module 'thread-optim'

Paul Eggert wrote: > True enough, but how about suggesting that people write something like the > following? > > bool mt = gl_multithreaded (); > if (mt) gl_lock_lock (file_cleanup_list_lock); > ... > if (mt) gl_lock_unlock (file_cleanup_list_lock); > > This is nearly as concise

Re: [PATCH] stdint: port intptr_t to more-recent MinGW

> * lib/stdint.in.h (intptr_t, uintptr_t): Do not define on MinGW, I can confirm that this patch works fine on my copy of mingw(-w64) from 2017. Bruno

Re: /*unsigned*/ int level3 in gen-uni-tables.c

Florian Weimer wrote: > gen-uni-tables.c produces types like this: > > struct > { > int header[1]; > int level1[2]; > short level2[2 << 7]; > /*unsigned*/ int level3[16 << 4]; > } > > Why is the unsigned commented out? I think, at the time the code was written, some K C

Re: /*unsigned*/ int level3 in gen-uni-tables.c

On 8/12/20 5:21 PM, Bruno Haible wrote: Does this sanitizer also apply to implicit conversions in static initializers? I think not. (But there is always next year's sanitizer. :-) Thanks for the update; I know this stuff can be a pain.

gendocs.sh - request for additional PDF in A4

The GnuCOBOL Programmer's Guide always created two sets of its PDF files: one in the default letter format and another in A4. With the recent changes in our build system this is achieved with running PDFs/%-letter.pdf : %.texi @mkdir -p $(dir $@) texi2pdf $(PDFOPTIONS) -o $@ -c

/*unsigned*/ int level3 in gen-uni-tables.c

gen-uni-tables.c produces types like this: struct { int header[1]; int level1[2]; short level2[2 << 7]; /*unsigned*/ int level3[16 << 4]; } Why is the unsigned commented out? Some of the constants are so large that they are treated as unsigned ints. This kind of narrowing