Paul Eggert wrote:
> >> (I would not bet that code like this:
> >>#if 0
> >># if @FOOBAR@
> >># endif
> >>#endif
> >> works for all C and C++ compilers. Better avoid that.)
> > I always wondered if a compiler would fail with that.
>
> The C standard has required it to work ever sin
On 4/30/25 18:33, Collin Funk wrote:
(I would not bet that code like this:
#if 0
# if @FOOBAR@
# endif
#endif
works for all C and C++ compilers. Better avoid that.)
I always wondered if a compiler would fail with that.
The C standard has required it to work ever since C89 (see its
Hi Bruno,
Bruno Haible writes:
> modules/ieee754-h is simpler, with a use of _GL_GNULIB_HEADER that is
> effectively replaced with 1 on the gnulib side. But this works only if
> there are no other substitutions to be made (no @...@ replacements)
> in preprocessor lines. (I would not bet that cod
Hi Collin,
> > That glibc patch needs more work, as I think Gnulib is misusing _LIBC.
> > _LIBC means we're using the header while compiling glibc itself,
> > whereas obstack.h appears in /usr/include/obstack.h and is used in
> > other contexts.
>
> I see.
>
> In lib/cdefs.h there is '#ifndef __
Paul Eggert writes:
> That glibc patch needs more work, as I think Gnulib is misusing _LIBC.
> _LIBC means we're using the header while compiling glibc itself,
> whereas obstack.h appears in /usr/include/obstack.h and is used in
> other contexts.
I see.
In lib/cdefs.h there is '#ifndef __GNULIB
Bruno Haible writes:
> No. The command
> $ gitk -- lib/obstack.c lib/obstack.in.h lib/obstack.h
> shows that it were Paul Eggert, Alan Modra, and me. Thus, we need to
> ask for Alan Modra's permission. I'll write a mail...
When I checkout their last commit
d15b2da0ac25e085ce30a9e2672624999ce
Collin Funk wrote:
> It seems you were the only one to update obstack.in.h after the license
> change (minus copyright date updates).
No. The command
$ gitk -- lib/obstack.c lib/obstack.in.h lib/obstack.h
shows that it were Paul Eggert, Alan Modra, and me. Thus, we need to
ask for Alan Modra's p
On 4/29/25 18:30, Collin Funk wrote:
Thanks! I submitted the patch for the clang undefined behavior sanitizer
issue and Paul fixed it to account for your later Oracle cc fix [1].
That glibc patch needs more work, as I think Gnulib is misusing _LIBC.
_LIBC means we're using the header while com
On 4/29/25 18:50, Bruno Haible wrote:
Paul, what do you think? Should we change 'obstack' from LGPLv3+ to LGPLv2+ ?
That would be less confusing, yes.
Collin Funk wrote:
> Could we change the module to
> LGPLv2+ then? I think it is best to keep shared files in sync, even if
> it has to be done manually.
It would be possible, yes: all its module dependencies are already LGPLv2+.
Paul, what do you think? Should we change 'obstack' from LGPLv3+ to
Bruno Haible writes:
> When doing such syncs back to glibc, please sync selected patches. Don't
> just copy the entire file, because usually that will not work, due to
> many coding conventions that are different in glibc than in gnulib.
Yes, I noticed many differences between Gnulib's obstack a
Hi Collin,
> I would like to sync glibc's obstack.h with Gnulib's obstack.in.h in
> order to fix the undefined behavior sanitizer
> nullptr-with-nonzero-offset errors that were fixed in Gnulib, but not in
> glibc [1].
When doing such syncs back to glibc, please sync selected patches. Don't
just c
Hi Bruno,
I would like to sync glibc's obstack.h with Gnulib's obstack.in.h in
order to fix the undefined behavior sanitizer
nullptr-with-nonzero-offset errors that were fixed in Gnulib, but not in
glibc [1].
Upon copying the file to make necessary manual changes, I noticed that
the glibc's file
13 matches
Mail list logo
