Re: New warnings on emacs-26 branch with gcc 8.2.0

Yuri Khan wrote: > > Indeed, casting through (void *) or (void (*) (void)) avoids the > > warning. > > I seem to remember C does not guarantee that pointers to functions > must survive casting through void*. Yes, on some old architectures like Windows 3.1 a function pointer and a 'void *' had

Re: warning: 'fnmatch' macro redefined

On 19 August 2018 at 02:24, Bruno Haible wrote: > Reuben Thomas wrote: > > breaks on Darwin: > Sorry, I pasted the wrong part of the output. Here's the first error: glob.c:282:53: error: use of undeclared identifier '__GLOB_FLAGS' if (pattern == NULL || pglob == NULL || (flags &

Re: [bug-gawk] [PATCH] Avoid left-shifting a negative value (by a positive value)

Paul Eggert wrote: > arn...@skeeve.com wrote: > > The file under discussion came from GNULIB (I > > believe) so I'm adding bug-gnulib and will let that team comment on > > this. > > We fixed that long ago in a different way in Gnulib, so presumably the next > time > Gawk syncs mktime.c from

Re: Compilation error in glob.c with gcc 4.8

Reuben Thomas wrote: > > Sorry, I pasted the wrong part of the output. Here's the first error: > > glob.c:282:53: error: use of undeclared identifier '__GLOB_FLAGS' > if (pattern == NULL || pglob == NULL || (flags & ~__GLOB_FLAGS) != 0) > ^ >

glob: fix over-optimization due to attribute __nonnull__

On Mac OS X, while compiling a testdir for module 'glob', I see this warning: glob.c:282:7: warning: comparison of nonnull parameter 'pattern' equal to a null pointer is 'false' on first encounter [-Wtautological-pointer-compare] if (pattern == NULL || pglob == NULL || (flags & ~__GLOB_FLAGS)

limits-h, fnmatch-h, glob-h: improve maintainability

It's a pitfall for maintenance if stdint.m4 modifies a variable set in limits-h.m4 and use in the 'limits-h' module. It's better if this use is done through a macro invocation (like already done in the 'iconv-h' module). 2018-08-19 Bruno Haible glob-h: Formalize side effects from

Re: [PATCH] hard-locale: simplify by removing hard-locale.m4

Paul Eggert wrote on 2018-07-17: > diff --git a/NEWS b/NEWS > index 156e49cde..1328e7324 100644 > --- a/NEWS > +++ b/NEWS > @@ -42,6 +42,8 @@ User visible incompatible changes > > DateModules Changes > > +2018-07-17 hard-locale m4/hard-locale.m4 and gl_HARD_LOCALE are

Re: New warnings on emacs-26 branch with gcc 8.2.0

On Sun, Aug 19, 2018 at 4:26 AM Bruno Haible wrote: > Indeed, casting through (void *) or (void (*) (void)) avoids the > warning. I seem to remember C does not guarantee that pointers to functions must survive casting through void*. It does for casting between function pointer types. So casting

Re: Compilation error in glob.c with gcc 4.8

On Sun, 19 Aug 2018, 10:48 Bruno Haible, wrote: > Reuben Thomas wrote: > > > > Sorry, I pasted the wrong part of the output. Here's the first error: > > > > glob.c:282:53: error: use of undeclared identifier '__GLOB_FLAGS' > > if (pattern == NULL || pglob == NULL || (flags & ~__GLOB_FLAGS) !=

getpass: move declaration to

The 'getpass' module provides a replacement for a glibc function. In glibc the header file for this function is . In gnulib, so far, the user has to include "getpass.h" instead - simply because this module predates the 'unistd' module. This patch moves the declaration into , to match glibc.

Re: New warnings on emacs-26 branch with gcc 8.2.0

[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Avoid -Wcast-function-type warnings from casts after GetProcAddress.