Reuben Thomas wrote:
> breaks on Darwin:
>
> In file included from glob.c:81:
> In file included from ./scratch_buffer.h:4:
> In file included from ./libc-config.h:33:
> ../config.h:927:9: warning: 'fnmatch' macro redefined [-Wmacro-redefined]
> #define fnmatch posix_fnmatch
> ^
>
Reuben Thomas wrote:
> I now get the same error, but with globfree.c. I am not sure why I didn't
> need this in my patches…
OK. Done as follows:
2018-08-18 Bruno Haible
glob: Fix another compilation error when glob.h is not replaced.
Reported and fix proposed by Reuben
Thanks for doing all those fixes, and sorry for any confusion that I introduced.
Eli Zaretskii wrote:
I urge you to reconsider and use the same technique we used in the
Emacs sources to shut up this warning. There's no reason Gnulib
cannot use that technique.
Is this the void (*) (void) cast that Andy just mentioned, or some other
technique? Sorry, I've lost some context
On 18 August 2018 at 20:45, Bruno Haible wrote:
> Paul Eggert wrote:
> > I didn't think the patch would be controversial
>
> ... whereas I would think that every revert or partial revert is
> controversial
> (except for obvious typos).
>
> > Please feel free to
> > revert the patch and replace
Eli Zaretskii wrote:
> There's also this additional option:
>
> 5) Cast through (void *). Like this:
>
> GetSystemTimePreciseAsFileTimeFunc =
> (GetSystemTimePreciseAsFileTimeFuncType) (void (*) (void))
> GetProcAddress (kernel32, "GetSystemTimePreciseAsFileTime");
Indeed,
On 18 August 2018 at 22:22, Reuben Thomas wrote:
> On 18 August 2018 at 21:45, Bruno Haible wrote:
>
>> Reuben Thomas wrote:
>> > This makes the build break again because of the problem I reported in
>> > glob_pattern_p.c (see my patch for it).
>>
>> Ah, I see. The macro 'weak_alias' apparently
On 18 August 2018 at 22:38, Bruno Haible wrote:
> Reuben Thomas wrote:
> > OK, globfree.c should already have seen libc-config.h via glob.h, so I
> > don't see why it's *not* working.
>
> We have a new optimization that omits the generated glob.h when it would
> not add relevant standardized
Paul Eggert wrote:
> I didn't think the patch would be controversial
... whereas I would think that every revert or partial revert is controversial
(except for obvious typos).
> Please feel free to
> revert the patch and replace it with something better.
Done as follows:
- I added a small
Reuben Thomas wrote:
> This makes the build break again because of the problem I reported in
> glob_pattern_p.c (see my patch for it).
Ah, I see. The macro 'weak_alias' apparently needs libc-config.h as well.
2018-08-18 Bruno Haible
glob: Fix compilation error when glob.h is not
On 18 August 2018 at 22:34, Bruno Haible wrote:
> Reuben Thomas wrote:
> > I now get the same error, but with globfree.c. I am not sure why I didn't
> > need this in my patches…
>
> OK. Done as follows:
>
Getting close. This now works on GNU/Linux, but breaks on Darwin:
In file included from
> diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
> index bff40d7..36b5074 100644
> --- a/lib/gettimeofday.c
> +++ b/lib/gettimeofday.c
> @@ -33,6 +33,10 @@
>
> #ifdef WINDOWS_NATIVE
>
> +/* Avoid warnings from gcc -Wcast-function-type. */
> +# define GetProcAddress \
> + (void *)
Reuben Thomas wrote:
> OK, globfree.c should already have seen libc-config.h via glob.h, so I
> don't see why it's *not* working.
We have a new optimization that omits the generated glob.h when it would
not add relevant standardized declarations. Since glob.h is not supposed
to define the macros
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, egg...@cs.ucla.edu, andrewjmore...@gmail.com,
> emacs-de...@gnu.org
> Date: Sun, 19 Aug 2018 02:17:52 +0200
>
> > diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
> > index bff40d7..36b5074 100644
> > --- a/lib/gettimeofday.c
> > +++
On 18 August 2018 at 08:57, Paul Eggert wrote:
> Reuben Thomas wrote:
>
>> Looks like lib/malloc/scratch_buffer.h needs to #include libc-config.h for
>> libc_hidden_proto? Only I can't quite believe it could be something so
>> simple for code that was last changed a while ago…
>>
>
> Does August
> Cc: br...@clisp.org, bug-gnulib@gnu.org, andrewjmore...@gmail.com,
> emacs-de...@gnu.org
> From: Paul Eggert
> Date: Sat, 18 Aug 2018 11:59:03 -0700
>
> Eli Zaretskii wrote:
> > There's no need to disable this warning at all.
>
> I thought the problem was that people were using -Werror on
On 18 August 2018 at 21:45, Bruno Haible wrote:
> Reuben Thomas wrote:
> > This makes the build break again because of the problem I reported in
> > glob_pattern_p.c (see my patch for it).
>
> Ah, I see. The macro 'weak_alias' apparently needs libc-config.h as well.
>
Yes. I assumed that
Hi guys!
Those two files are really alike, maybe one of them should be phased out?
In Bison I had a clash on FILE_SYSTEM_PREFIX_LEN when including them (actually,
I did not include dosname.h, it is included by a bunch of modules, including
dirname.h).
Cheers!
Reuben Thomas wrote:
Looks like lib/malloc/scratch_buffer.h needs to #include libc-config.h for
libc_hidden_proto? Only I can't quite believe it could be something so
simple for code that was last changed a while ago…
Does August 7 count as "a while ago"? Anyway, I suspect that caused the
Hi Paul,
> I installed the attached which should fix things, albeit more drastically
> than
> I'd like as it creates glob.h in cases where it's not needed.
This is frustrating in two aspects:
1) Reuben clearly stated a problem that he perceived:
> > Looks like lib/malloc/scratch_buffer.h
Hi Akim,
> Those two files are really alike, maybe one of them should be phased out?
Yes, this would likely be possible. But I'd say it's low priority,
since the benefit is small.
> In Bison I had a clash on FILE_SYSTEM_PREFIX_LEN when including them
> (actually, I did not include dosname.h, it
> Le 18 août 2018 à 17:58, Bruno Haible a écrit :
>
> Hi Akim,
Hi Bruno!
>> Those two files are really alike, maybe one of them should be phased out?
>
> Yes, this would likely be possible. But I'd say it's low priority,
> since the benefit is small.
Ok!
>> In Bison I had a clash on
> > There is also one function cast warning from gnulib code:
> > C:/emacs/git/emacs/master/lib/gettimeofday.c: In function 'initialize':
> > C:/emacs/git/emacs/master/lib/gettimeofday.c:48:9: warning: cast between
> > incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to
> >
Bruno Haible wrote:
This code uses GetProcAddress so that it can exploit
features of newer Windows versions while at the same time still
work on older Windows versions.
Can this problem be addressed a bit better by using GetProcAddress only inside
#ifndef HAVE_GETSYSTEMTIMEPRECISEASFILETIME
Bruno Haible wrote:
I thought that on this mailing list, we had an agreement that we discuss
patches_before_ committing them, if they are controversial.
I didn't think the patch would be controversial, since glob.h is built for all
sorts of reasons and this just seemed to be another
Paul Eggert wrote:
> Can this problem be addressed a bit better by using GetProcAddress only
> inside
> #ifndef HAVE_GETSYSTEMTIMEPRECISEASFILETIME code on builds for MS-Windows 7
> and
> earlier, and directly using GetSystemTimePreciseAsFileTime on builds for
> MS-Windows 8 and later?
I
> From: Bruno Haible
> Date: Sat, 18 Aug 2018 18:09:27 +0200
> Cc: Paul Eggert , Andy Moreton ,
> emacs-de...@gnu.org
>
> So, there are 4 options:
> 1) Use static reference to Windows API functions.
> 2) Use '#pragma GCC diagnostic ignored "-Wcast-function-type"'
> 3) Remove
> From: Paul Eggert
> Date: Sat, 18 Aug 2018 10:19:54 -0700
> Cc: Andy Moreton , emacs-de...@gnu.org
>
> Bruno Haible wrote:
> > This code uses GetProcAddress so that it can exploit
> > features of newer Windows versions while at the same time still
> > work on older Windows versions.
>
> Can
Eli Zaretskii wrote:
There's no need to disable this warning at all.
I thought the problem was that people were using -Werror on MS-Windows and that
builds were failing. If that's not the case, then we can simply go with Bruno's
option (4), i.e., live with the warning.
29 matches
Mail list logo
