Re: Suggestion for cherry-picking to stable branches

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> It's metadata in addition to the
>> commit summary (matching based on a title isn't easy, it's way easier if
>> someone says "here's the commits it's based on"; one can give multiple
>> such lines).
>
> It would significantly increase the amount of work for maintaining a stable
> branch. No, thanks.

Sure, no worries. I wasn't aware of your workflow and just wanted to
make the suggestion.

>
>> it makes life far easier if investigating a bug.
>
> The way I check whether a certain bug fix is present is
>   1. to get the fix from master,
>   2. find a particular code line / hunk that is essential for the fix,
>   3. look if this change is present in the branch.
>
> This is more reliable than to look at the git log or ChangeLog, because
> when a patch has not been applied correctly in the branch (due to
> rejects, maybe) there is a mismatch between the advertised list of fixes
> and the actual list of fixes.

Thanks!

best,
sam

Re: Suggestion for cherry-picking to stable branches

[Sam James]

Bruno Haible  writes:

>> > easy to compare with the original commit and distinguish
>> > branch-only commits from backports.
>
> You can get limited insights by comparing the ChangeLogs of the
> master branch with a stable branch.
>
> But if what you want is a mechanically verifiable assertion of
> any kind, I can tell you that none exists. Backporting patches
> is, ultimately, manual developer work. (This is obvious by the
> fact that developers who have to maintain 6 or 7 backport branches
> spend a *lot* of time on that.) You may trust or may not trust
> this developer work, but there is no mechanical way to prove
> that you can trust it.

I wasn't asking from a perpective of auditing, more that it makes life
far easier if investigating a bug. It's metadata in addition to the
commit summary (matching based on a title isn't easy, it's way easier if
someone says "here's the commits it's based on"; one can give multiple
such lines).

If it's not easy for you to add that metadata with your workflow, that's
fine, of course.

thanks,
sam

Re: Suggestion for cherry-picking to stable branches

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> Could I propose that cherry-picks to the stable-XXX branches are done
>> with 'git cherry-pick -x'? This is often done in projects following a
>> gnulib-like model.
>> 
>> git will append '(cherry picked from commit ...)' to the commit message
>> which makes it easy to compare with the original commit and distinguish
>> branch-only commits from backports.
>
> All commits to the stable branches [1] are backports. There are no commits
> that are created for the branch specifically.
>
> But while doing these backports, I have to make several adjustments:
>   - Combine 2 or more commits from 'master' if the first of these commits
> introduced a regression that was only fixed later on.
>   - Assign new '# serial' numbers to the *.m4 files.
>   - Omit modifications to modules that did not exist when the stable branch
> was forked off.
>   - Omit documentation changes that don't apply.
>   - Fix merge conflicts.
>   - For stable branches from the previous year: Update the (C) year
> of each modified file.
>
> I don't think that a tool like 'git cherry-pick' will allow me to have
> the needed flexibility for this process.

Ah, so, in a way, this is precisely why the line is useful, because
they're *not* direct cherry-picks and it's useful to be able to
correspond them to what the mainline change(s) were.

But if you're not using 'git cherry-pick' already for these, then I can
understand it's a big workflow change and probably not worth it.

The expectation isn't that it directly matches the 'cherry-picked from
...' commits, but rather that it gives some anchor to compare to /
expresses intent, rather than having to compare just the commit summary
(as those aren't unique).

>
> Bruno
>
> [1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html

Suggestion for cherry-picking to stable branches

[Sam James]

Hi,

Could I propose that cherry-picks to the stable-XXX branches are done
with 'git cherry-pick -x'? This is often done in projects following a
gnulib-like model.

git will append '(cherry picked from commit ...)' to the commit message
which makes it easy to compare with the original commit and distinguish
branch-only commits from backports.

thanks,
sam


signature.asc
Description: PGP signature

Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

[Sam James]

Paul Eggert  writes:

> On 2024-04-27 15:17, Sam James wrote:
>> Someone might read this and wrongly think that "GCC 14"
>> is broken.
>> I'd just omit 14 here.
>
> Good point as I think some of these bugs are also in GCC 13.x for some
> value of x.
>
> I installed the attached. It's not quite what you asked for but I hope
> it addresses the issue.
>

WFM, cheers paul!

> [2. text/x-patch; 0001-maint-be-more-precise-and-vague-about-GCC-14.patch]...

Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

[Sam James]

Paul Eggert  writes:

> * m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
> ---
>  ChangeLog   |  3 +++
>  doc/gnulib.texi |  4 
>  m4/nullptr.m4   | 18 --
>  3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index b30238f934..e341b62968 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,5 +1,8 @@
>  2024-04-27  Paul Eggert  
>  
> + nullptr: work around GCC 14 nullptr sentinel bug
> + * m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
> +
>   stddef: work around GCC 14 stddef.h bugs
>   * lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
>   defined, as stddef.h has already been included.  This works
> diff --git a/doc/gnulib.texi b/doc/gnulib.texi
> index ac8c01d1e1..aa0eb57f62 100644
> --- a/doc/gnulib.texi
> +++ b/doc/gnulib.texi
> @@ -978,6 +978,10 @@ Portability problems fixed by Gnulib:
>  Some platforms lack @code{nullptr}:
>  For C: GCC 12, Clang 15, and other pre-2023 C compilers.
>  For C++: pre-2011 C++ compilers.
> +
> +@item
> +Some platforms incorrectly warn when @code{nullptr} is a sentinel argument:
> +GCC 13.2 and 14.0.

This is perhaps a bit confusing, even if technically correct. It'll be
fixed in the final release (GCC 14.1), as Jakub fixed it on 2024-04-23.

GCC X.0 will never be released and refers to a development version (just
like GCC X.Y.1). Someone might read this and wrongly think that "GCC 14"
is broken.

I'd just omit 14 here.

>  @end itemize
>  
>  Portability problems not fixed by Gnulib:
> diff --git a/m4/nullptr.m4 b/m4/nullptr.m4
> index e99495..4f2284296a 100644
> --- a/m4/nullptr.m4
> +++ b/m4/nullptr.m4
> @@ -1,5 +1,5 @@
>  # nullptr.m4
> -# serial 1
> +# serial 2
>  dnl Copyright 2023-2024 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -14,7 +14,21 @@ AC_DEFUN([gl_NULLPTR],
>   AC_CACHE_CHECK([for C nullptr], [gl_cv_c_nullptr],
> [AC_COMPILE_IFELSE(
>[AC_LANG_SOURCE([[int *p = nullptr;]])],
> -  [gl_cv_c_nullptr=yes],
> +  [gl_cv_c_nullptr=yes
> +   # Work around 
> .
> +   gl_saved_CFLAGS=$CFLAGS
> +   CFLAGS="$CFLAGS -Wall -Werror"
> +   AC_COMPILE_IFELSE(
> + [AC_LANG_PROGRAM(
> +[[void f (char const *, ...) __attribute__ ((sentinel));]],
> +[[f ("", nullptr);]])],
> + [],
> + [AC_COMPILE_IFELSE(
> +[AC_LANG_PROGRAM(
> +   [[void f (char const *, ...) __attribute__ 
> ((sentinel));]],
> +   [[f ("", (void *) 0);]])],
> +[gl_cv_c_nullptr='not as a sentinel'])])
> +   CFLAGS=$gl_saved_CFLAGS],
>[gl_cv_c_nullptr=no])])
>gl_c_nullptr=$gl_cv_c_nullptr
>AC_LANG_POP([C])],

Re: [PATCH] largefile: port to C++

[Sam James]

Paul Eggert  writes:

> This patch is mostly taken from Autoconf master.
> * m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED):
> Undefine if unpatched Autoconf 2.72 or earlier, so that
> later code will redefine it.
> The remaining part of this patch is from Autoconf master.
> (_AC_SYS_YEAR2038_PROBE, _AC_SYS_LARGEFILE_PROBE):
> Put "$CCFLAGS" in diagnostics, not "$CC".
> (_AC_SYS_LARGEFILE_OPTIONS): Omit -n32.
> (AC_SYS_LARGEFILE_PROBE): Fiddle with CPPFLAGS, not CC.
> Do not worry about -n32.
> ---
>  ChangeLog   | 12 
>  m4/largefile.m4 | 33 -

Please crank serial.

>  2 files changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 6564e09ac5..676aaef0be 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,5 +1,17 @@
>  2024-04-24  Paul Eggert  
>  
> + largefile: port to C++
> + This patch is mostly taken from Autoconf master.
> + * m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED):
> + Undefine if unpatched Autoconf 2.72 or earlier, so that
> + later code will redefine it.
> + The remaining part of this patch is from Autoconf master.
> + (_AC_SYS_YEAR2038_PROBE, _AC_SYS_LARGEFILE_PROBE):
> + Put "$CCFLAGS" in diagnostics, not "$CC".
> + (_AC_SYS_LARGEFILE_OPTIONS): Omit -n32.
> + (AC_SYS_LARGEFILE_PROBE): Fiddle with CPPFLAGS, not CC.
> + Do not worry about -n32.
> +
>   c32srtombs,mbsrtoc32s,mbsrtowcs,wcsrtombs: pacify GCC 14
>   * lib/c32srtombs-state.c (_gl_c32srtombs_state):
>   * lib/mbsrtoc32s-state.c (_gl_mbsrtoc32s_state):
> diff --git a/m4/largefile.m4 b/m4/largefile.m4
> index cf97e986a3..2f824089b0 100644
> --- a/m4/largefile.m4
> +++ b/m4/largefile.m4
> @@ -26,9 +26,20 @@ AC_DEFUN([gl_SET_LARGEFILE_SOURCE],
>   ]])
>  )
>  
> +dnl Remove AC_SYS_YEAR2038_RECOMMENDED if unpatched Autoconf 2.72 or earlier.
> +dnl Autoconf 2.72 still uses -n32, which is not a C preprocessor option,
> +dnl and which was useful only on IRIX which is no longer supported.
> +dnl This should be fixed in Autoconf 2.73.
> +m4_ifdef([AC_SYS_YEAR2038_RECOMMENDED],
> +  [m4_bmatch(m4_ifdef([_AC_SYS_LARGEFILE_OPTIONS],
> +   [m4_defn([_AC_SYS_LARGEFILE_OPTIONS])],
> +   ["-n32"]),
> + ["-n32"],
> +   [m4_undefine([AC_SYS_YEAR2038_RECOMMENDED])])])
> +
>  m4_ifndef([AC_SYS_YEAR2038_RECOMMENDED], [
> -# Support AC_SYS_YEAR2038_RECOMMENDED and related macros, even if
> -# Autoconf 2.71 or earlier.  This code is taken from Autoconf master.
> +# Fix up AC_SYS_YEAR2038_RECOMMENDED and related macros, even if
> +# unpatched Autoconf 2.72 or earlier.  This code is taken from Autoconf 
> master.
>  
>  # _AC_SYS_YEAR2038_TEST_CODE
>  # --
> @@ -77,7 +88,7 @@ m4_define([_AC_SYS_YEAR2038_OPTIONS], m4_normalize(
>  # If you change this macro you may also need to change
>  # _AC_SYS_YEAR2038_OPTIONS.
>  AC_DEFUN([_AC_SYS_YEAR2038_PROBE],
> -[AC_CACHE_CHECK([for $CC option for timestamps after 2038],
> +[AC_CACHE_CHECK([for $CPPFLAGS option for timestamps after 2038],
>[ac_cv_sys_year2038_opts],
>[ac_save_CPPFLAGS="$CPPFLAGS"
>ac_opt_found=no
> @@ -207,7 +218,6 @@ m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
>  ["none needed"]   dnl Most current systems
>  ["-D_FILE_OFFSET_BITS=64"]dnl X/Open LFS spec
>  ["-D_LARGE_FILES=1"]  dnl 32-bit AIX 4.2.1+, 32-bit z/OS
> -["-n32"]  dnl 32-bit IRIX 6, SGI cc (obsolete)
>  ))
>  
>  # _AC_SYS_LARGEFILE_PROBE
> @@ -224,25 +234,25 @@ m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
>  # If you change this macro you may also need to change
>  # _AC_SYS_LARGEFILE_OPTIONS.
>  AC_DEFUN([_AC_SYS_LARGEFILE_PROBE],
> -[AC_CACHE_CHECK([for $CC option to enable large file support],
> +[AC_CACHE_CHECK([for $CPPFLAGS option for large files],
>[ac_cv_sys_largefile_opts],
> -  [ac_save_CC="$CC"
> +  [ac_save_CPPFLAGS=$CPPFLAGS
>ac_opt_found=no
>for ac_opt in _AC_SYS_LARGEFILE_OPTIONS; do
>  AS_IF([test x"$ac_opt" != x"none needed"],
> -  [CC="$ac_save_CC $ac_opt"])
> +  [CPPFLAGS="$ac_save_CPPFLAGS $ac_opt"])
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([_AC_SYS_LARGEFILE_TEST_CODE])],
>   [AS_IF([test x"$ac_opt" = x"none needed"],
>   [# GNU/Linux s390x and alpha need _FILE_OFFSET_BITS=64 for wide ino_t.
> -  CC="$CC -DFTYPE=ino_t"
> +  CPPFLAGS="$CPPFLAGS -DFTYPE=ino_t"
>AC_COMPILE_IFELSE([], [],
> -[CC="$CC -D_FILE_OFFSET_BITS=64"
> +[CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"
>   AC_COMPILE_IFELSE([], [ac_opt='-D_FILE_OFFSET_BITS=64'])])])
>ac_cv_sys_largefile_opts=$ac_opt
>ac_opt_found=yes])
>  test $ac_opt_found = no || break
>done
> -  CC="$ac_save_CC"
> +  CPPFLAGS=$ac_save_CPPFLAGS
>dnl Gnulib implements large file support for native Windows, based on the
>dnl variables WINDOWS_64_BIT_OFF_T, WINDOWS_64_BIT_ST_SIZE.
>

Re: new committer questions

[Sam James]

Bruno Haible  writes:

> Our new committer, Collin Funk, asks:
>> Since I am not a GNU maintainer and have not
>> used Savannah, please send any other rules, documentation, etc. that
>> you think would be beneficial to read.
> [...]

Forgive the noise, but congratulations Collin!

> [...]
>
> Bruno

best,
sam

Re: [PATCH] Fix wchar_h.m4 serial number

[Sam James]

Bruno Haible  writes:

> Hi Sam,
>
Hi Bruno,

>> * m4/wchar_h.m4: Remove duplicate serial number specification and increment
>>   serial.
>
> Thanks, applied.
>
>> (It's easier for some work I'm doing if each serial maps to one checksum
>> of the macro, and serial #s are free.)
>
> We cannot guarantee this. For example, if we make a comment-only change to
> a .m4 file, or if we simply forget bumping the serial, two variants of the
> file with the same serial can be the result.

No problem. Thank you for the fast application & response! :)

>
> Bruno

best,
sam


signature.asc
Description: PGP signature

[PATCH] Fix wchar_h.m4 serial number

[Sam James]

Remove duplicate serial number specification (the latter of which is invalid)
and increment the serial to reflect this change.

(It's easier for some work I'm doing if each serial maps to one checksum
of the macro, and serial #s are free.)

* m4/wchar_h.m4: Remove duplicate serial number specification and increment
  serial.
---
 m4/wchar_h.m4 | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/m4/wchar_h.m4 b/m4/wchar_h.m4
index a7b660defd..995bdc659d 100644
--- a/m4/wchar_h.m4
+++ b/m4/wchar_h.m4
@@ -1,5 +1,5 @@
 # wchar_h.m4
-# serial 1
+# serial 64
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -9,8 +9,6 @@ dnl A placeholder for ISO C99 , for platforms that 
have issues.
 
 dnl Written by Eric Blake.
 
-# wchar_h.m4 serial 63
-
 AC_DEFUN_ONCE([gl_WCHAR_H],
 [
   AC_REQUIRE([gl_WCHAR_H_DEFAULTS])
-- 
2.44.0

Re: autoreconf --force seemingly does not forcibly update everything

[Sam James]

Bruno Haible  writes:

> Nick Bowler wrote:
>> If I distribute a release package, what I have tested is exactly what is
>> in that package.  If you start replacing different versions of m4 macros,
>> or use some distribution-patched autoconf/automake/libtool or whatever,
>> then this you have invalidated any and all release testing.
>
> +1
>
> Last month, I spent 2 days on prerelease testing of coreutils. If, after
> downloading the carefully prepared tarball from ftp.gnu.org, the first
> thing a distro does is to throw away the *.m4 files and regenerate the
> configure script with their own one,
>   * It shows no respect for the QA work that the upstream developers have
> put in.

This reads as taking it a bit personally to me.

Nick poses that a specific combination of tools is what is tested and
anything else invalidates it. But how does this work when building on a
system that was never tested on, or with different flags, or a different
toolchain?

It's reasonable to say "look, if you do this, please both state it
clearly and also do some investigation first to see if you can reproduce
it with my macros", but I don't think it's a crime for someone to
attempt it either.

It also has value in the context of software which is no longer
maintained but needs to work on newer systems.

We don't apply this rule to anything else -- you've never rejected a
report from me because I have a newer version of a library installed
like openssl or similar. Why is this different?

>   * It increases the number of bug reports that reach upstream and yet
> are caused by the distro.
>   * In the long run, the upstream maintainers will be less willing to
> handle bug reports from users of this distro.
>

I do sympathise with these points and also that it might be
overwhelming given it removes the ability to fix some elements of the
build environment. Right now, you can at least assert that it builds in
a diverse set of places based on what you tested.

> Bruno

thanks,
sam


signature.asc
Description: PGP signature

Re: serial number format

[Sam James]

Paul Eggert  writes:

> I've not been a fan of those .m4 serial numbers, which may help to
> explain why so many .m4 files lack them. Although I still have doubts
> whether they're worth the trouble, perhaps it'd help if we added a
> file m4/.dir-locals.el (or something similar) that would cause Emacs
> to update these serial numbers automatically.

Not quite it, but autoconf-archive has some tooling around it:
* 
https://github.com/autoconf-archive/autoconf-archive/blob/81e26138e807b9ecb3c19b953e8776ff9e415fdf/macro.py#L112
* 
https://github.com/autoconf-archive/autoconf-archive/blob/81e26138e807b9ecb3c19b953e8776ff9e415fdf/set-serial.sh#L20

Maintainer mode is integrated with this so it updates serial numbers
automatically.

Re: serial number format

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> For reasons once might be able to guess, I'm currently playing with
>> "known" M4 macros vs unseen serials and such.
>> 
>> At the moment, my tool uses the format described at
>> https://www.gnu.org/software/automake/manual/html_node/Serials.html.
>> 
>> My reading of it implies that the use in e.g. m4/build-to-host.m4
>> as '# build-to-host.m4 serial 3' isn't valid (I would expect "# serial 3
>> build-to-host.m4" or similar, closest analogue).
>> 
>> If I grep for serial in gnulib, I see a mix of both the format I
>> expected and this other format which uses the macro name too.
>> 
>> Are both formats valid (I know it's largely a convention)?
>
> The handling of the 'serial' lines happens in $PREFIX/bin/aclocal,
> lines 149..151:
>
>   # Match a serial number.
>   my $serial_line_rx = '^#\s*serial\s+(\S*)';
>   my $serial_number_rx = '^\d+(?:\.\d+)*$';
>
> and lines 604..709. This means, the format is a line that starts
> with '#', followed by optional whitespace, then the word 'serial',
> then some whitespace, then some consecutive non-whitespace characters.
> The latter must consist only of digits and dots and start with a digit
> (see also the error message at line 611:
>   "expecting a version string with only digits and dots").
>
> So, a line
>   # build-to-host.m4 serial 3
> has no effect.
>
> The format with fractional digits is, of course, useful for git branches,
> where we can have
>   # serial 4.1
> if on the 'master' branch the serial 4 and 5 already exist.
>
>> Is there a
>> reason for the apparent inconsistency in format used within e.g. gnulib?
>
> Yes: In some cases (see $PREFIX/bin/aclocal, lines 910..936) the generated
> aclocal.m4 file does not contain a reference to the .m4 file but its entire
> contents. In order to make it clear which .m4 file is where in the aclocal.m4
> file, I added a comment indicating the original file name. But having not
> read the Automake documentation, I thought I could merge it with the 'serial'
> line...
>
>> I'll inevitably have to try deal with both formats as they will be in
>> the wild anyway, but got curious ;)
>
> No, you need to deal only with the valid format, not with the ineffective one.
>
> I am applying these three patches:

Thank you very much Bruno -- for the quick fix, explanation, and prompt
reply. Cheers!

At a glance, it looks like gettext's m4/fixautomake.m4 at
least might be affected. There's some in GNU Autoconf's testsuite, but
that requires further inspection in case it's deliberately testing the
parsing.

I should really have all the GNU projects in one directory so I can
easily grep in future.

> [...]

best,
sam


signature.asc
Description: PGP signature

serial number format

[Sam James]

Hi all,

For reasons once might be able to guess, I'm currently playing with
"known" M4 macros vs unseen serials and such.

At the moment, my tool uses the format described at
https://www.gnu.org/software/automake/manual/html_node/Serials.html.

My reading of it implies that the use in e.g. m4/build-to-host.m4
as '# build-to-host.m4 serial 3' isn't valid (I would expect "# serial 3
build-to-host.m4" or similar, closest analogue).

If I grep for serial in gnulib, I see a mix of both the format I
expected and this other format which uses the macro name too.

Are both formats valid (I know it's largely a convention)? Is there a
reason for the apparent inconsistency in format used within e.g. gnulib?
Is there anywhere else I should go read up on conventions for this?

I'll inevitably have to try deal with both formats as they will be in
the wild anyway, but got curious ;)

thanks,
sam


signature.asc
Description: PGP signature

Re: gnulib-tool caching

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> > I see... you are building a cache that will become invalid when either
>> >   - the bootstrap.conf changes, or
>> >   - there is a change in gnulib in one of the request modules (in the
>> > module description or in code).
>> 
>> We could also probably cache based on (g)libc version, kernel version,
>> compiler & linker version, and any dependencies which gnulib modules may
>> use (e.g. OpenSSL).
>
> We are talking about different things.
> 1) First comes the './autogen.sh' execution (or 'bootstrap'), which
>generates files, by calling gnulib-tool and the Autotools.
> 2) Then comes the './configure' step.
>
> We are talking about caching the result of 1).
> You seem to be thinking about 2).

Oh, I see. Thanks!

>
> Bruno

Re: gnulib-tool caching

[Sam James]

Bruno Haible  writes:

> Simon Josefsson wrote:
>> I now
>> remember that something like this was discussed before:
>> 
>> https://git.savannah.gnu.org/cgit/libidn.git/commit/?id=9ae53e866a6fafa56db26d184ccae9c39dae7446
>> https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00077.html
>
> I see... you are building a cache that will become invalid when either
>   - the bootstrap.conf changes, or
>   - there is a change in gnulib in one of the request modules (in the
> module description or in code).

We could also probably cache based on (g)libc version, kernel version,
compiler & linker version, and any dependencies which gnulib modules may
use (e.g. OpenSSL).

While that might sound a bit much, it should be pretty quick to
calculate compared to no cache at all.

With that, you can do pretty well, I think. Whether or not it's worth it
is another question. We'd still need people to be responsible about it
(not use it recklessly, just when they're developing and know when their
system changes).

I wasn't aware of the Python tool work and am intrigued.

Re: Configure warning/error in m4/frexp.m4

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> > It's good if you have the time to test not-yet-released compiler versions.
>> > I don't have that time, and therefore will prefer to wait until the
>> > clang release is out.
>> 
>> OK. You've appreciated reports in the past (even quite recently), I can
>> avoid making them in future if you'd prefer me to avoid it for
>> gnulib.
>
> Let me say it like this:
>   - If a new compiler feature is still being discussed or likely to be 
> changed,
> I would consider it too early to involve Gnulib.
>   - If a new compiler feature is finalized and it's only a matter of time
> until it becomes official, then you're welcome to involve us, as it will
> allow us to react sooner.
>
> This is for general things. There may be special situations which need
> different handling.
>

Fair enough. Thanks, and sorry for the noise.

> Bruno

sam

Re: Configure warning/error in m4/frexp.m4

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> it's still going to be an issue if (as
>> planned) Clang flips '-Wincompatible-pointer-types' to error out by
>> default unless they carve out an exception for qualifiers here.
>> 
>> I'll advocate that they do, of course. I just came across it while
>> checking for configure changes w/ recent GCC changes.
>
> It's good if you have the time to test not-yet-released compiler versions.
> I don't have that time, and therefore will prefer to wait until the
> clang release is out.

OK. You've appreciated reports in the past (even quite recently), I can
avoid making them in future if you'd prefer me to avoid it for
gnulib. This tends to be particularly important for gnulib given it's included
in other projects and changes take time to propagate into releases.

Perhaps I should have been clearer that in this instance, I was asking
for opinions rather than saying this is definitely a problem to be fixed, as 
well.

>
> If they really want to make an implicit assignment from 'const char *'
> or 'volatile char *' to 'char *' an error, it will cause problems in
> many packages, namely where argument arrays for calling exec* are
> constructed: Since
>

Anyway, I'll communicate the desire that Clang be consistent with GCC
and not create busywork as these cases aren't really the problematic
type anyway.

thanks,
sam

Re: Configure warning/error in m4/frexp.m4

[Sam James]

Sam James  writes:

> Bruno Haible  writes:
>
>> Hi Sam,
>
> Hi Bruno,
>
>>
>>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>>> a Clang warning/error when Clang is passed
>>> -Werror=incompatible-pointer-types.
>>
>> Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at
>> configure time. Neither with gcc nor with clang.
>
> Yes, I understand that. But Clang is likely to make this change to its
> default and -Werror=... was just a way of emulating that. gnulib _does_
> have to cater to the default strictness of compilers.
>
>>
>> The reason is that [1]
>>   "Many GCC warning options usually don’t point to mistakes in the code;
>>these warnings enforce a certain programming style. It is a project
>>management decision whether you want your code to follow any of these
>>styles. Note that some of these programming styles are conflicting.
>>You cannot have them all; you have to choose among them."
>>
>> For example, there is a warning option that attempts to enforce
>> explicit casts (no implicit conversions), and there is a warning option
>> that attempts to enforce no explicit casts. When you use such a warning
>> option together with -Werror, you are attempting to enforce a certain
>> programming style on the configure tests. Obviously the configure test
>> snippets cannot obey different, conflicting programming styles.
>
> Yep, completely on board with that & I get it. The only reason I
> reported this is because there's a reasonable chance this will be Clang's
> new behaviour by default (see below).
>
>>
>>> /tmp/foo.c: In function ‘main’:
>>> /tmp/foo.c:59:21: warning: passing argument 2 of ‘memcmp’ discards 
>>> ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
>>>59 | if (memcmp (, , sizeof x))
>>>   | ^~
>>
>> There is nothing wrong with this code (m4/frexp.m4:159, m4/frexpf.m4:83).
>>
>> We don't want to add a cast here, because — as Paul argues — casts can make
>> code more difficult to maintain in the long run.
>
> Yes, I agree it's pedantic, but it's still going to be an issue if (as
> planned) Clang flips '-Wincompatible-pointer-types' to error out by
> default unless they carve out an exception for qualifiers here.
>
> I'll advocate that they do, of course. I just came across it while
> checking for configure changes w/ recent GCC changes.

I should add: if your position is, reasonably, "clang really shouldn't
do that unless they carve out an exception for this kind of case",
then that's fine. But the report was not about me just doing -Werror=x
for the sake of it and misunderstands the motivation here.

>
>>
>> Bruno
>>
>> [1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

Re: Configure warning/error in m4/frexp.m4

[Sam James]

Bruno Haible  writes:

> Hi Sam,

Hi Bruno,

>
>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>> a Clang warning/error when Clang is passed
>> -Werror=incompatible-pointer-types.
>
> Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at
> configure time. Neither with gcc nor with clang.

Yes, I understand that. But Clang is likely to make this change to its
default and -Werror=... was just a way of emulating that. gnulib _does_
have to cater to the default strictness of compilers.

>
> The reason is that [1]
>   "Many GCC warning options usually don’t point to mistakes in the code;
>these warnings enforce a certain programming style. It is a project
>management decision whether you want your code to follow any of these
>styles. Note that some of these programming styles are conflicting.
>You cannot have them all; you have to choose among them."
>
> For example, there is a warning option that attempts to enforce
> explicit casts (no implicit conversions), and there is a warning option
> that attempts to enforce no explicit casts. When you use such a warning
> option together with -Werror, you are attempting to enforce a certain
> programming style on the configure tests. Obviously the configure test
> snippets cannot obey different, conflicting programming styles.

Yep, completely on board with that & I get it. The only reason I
reported this is because there's a reasonable chance this will be Clang's
new behaviour by default (see below).

>
>> /tmp/foo.c: In function ‘main’:
>> /tmp/foo.c:59:21: warning: passing argument 2 of ‘memcmp’ discards 
>> ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
>>59 | if (memcmp (, , sizeof x))
>>   | ^~
>
> There is nothing wrong with this code (m4/frexp.m4:159, m4/frexpf.m4:83).
>
> We don't want to add a cast here, because — as Paul argues — casts can make
> code more difficult to maintain in the long run.

Yes, I agree it's pedantic, but it's still going to be an issue if (as
planned) Clang flips '-Wincompatible-pointer-types' to error out by
default unless they carve out an exception for qualifiers here.

I'll advocate that they do, of course. I just came across it while
checking for configure changes w/ recent GCC changes.

>
> Bruno
>
> [1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

Configure warning/error in m4/frexp.m4

[Sam James]

Hi,

The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
a Clang warning/error when Clang is passed
-Werror=incompatible-pointer-types.

This _isn't_ an issue with GCC 14, as it doesn't consider the lost
const to be a problem, like so:

/tmp/foo.c: In function ‘main’:
/tmp/foo.c:59:21: warning: passing argument 2 of ‘memcmp’ discards ‘volatile’ 
qualifier from pointer target type [-Wdiscarded-qualifiers]
   59 | if (memcmp (, , sizeof x))
  | ^~
In file included from /tmp/foo.c:3:
/usr/include/string.h:64:50: note: expected ‘const void *’ but argument is of 
type ‘volatile double *’
   64 | extern int memcmp (const void *__s1, const void *__s2, size_t __n)
  |  ^~~~

But Clang on the other hand, when directed to treat incompatible
ptr. types as errors (which they may well do given GCC is) gives:

/tmp/foo.c:59:21: error: passing 'volatile double *' to parameter of type 
'const void *' discards qualifiers 
[-Werror,-Wincompatible-pointer-types-discards-qualifiers]
   59 | if (memcmp (, , sizeof x))
  | ^~
/usr/include/string.h:64:50: note: passing argument to parameter '__s2' here
   64 | extern int memcmp (const void *__s1, const void *__s2, size_t __n)
  |  ^
1 error generated.

I'm naturally testing with GCC 14 at the moment but this was left over
in some of the older testing we did with Clang so I'm working through
the backlog there as well.

thanks,
sam

obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

[Sam James]

Gavin Smith  writes:

> On Sun, Nov 12, 2023 at 12:41:58PM +0100, John Paul Adrian Glaubitz wrote:
>
>> > diff tree.c.old tree.c -u
>> > --- tree.c.old  2023-11-04 16:15:13.632755680 +
>> > +++ tree.c  2023-11-04 16:16:36.211072521 +
>> > @@ -43,7 +43,10 @@
>> >if (obs_element_first)
>> >  obstack_free (_element, obs_element_first);
>> >else
>> > -obstack_init (_element);
>> > +{
>> > +  obstack_alignment_mask (_element) = 7; /* 8-byte alignment */
>> > +  obstack_init (_element);
>> > +}
>> >  
>> >obs_element_first = obstack_alloc (_element, sizeof (int));
>> > 
>> > 
>> > Can you check if that works?
>> 
>> Yes, I can confirm that this patch fixes the crash for me.
>> 
>> Would be great if this fix could be included for the next release!
>
> I've added it to the release branch so if there is ever a Texinfo 7.1.1
> release, it will be included.  In the current development code, there
> are significant changes and obstacks don't appear to be used at all,
> making it a moot point.
>
> The problem should probably to be reported to the gnulib developers to
> investigate why incorrectly aligned memory was being returned.

Thanks. I'll add bug-gnulib@ and summarise below.

When building Texinfo 7.1 on sparc64, texi2any crashes with SIGBUS like:

/bin/bash: line 16: 753042 Bus error   TEXINFO_DEV_SOURCE=1 
top_srcdir=".." top_builddir=".." /usr/bin/perl ../tp/texi2any -c 
INFO_SPECIAL_CHARS_WARNING=0 -I . -o texi2any_api.info `test -
f 'texi2any_api.texi' || echo './'`texi2any_api.texi
/bin/bash: line 16: 753044 Bus error   TEXINFO_DEV_SOURCE=1 
top_srcdir=".." top_builddir=".." /usr/bin/perl ../tp/texi2any -c 
INFO_SPECIAL_CHARS_WARNING=0 -I . -o info-stnd.info `test -f
'info-stnd.texi' || echo './'`info-stnd.texi

We found this was introduced to texinfo by
83259a78038068caf3f3d8d669796ea003a63735 ('Run 'gnulib-tool --add-import
obstack' under tp/Texinfo/XS.')

When building Texinfo and running its test suite with ubsan on sparc64,
we get:


export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
./autogen.sh;  ./configure PERL_EXT_CFLAGS="-O2 -ggdb3
-fsanitize=undefined" CFLAGS="-O2 -ggdb3 -fsanitize=undefined"   ; make
-j$(nproc) ; make check -j$(nproc)

parsetexi/tree.c:77:11: runtime error: member access within misaligned address 
0x0100010e9744 for type 'struct ELEMENT', which requires 8 byte alignment
0x0100010e9744: note: pointer points here
  00 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 
00 00 00 00 00 00 00
  ^
#0 0xfff8000102fc12ec in new_element parsetexi/tree.c:77
#1 0xfff8000102fc12ec in new_element parsetexi/tree.c:77
#2 0xfff8000102fabee4 in setup_document_root_and_before_node_section 
parsetexi/parser.c:521
#3 0xfff8000102fbc584 in parse_texi_document parsetexi/parser.c:532
#4 0xfff8000102f84338 in parse_file parsetexi/api.c:231
#5 0xfff8000102f73f28 in XS_Texinfo__Parser_parse_file 
parsetexi/Parsetexi.c:239
#6 0xfff80001004563bc  (/usr/lib64/libperl.so.5.38+0x1563bc)
#7 0xfff800010044ae64 in Perl_runops_standard 
(/usr/lib64/libperl.so.5.38+0x14ae64)
#8 0xfff800010037a2b4 in perl_run (/usr/lib64/libperl.so.5.38+0x7a2b4)
#9 0x1000d10 in main (/usr/bin/perl+0xd10)
#10 0xfff800010092a894 in __libc_start_call_main 
../sysdeps/nptl/libc_start_call_main.h:58
#11 0xfff800010092a99c in __libc_start_main_impl 
/usr/src/debug/sys-libs/glibc-2.37-r3/glibc-2.37/csu/libc-start.c:360
#12 0x1000d74 in _start (/usr/bin/perl+0xd74)

It appears that the obstack gnulib module is the culprit. The workaround
patch Gavin has applied to release/7.1 is at
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?h=release/7.1=81a854e22ca2449f2351436a863e5262935f5dc0.

thanks,
sam

Re: hooks for memory allocators

[Sam James]

Bruno Haible  writes:

> Sam James wrote:
>> I don't think this applies to gnulib, but it feels relevant enough for
>> me to mention it: for packages with their own allocator where they
>> retain a pool, it may be worth adding ASAN attributes/hooks.
>> 
>> Emacs did this a little while ago in
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=cb242bf1514ade34ab93b1db1ea7550093ae5839
>
> Interesting; I wasn't aware of that.
>
> It may be useful in the Gnulib module 'ssfmalloc'.

Now I learned two things today ;)

Valgrind has similar annotations available, by the way.

>
> Bruno

Re: *alloc: Take advantage of CHERI bounds-checking

[Sam James]

Bruno Haible  writes:

> I was impressed by the fact that CHERI detected the multithread-safety
> bug of gnulib's use of rand() in the test suite.
>
> Now I'd like to try CHERI on packages like gettext, and see whether
> it finds bugs that neither valgrind nor the gcc bounds-checking options
> can detect.
>
> For this purpose, it is useful if all functions that allocate memory
> blocks return bounds for these memory blocks that are as tight as possible.
> malloc(), realloc(), reallocarray(), alloca() already do so.
> (To convince yourself, use a C program that makes use of these functions,
> and print the return values from within gdb. gdb prints pointers with bounds.)
>
> This set of patches handles most memory allocators that we have in gnulib.

Oh, TIL. I didn't realise CHERI provided an API for this. Thank you!

I don't think this applies to gnulib, but it feels relevant enough for
me to mention it: for packages with their own allocator where they
retain a pool, it may be worth adding ASAN attributes/hooks.

Emacs did this a little while ago in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=cb242bf1514ade34ab93b1db1ea7550093ae5839
to find UAFs where the memory might get reused yet but isn't yet
returned to the underlying malloc/free impl.

>
> The API is documented in
> .
>
>
> 2023-11-11  Bruno Haible  
>
>   malloca: Take advantage of CHERI bounds-checking.
>   * lib/malloca.h: Include .
>   (malloca) [CHERI]: In the stack-allocation case, return a pointer with
>   a tight lower bound and a tight upper bound.
>   * lib/malloca.c: Include .
>   (small_t) [CHERI]: Define as uintptr_t.
>   (mmalloca) [CHERI]: Return a pointer with a tight upper bound.
>   (freea) [CHERI]: Update.
>
> 2023-11-11  Bruno Haible  
>
>   safe-alloc: Take advantage of CHERI bounds-checking.
>   * lib/safe-alloc.h: Include .
>   (safe_alloc_realloc_n): When count or size is 0, return a pointer whose
>   bounds are of size 0, not 1.
>
> 2023-11-11  Bruno Haible  
>
>   ialloc: Take advantage of CHERI bounds-checking.
>   * lib/ialloc.h: Include .
>   (irealloc): When s is 0, return a pointer whose bounds are of size 0,
>   not 1.
>   (ireallocarray): When n or s is 0, return a pointer whose bounds are of
>   size 0, not 1.
>
> 2023-11-11  Bruno Haible  
>
>   eealloc: Take advantage of CHERI bounds-checking.
>   * lib/eealloc.h: Include .
>   (eemalloc): When n is 0, return a pointer whose bounds are of size 0,
>   not 1.
>   (eerealloc): Likewise.
>
> 2023-11-11  Bruno Haible  
>
>   alignalloc: Take advantage of CHERI bounds-checking.
>   * lib/alignalloc.h: Include .
>   (alignalloc): When size is 0, return a pointer whose bounds are of
>   size 0, not 1.
>
> [2. text/x-patch; 
> 0001-alignalloc-Take-advantage-of-CHERI-bounds-checking.patch]...
>
> [3. text/x-patch; 
> 0002-eealloc-Take-advantage-of-CHERI-bounds-checking.patch]...
>
> [4. text/x-patch; 
> 0003-ialloc-Take-advantage-of-CHERI-bounds-checking.patch]...
>
> [5. text/x-patch; 
> 0004-safe-alloc-Take-advantage-of-CHERI-bounds-checking.patch]...
>
> [6. text/x-patch; 
> 0005-malloca-Take-advantage-of-CHERI-bounds-checking.patch]...

Build failure with

[Sam James]

Hello,

Forwarding a downstream report at https://bugs.gentoo.org/913368
of coreutils-9.4 failing to build with openssl-1.1.x:
"""
x86_64-pc-linux-gnu-gcc  -I. -I./lib  -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H 
-Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe 
-frecord-gcc-switches -fno-diagnostics-color -fmessage-length=0 -c -o 
src/b2sum-digest.o `test -f 'src/digest.c' || echo './'`src/digest.c
In file included from src/digest.c:41:
./lib/md5.h:36:12: fatal error: openssl/configuration.h: No such file or 
directory
   36 | #  include 
  |^
compilation terminated.
"""

This appears to have been introduced with gnulib commit
a436f5f498d7e747864d40d4450fa8330dd44d12.

configuration.h is only available with >=openssl-3.

thanks,
sam

Re: [PATCH 1/4] manywarnings: omit -fno-common in GCC 10+

[Sam James]

Paul Eggert  writes:

> * m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC): Omit -fno-common
> in GCC 10 and later, as it is the default there.

I think this is fine, but I'd note that (to my surprise),
nixpkgs inverted this default for a while.

But I don't think that changes what you should do here.


signature.asc
Description: PGP signature

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Sam James]

Bruno Haible  writes:

> Paul Eggert wrote:
>> > How about a middle ground between the two macros? A macro, say
>> > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
>> >- like AC_SYS_YEAR2038, has the option --disable-year2038,
>> >- like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
>> >  unavailable and --disable-year2038 was not specified.
>> 
>> Even simpler, let's have just one new macro instead of two. I.e., let's 
>> change Autoconf to remove AC_SYS_YEAR2038_REQUIRED and to define instead 
>> a macro AC_SYS_YEAR2038_OPT_OUT that acts like AC_SYS_YEAR2038 except it 
>> errors out if wide time_t and --disable-year2038 are both missing.
>> 
>> Then let's propagate this change into Gnulib, and rename Gnulib's 
>> year2030-required module to year2038-opt-out.
>
> I like this. Thanks.

Thanks for bringing this up Bruno. This is a reasonable compromise to me
- not just in the change here, but in the documentation/phrasing tweak
as I was concerned about the rather forthright recommendation & presentation of
year2038-required.

>
> And if the package would very much like to assume a wide time_t and
> therefore has some test suite failures if --disable-year2038 was specified,
> so be it. It's better to be able to build a package at all, with some
> test suite failures, than not being able to build it at all.
>

I feel on the fence about this bit: I think it's reasonable to provide
a macro to require it as a last resort for people, but on the other
hand, providing it might be seen to encourage it as a reasonable
solution, when in most cases, it's not that way at all,
so I'll go with however the majority feels on that.

>> Similarly for AC_SYS_LARGEFILE_REQUIRED.

... and this.

>
> For the sake of symmetry between the two, that makes sense.
>

Thanks Paul as well.

best,
sam


signature.asc
Description: PGP signature

Re: coreutils-9.1.198-e68b1.tar.xz on Linux/sparc64

[Sam James]

Bruno Haible  writes:

> Hi Sam,

Hi Bruno,
>
>> The test-pthread-cond test fails for me.
>> 
>> gnulib-tests/test-pthread-cond.log doesn't have much detail:
>> ```
>> Starting test_pthread_cond_wait ... OK
>> Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
>> status: 134)
>> ```
>
> Is it reproducible?

I managed to hit it once again just now with make check -j256, but
when I ran manually with 'make check' in gnulib-tests, and then ran
the individual test too, it passed repeatedly, so...

>
> I'm asking because on the two Linux/sparc64 machines I have access to,
> this test succeeds.
>
> - Machine 1: Debian EGLIBC 2.13-38+deb7u10, Debian 7.11
>   FAIL: test-fnmatch
>   FAIL: test-getcwd.sh
> - Machine 2: Debian GLIBC 2.24-9
>   All gnulib-tests pass.
>
> This is both in 32-bit mode and in 64-bit mode.
>
> Could it be that your machine was overloaded and thus slow when you ran
> the tests?

... I suspect you're right, and we needn't worry. Thank you!

>
> Bruno



signature.asc
Description: PGP signature

coreutils-9.1.198-e68b1.tar.xz on Linux/sparc64

[Sam James]

The test-pthread-cond test fails for me.

gnulib-tests/test-pthread-cond.log doesn't have much detail:
```
Starting test_pthread_cond_wait ... OK
Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
status: 134)
```

Access to the machine is available if needed.

best,
sam


signature.asc
Description: PGP signature

Re: functions with empty parameter lists

[Sam James]

> On 7 Feb 2023, at 12:06, Bruno Haible  wrote:
> 
> Thanks Paul, for reviewing what I wrote.
> 
> Paul Eggert wrote:
>>>   * We should stop compiling with -Wstrict-prototypes and instead (not 
>>> always,
>>> but frequently enough) compile with the '-std=gnu23' option. Clang
>>> currently implements it better. GCC 13 may be on par with clang again on
>>> this topic [1].
>> 
>> We could have 'configure' check -Wstrict-prototypes specially. If the
>> compiler complains about the abovementioned style, 'configure' would
>> omit -Wstrict-prototypes; otherwise it could keep it. The idea is that
>> eventually GCC will be smart enough so that 'gcc -Wstrict-prototypes'
>> will do the right thing even when not in C23 mode.
> 
> Hmm, that would mean that GCC's implementation of -Wstrict-prototypes,
> for older -std=... options, would change from GCC 12 to GCC 13. I doubt
> they will want to do this. Therefore I filed another GCC bug report:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
> 
> (since https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108690 has already
> been closed).

Thank you for doing this. I suspected we needed one
At 
https://discourse.llvm.org/t/unresolved-issues-from-the-llvm-15-x-release/66071/40.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: coreutils/gnulib - fts.c dangling pointers & gcc 13.1

[Sam James]

> On 4 Feb 2023, at 22:03, Paul Eggert  wrote:
> 
> On 2023-02-04 12:23, Sam James wrote:
>> I guess it's hard for me to say given I don't know what options allowed it 
>> to be reproduced and I couldn't hit it.
>> I assumed it must have been -Wstrict-aliasing=2 or lower which makes it more 
>> aggressive at the risk of false positives.
>> But if you reproduced it, then it's useful, I suppose.
> 
> I didn't reproduce the warning, since I lack GCC "13.1". I merely looked at 
> the Gnulib source and noticed a couple of places where it was not conforming 
> to the C standard.  I have enough knowledge of GCC internals that I think 
> I've changed the code so that it will pacify GCC "13.1".
> 
> Although the updated code still doesn't conform, it should work fine on real 
> platforms. (The old code probably works too, for what it's worth.)

Alright, thanks for explaining - I follow now, cheers.

Maybe we'll get more information from the original reporter too.


signature.asc
Description: Message signed with OpenPGP

Re: coreutils/gnulib - fts.c dangling pointers & gcc 13.1

[Sam James]

> On 4 Feb 2023, at 20:20, Paul Eggert  wrote:
> 
> On 2023-02-04 11:53, Sam James wrote:
>> I'd consider using #pragma GCC ... to suppress -Wuse-after-free
>> for the "problematic" lines instead. It'd avoid the risk of either 
>> optimisations or sanitisers
>> respectively causing us pain in future.
> 
> I don't see why that pragma would avoid those problems. All it would do is 
> shut off the warnings; GCC's underlying analyses would be the same, and GCC 
> would generate the same machine code. In that sense these warnings are useful 
> - they're canaries in the coal mine.

I guess it's hard for me to say given I don't know what options allowed it to 
be reproduced and I couldn't hit it.

I assumed it must have been -Wstrict-aliasing=2 or lower which makes it more 
aggressive at the risk of false positives.

But if you reproduced it, then it's useful, I suppose.


signature.asc
Description: Message signed with OpenPGP

Re: coreutils/gnulib - fts.c dangling pointers & gcc 13.1

[Sam James]

> On 4 Feb 2023, at 18:46, Paul Eggert  wrote:
> 
> I manually inspected fts.c to look for violations of the C standard that 
> might draw GCC's attention, and installed the attached patches into Gnulib. 
> As you can see, they don't fix the technical violations of the C standard. 
> However, I hope they keep GCC happy. Please give them a try with "GCC 
> 13.1".<0001-fts-pacify-GCC-13-Wuse-after-free.patch><0002-fts-pacify-GCC-12-Wstrict-aliasing.patch>

For what it's worth, with GCC 13.0.1 20230129, I get no warnings with 
--enable-gcc-warnings,
and the test suite passes. Ditto =expensive.

But I don't get any with the previous commits either :)

As for the patches, I'd consider using #pragma GCC ... to suppress 
-Wuse-after-free
for the "problematic" lines instead. It'd avoid the risk of either 
optimisations or sanitisers
respectively causing us pain in future.



signature.asc
Description: Message signed with OpenPGP

Re: coreutils/gnulib - fts.c dangling pointers & gcc 13.1

[Sam James]

> On 3 Feb 2023, at 22:11, Paul Eggert  wrote:
> 
> On 2023-02-03 12:24, Peter Frazier wrote:
>> dangling pointers & gcc 13.1
>> problem with:
>> coreutils/gnulib, fts.c
>> compilation failure:
>> -Werror=use-after-free error
>> approach to resolution (thus far):
>> post free of vars, I set the vars to NULL, but it did not help
> 
> Could you be more specific about the symptoms you observed, and how to 
> reproduce them? For one thing, GCC 13.1 has not been released yet, as far as 
> I can see.
> 

Yes, we need the full build log, and the commands run to obtain them. GCC 13 
has not yet been
released so we need the 'gcc -v' output too.


signature.asc
Description: Message signed with OpenPGP

Re: Making _Noreturn a no-op in < Clang 16?

[Sam James]

> On 20 Jan 2023, at 03:40, Paul Eggert  wrote:
> 
> On 1/19/23 13:30, Sam James wrote:
>> Right, I just meant that we don't tend to care about quieting warnings with 
>> older compilers,
>> and it's not useful from a static analysis perspective here either given 
>> that older Clangs can't be trusted.
>> It is of course useful as an attribute in general. I don't think either of 
>> these things are really
>> a downside to committing the workaround here. If we get folks who get build 
>> failures with extra warnings
>> enabled, we can tell them to upgrade their compiler.
> 
> But clang 16 isn't out yet, so we can't reasonably tell people to upgrade.
> 
> And even if it clang 16 were out, I can't reasonably tell all Emacs 
> developers to switch to it right away. Many of them are using Apple's 
> compiler and will upgrade whenever. Plain './configure; make' on a 
> bleeding-edge Emacs built from Git with Clang 15 would generate 270 false 
> alarms if we simply did "#define _Noreturn /**/", and I expect many Emacs 
> developers would be annoyed by that (or would stop paying attention to any 
> correct diagnostics mixed in with the flood of false positives).
> 

I take your point and it's fair enough. Thanks for hashing it out with me.

> With that in mind, how about the attached Gnulib patch? (I haven't installed 
> it.) The basic idea is to "#define _Noreturn /**/" on buggy clangs if a 
> cautious builder compiles with 
> -D_GL_WORK_AROUND_LLVM_BUG_5979.<0001-snippet-_Noreturn-work-around-Clang-_Noreturn-bug.patch>

If it's not too much of a hassle, this works for me, because at least we 
advertise the problem a bit, and we can tell distros
to set -D_... if they're stuck on older Clang for a bit.

Cheers Paul.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Making _Noreturn a no-op in < Clang 16?

[Sam James]

> On 19 Jan 2023, at 21:20, Paul Eggert  wrote:
> 
> On 1/19/23 12:44, Sam James wrote:
>> _Noreturn is pretty much just an optimisation (and I'm not convinced that 
>> it's _needed_  in a lot of cases, rather just a useful hint).
> 
> _Noreturn is not just an optimization: it's also useful for static checking. 
> For example:
> 
>  int
>  f (int x)
>  {
> if (x < INT_MAX)
>   return x + 1;
> error (1, 0, "x is too large");
>  }
> 
> Since error is _Noreturn the compiler knows not to warn that F might return 
> garbage. It's useful to suppress false alarms, even when Clang is the 
> compiler.
> 

Right, I just meant that we don't tend to care about quieting warnings with 
older compilers,
and it's not useful from a static analysis perspective here either given that 
older Clangs can't be trusted.

It is of course useful as an attribute in general. I don't think either of 
these things are really
a downside to committing the workaround here. If we get folks who get build 
failures with extra warnings
enabled, we can tell them to upgrade their compiler.


signature.asc
Description: Message signed with OpenPGP

Re: Making _Noreturn a no-op in < Clang 16?

[Sam James]

> On 19 Jan 2023, at 04:17, Paul Eggert  wrote:
> 
> The problem we found in Gawk was that this sort of function call:
> 
>(b ? f : g) (x)
> 
> is mishandled by Clang < 16 when one function is _Noreturn and the other 
> isn't, in that Clang mistakenly treats the call as if both functions are 
> _Noreturn.
> 
> I expect this sort of issue to be reasonably rare in practical C code, as 
> most people don't write code like the above, and when they do then typically 
> F is _Noreturn if and only if G is also _Noreturn. So I've held off on doing 
> the more-drastic "#define _Noreturn /*empty*/" for Clang < 16 in Gnulib, as 
> my guess has been that the advantages of enabling _Noreturn on Clang < 16 are 
> greater than the disadvantages given the rarity of situations like the above.
> 

I don't have any sort of statistics on this either. _Noreturn is pretty much 
just an optimisation (and I'm not convinced that it's _needed_ in a lot of 
cases, rather just a useful hint). I'd rather
a correct result than a quicker one. But then again, you could argue that given 
nobody noticed for at least 13 years (including with several Linux distros 
building gawk with Clang), it's
not a big deal in the wild.

(err() is noreturn anyway so I'd expect the compiler to be able to deduce it.)

Up to you. I think the conservative option is to do it, but if you feel 
uncertain, we can probably just leave the matter. Is there any precedent wrt
handling miscompilations for actively supported compilers in gnulib and such?


signature.asc
Description: Message signed with OpenPGP

Making _Noreturn a no-op in < Clang 16?

[Sam James]

Hi all,

Over on bug-gawk, we ended up finding that Clang was miscompiling certain
expressions involving _Noreturn. This is fixed in Clang's git repo but not
in any released version. It should be in 16.0.

Paul suggested [0] that gnulib ought to #define _Noreturn to blank
for known-broken Clang versions, especially given finding such
broken patterns isn't easy.

This seems like a reasonable path forward. I'm concerned about
gnulib versions in various released bits of GNU software (diffutils
just got a release, for example) without this workaround in.

What do you think?

[0] https://lists.gnu.org/archive/html/bug-gawk/2023-01/msg4.html

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Clang-built Gawk 5.2.1 regex oddity

[Sam James]

> On 5 Jan 2023, at 23:06, Arsen Arsenović  wrote:
> 
> Hi,
> 
> Paul Eggert  writes:
> 
>> This is a serious bug in Clang: it generates incorrect machine code.
>> 
>> The code that Clang generates for the following (gawk/support/dfa.c lines
>> 1141-1143):
>> 
>>((dfa->syntax.dfaopts & DFA_CONFUSING_BRACKETS_ERROR
>>  ? dfaerror : dfawarn)
>> (_("character class syntax is [[:space:]], not [:space:]")));
>> 
>> is immediately followed by the code generated for the following
>> (gawk/support/dfa.c line 1015):
>> 
>>dfaerror (_("invalid character class"));
>> 
>> and this is incorrect because the two source code regions are not connected
>> with each other.
> 
> This is now fixed in Clang:
> https://reviews.llvm.org/rGcf8fd210a35c8e93136cb8edc5c6a2e818dc1b1d

This is not in 15.0.7 and there won't be any further 15.x releases as there's
an ABI break caused by it. We've backported it in Gentoo but others may not.

It will be in 16.x.

I think gnulib should probably make that #define change for Clang < 16.




signature.asc
Description: Message signed with OpenPGP

Re: Clang-built Gawk 5.2.1 regex oddity

[Sam James]

> On 3 Jan 2023, at 02:14, Sam James  wrote:
> 
> 
> 
>> On 2 Jan 2023, at 06:10, Paul Eggert  wrote:
>> 
>> This is a serious bug in Clang: it generates incorrect machine code.
>> 
>> [snip]
>> 
>> My guess is that Clang got confused because dfaerror is declared _Noreturn, 
>> so Clang mistakenly assumed that dfawarn is also _Noreturn, which it is not.
>> 
>> I worked around the Clang bug by installed the attached patch into Gnulib. 
>> Please give it a try with Gawk.
> 
> Confirmed this mitigates the problem. I had to apply it manually to support/ 
> as I couldn't immediately see how to sync gnulib myself, but that's no big 
> deal.
> 
>> 
>> Incorrect code generation is a serious bug in Clang; can you please report 
>> it to the Clang folks? I am considering using a bigger hammer, and doing 
>> this:
>> 
> 
> Kenton's done this at https://github.com/llvm/llvm-project/issues/59792 now.
> 
>>  #define _Noreturn /*empty*/
>> 
>> whenever Clang is used, until the bug is fixed.
>> 
> 
> maskray's analysis so far at 
> https://github.com/llvm/llvm-project/issues/59792#issuecomment-1369314436 
> agrees with yours, which would mean
> this is likely a good idea.
> 

By the way, when I ran gnulib's test suite following 
https://sourceware.org/glibc/wiki/Testing/Gnulib, I didn't get any failures
with Clang. I was expecting to get one (before your commit) for DFA.

Maybe we should shoehorn a similar ternary expression into 
tests/test-dfa-match-aux.c so we're guaranteed
a test failure with bad compilers if someone uses the DFA module?


signature.asc
Description: Message signed with OpenPGP

Re: Clang-built Gawk 5.2.1 regex oddity

[Sam James]

> On 2 Jan 2023, at 06:10, Paul Eggert  wrote:
> 
> This is a serious bug in Clang: it generates incorrect machine code.
> 
> [snip]
> 
> My guess is that Clang got confused because dfaerror is declared _Noreturn, 
> so Clang mistakenly assumed that dfawarn is also _Noreturn, which it is not.
> 
> I worked around the Clang bug by installed the attached patch into Gnulib. 
> Please give it a try with Gawk.

Confirmed this mitigates the problem. I had to apply it manually to support/ as 
I couldn't immediately see how to sync gnulib myself, but that's no big deal.

> 
> Incorrect code generation is a serious bug in Clang; can you please report it 
> to the Clang folks? I am considering using a bigger hammer, and doing this:
> 

Kenton's done this at https://github.com/llvm/llvm-project/issues/59792 now.

>   #define _Noreturn /*empty*/
> 
> whenever Clang is used, until the bug is fixed.
> 

maskray's analysis so far at 
https://github.com/llvm/llvm-project/issues/59792#issuecomment-1369314436 
agrees with yours, which would mean
this is likely a good idea.



signature.asc
Description: Message signed with OpenPGP

-Wlto-type-mismatch warning in error()

[Sam James]

Hi,

Compiling texinfo 7.0.1 with CFLAGS="-O2 -flto -Werror=lto-type-mismatch" 
results
in the following:
```
make[3]: Entering directory 
'/var/tmp/portage/sys-apps/texinfo-7.0.1/work/texinfo-7.0.1/install-info'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../gnulib/lib 
-I../gnulib/lib -DLOCALEDIR=\"/usr/share/locale\"   -O2 -flto 
-Werror=lto-type-mismatch -O2 -flto -Werror=lto-type-mismatch -ggdb3 
-Werror=implicit-function-declaration -Werror=implicit-int -c -o install-info.o 
install-info.c
x86_64-pc-linux-gnu-gcc  -O2 -flto -Werror=lto-type-mismatch -O2 -flto 
-Werror=lto-type-mismatch -ggdb3 -Werror=implicit-function-declaration 
-Werror=implicit-int  -Wl,-O1 -Wl,--as-needed 
-Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,-z,pack-relative-relocs -o 
ginstall-info install-info.o ../gnulib/lib/libgnu.a
../gnulib/lib/error.h:33:13: error: type of ‘error’ does not match original 
declaration [-Werror=lto-type-mismatch]
   33 | extern void error (int __status, int __errnum, const char *__format, 
...)
  | ^
install-info.c:218:1: note: type mismatch in parameter 1
  218 | error (const char *fmt, ...)
  | ^
install-info.c:218:1: note: ‘error’ was previously declared here
install-info.c:218:1: note: code may be misoptimized unless 
‘-fno-strict-aliasing’ is used
lto1: some warnings being treated as errors
lto-wrapper: fatal error: //usr/bin/x86_64-pc-linux-gnu-gcc returned 1 exit 
status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: 
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:1514: ginstall-info] Error 1
```

This is with GCC 12.2.1 20221203.

We've also seen this in GNU make, so not sure if it's a
gnulib problem or not, as it may be in lib/error.h (hence CCing bug-gnulib):
- https://bugs.gentoo.org/863713 (texinfo)
- https://bugs.gentoo.org/863824 (make)

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH silence -Wdeprecation-warning for sprintf on macOS] silence sprintf deprecation warning

[Sam James]

> On 25 Nov 2022, at 22:25, Bruno Haible  wrote:
> 
> Minsoo Choo wrote:
>> sprintf is deprecated on macOS. Silence this warning by silencing
>> -Wdeprecated-declartions.
> 
> I don't get a warning by compiling the 'vasnprintf-posix' module
> on macOS 12.6, even with -Wall -Wdeprecated-declarations.
> 
> What OS are you on, what are you compiling, and what are the values
> for CC, CFLAGS, and CPPFLAGS that you have provided?

13.0 is needed - see 
https://lists.gnu.org/archive/html/bug-gnulib/2022-11/msg00013.html.

> 
> Bruno
> 


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 16 Nov 2022, at 15:27, Richard Biener  wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc  wrote:
>> 
>> Hey,
>> 
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>> 
 The idea is so obvious that I'm probably missing something, why autoconf
 can't use that idiom instead.  But perhaps the (historic?) reasons why it
 couldn't be used are gone now?
>>> 
>>> Ironically, modern GCC and LLVM optimize ' != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>> 
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>> 
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
> 
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
> 
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
>  |  ^~
> t.c:1:1: note: 'printf' is declared in header ''
>  +++ |+#include 
>1 | char printf(void);
> 
> so without -Werror this should be fine.
> 
Unrelated but I was a bit tempted to ask for throwing in 
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the 
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.

> Richard.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 15 Nov 2022, at 13:30, Zack Weinberg  wrote:
> 
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
>>> 
>>> Although there will be problems with people who run "./configure 
>>> CFLAGS='-Werror'", that sort of usage has always been problematic and 
>>> unsupported by Autoconf, so we can simply continue to tell people "don't do 
>>> that".
>>> 
>> 
>> Is there somewhere in the autoconf docs we actually say this?
>> 
>> I've seen a few instances of folks adding it themselves very
>> early in their configure scripts (which is a pain for distros
>> anyway) which then ends up affecting the rest.
> 
> It's mentioned in the NEWS entry for 2.70: 
> https://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS#n170

Thanks, sorry, I didn't think to check NEWS. This is good enough for me to link 
folks to, anyway, for the time being.

> Note that there have been bug reports for cases where running builds with 
> more warnings than configure uses (and I think also -Werror), means that 
> configure checks spuriously succeed (i.e. configure reports that something is 
> available, but then you get compiler errors on the code that tries to use 
> it).  I can't remember any concrete examples right now, though.

I can totally imagine that, don't stress about the examples.



signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 21:31, Paul Eggert  wrote:
> 
> On 2022-11-12 12:23, Wookey wrote:
>> we can't just have everyone who enabled LFS sometime in the
>> last 20 years suddenly being forced into the time_t change (can we?)
> 
> We've done it in the past.
> 
> AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. 
> Originally it affected only off_t; its effect on other types like ino_t came 
> later. Hence people who initially used AC_SYS_LARGEFILE were later "suddenly 
> forced" into an ino_t width change. Similarly for other non-off_t types that 
> AC_SYS_LARGEFILE affects.
> 
> So there's longstanding precedent for AC_SYS_LARGEFILE changing the width of 
> system types that were formerly unaffected. The difference is that time_t is 
> more widely used than ino_t etc., and people are understandably more 
> concerned about time_t changes.
> 

Thanks, that's a helpful bit of history I wasn't aware of there.

> 
> Because of the concerns raised in this thread it's become clear that what's 
> in Autoconf now is too drastic, and I've proposed (though not yet 
> implemented) a change that will cause AC_SYS_LARGEFILE to continue to not 
> affect time_t unless there's an affirmative request like "./configure 
> --enable-year2038". I am waiting for feedback on that from Zack and others, 
> and am hoping for quick turnaround on this because we do need a new Autoconf 
> release.
> 
> 

Sorry, I missed this until now.

That would work well for me too. It's fine for me at least if the same macro 
just haas additional compatibilities, even if a bit confusing
at first.

As for further changes (as the original post wasn't exclusive to autoconf),
I await comment from other glibc maintainers as I still feel like we're
pretty stuck about how to handle this overall. But your suggestion
(or zw's patch) puts out or dampens the autoconf fire at least.

Thanks for helping come to a compromise. I know this isn't
a simple or easy topic at all.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
> 
> On 2022-11-11 07:11, Aaron Ballman wrote:
>> We believe the runtime behavior is sufficiently dangerous to
>> warrant a conservative view that any call to a function will be a call
>> that gets executed at runtime, hence a definitive signature mismatch
>> is something we feel comfortable diagnosing (in some form) by default.
> 
> As long as these diagnostics by default do not cause the compiler to exit 
> with nonzero status, we should be OK with Autoconf-generated 'configure' 
> scripts. Although there will be problems with people who run "./configure 
> CFLAGS='-Werror'", that sort of usage has always been problematic and 
> unsupported by Autoconf, so we can simply continue to tell people "don't do 
> that".
> 

Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha 
>  wrote:
> 
> Sam James  writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer  wrote:
>>> We need to support legacy binaries on i386.  Few libraries are
>>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>>> distributions, no one is going to do that work, and we have to stick to
>>> whathever we are building today.
>> 
>> While I agree, I don't think it's as well-known that it should be that
>> these are ABI breaking and require inspection. It's being done ad-hoc
>> or in many cases, not at all.
> …
>>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>>> contains two changes of note [2][3]
>>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>>> 
>>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>>> "supported" by glibc right now is untenable.
>>> 
>>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>>> for Fedora unfortunately.
>>> 
>>> I thought the gnulib change has been reverted?
>>> 
>>> I really wish the rest of GNU would talk to glibc maintainers before
>>> overriding glibc maintainer decisions.
> 
> There seems to be a disconnect between Paul Eggert’s position on these
> changes and everyone else on this thread’s position.
> 
> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.
> If an application is being built on the machine where it’ll be used, and
> both it and the system support building it with 64-bit time_t and off_t,
> *why wouldn’t you*?  It has no impact on anything else to do that, and
> it future-proofs your installataion.
> 
> But everyone else is worrying about cases where, either, an application
> is built with 64-bit time_t and/or off_t and then copied to a different
> system where the underlying libraries *don’t* support that, or a *shared
> library* is rebuilt with 64-bit time_t and/or off_t and that silently
> changes its ABI out from under programs that use it.
> 

Precisely.

> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)
> 
> (It’s also unfortunate that, 20+ years after the invention of ELF symbol
> versioning, it’s still ridiculously difficult.  So many macros and
> assembly hacks and fighting with libtool.  But I digress.)
> 
> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
> in order to unblock C23 testing — am I correct?  It doesn’t resolve the
> larger issue, but it gives us more time to think about what the
> resolution ought to be.
> 
> What do you think?

This is really I think the best option while allowing us time & space
to complete the larger discussion.

We keep AC_SYS_YEAR2038 which lets upstreams opt in,
but it avoids the risk of sudden LFS-into-time64 rollover.

Year 2038 work is really important (which is why I brought
up the topic) but I don't want confusion around it to make
people avoid adopting 2.72 or leave us without a 2.72
at all.

I do sympathise with Paul's position, but I'm not
a believer in piecemeal anyway now and it's fair to say there's no
consensus on this yet.

Paul's point Is fair that distros who wish can set the cache var to
ff, so *if* you and Paul want to keep it in.

I could live with a bigger "please check this!" in NEWS. I don't think it's a
total disaster as long as we brief distros first, as we're already
doing it for gnuilb & upstreams may well end up doing themselves,
so the train is on its way out of the station anyway.

(I think we need to keep the discussion going on that front,
but I think it'd be wrong to let it block this release, as it's
not a simple problem and I'm still unsure how I fully feel
about the issues 

Re: On time64 and Large File Support

[Sam James]

> On 11 Nov 2022, at 09:19, Florian Weimer  wrote:
> 
> * Sam James:
> 
>> In Gentoo, we've been planning out what we should do for time64 on
>> glibc [0] and concluded that we need some support in glibc for a newer
>> option. I'll outline why below.
>> 
>> Proposal: glibc gains two new build-time configure options:
>> * --enable-hard-time64
>> * --enable-hard-lfs
> 
> We should define new target triplets for this if it's really required.

I hadn't considered that option. I'll reflect on it. Please let me know
if you have further thoughts on this.

But that said, these binaries are broken anyway in 2038?

> We need to support legacy binaries on i386.  Few libraries are
> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis.  For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.

While I agree, I don't think it's as well-known that it should be that
these are ABI breaking and require inspection. It's being done ad-hoc
or in many cases, not at all.

Part of the use of this thread is, if nothing else, we can show upstreams
and other distros It if they're confused.

It's very easy to miss that a package has started enabling LFS
and then your opportunity to catch the ABI breakage is gone.

It doesn't help that I (and I suspect most distribution maintainers)
do all development on x86_64 and hence even ABI diffing isn't
going to notice. You have to specifically diff the build system, which I
do, but it's not easy if it's buried deep within gnulib or something.

> 
>> These would hard-enable the relevant #defines within glibc's headers
>> and ensure that any binaries built with such a glibc have both Large
>> File Support (LFS) and time64 support.
>> 
>> I've come to the conclusion it's infeasible to try handle the
>> migration piecemeal. Various mismatches can and will occur (and while
>> it's more likely with time64, it's possible with LFS too) [1].
>> 
>> We're now (possibly) on the eve of an autoconf 2.72 release which contains 
>> two changes
>> of note [2][3]
>> 1. addition of a new AC_SYS_YEAR2038 macro;
>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>> 
>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>> wget/gnutls breaking [1]. I feel this shows that the only approach
>> "supported" by glibc right now is untenable.
> 
> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
> 
> I thought the gnulib change has been reverted?
> 
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.
> 

Right, we need to be unified on this, because it's confusing enough
without unilateralism.



signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 10 Nov 2022, at 17:16, Zack Weinberg  wrote:
> 
> I’m the closest thing Autoconf has to a lead maintainer at present.
> 
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.

Thank you for asking. The fixes in git get us there, I think, as far
as you can, with the exception of the stuff you (and I) mention below.

> 
> [...]
> 
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.
> 
> How important do you think it is for this to be fixed?
> 
> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

This might be a WONTFIX but let me mention it just for
the record:
1. AC_CHECK_FUNCS is, as you've noticed, very noisy.

I would support having a hardcoded list for certain CHOSTs
as Rich suggests to reduce noise, but I don't think we can
do this accurately very quickly.

I think for Gentoo's efforts, I might just build up a set
of cache variables for glibc/musl on each arch to
reduce the noise in logs. But that's time consuming
and brittle still, so I'm not sure.

(Note that Gentoo and Fedora are taking two complementary
but different approaches here:
we're diffing config.logs and other compiler
output, in addition to build logs, while Florian for Fedora
Is building a list of functions which *we know* are available
In a specific environment and patching gcc to spit out
logs when something in said list is missing. This mitigates
noise for things like functions in libbsd, which I'm finding
a bit of a pain.)

I'll see what others say.

2. I often have to set the following cache variables to
reduce noise in logs:
* ac_cv_c_undeclared_builtin_options="none needed"
* ac_cv_header_sys_types_h_makedev=no
* gl_cv_compiler_check_decl_option="-Werror=implicit-function-declaration" 
(obviously this is gnulib)
* gl_cv_minmax_in_limits_h=no

I don't know if we can do anything to make these tests smarter
or just leave it as-is. It's fine if we can't, as exporting the cache
vars is not a bad workaround for us when doing testing.

> 
> zw
> 
> p.s. GCC and Clang folks: As long as you’re changing the defaults out
> from under people, can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX modes?

I support this as well. This kind of thing has led to endless
bugs in userland, see https://reviews.llvm.org/D137511.



signature.asc
Description: Message signed with OpenPGP

Re: Creating a formula for Homebrew

[Sam James]

> On 25 Aug 2022, at 15:53, dmitrii.pasech...@cs.ox.ac.uk wrote:
> 
> On Thu, Feb 08, 2018 at 11:43:08AM +0100, Bruno Haible wrote:
>> Wesley Viana wrote:
>>> So I was wondering how to contribute by "packing" gnulib into a brew
>>> formula.
>> 
>> Packaging gnulib through a packaging system (such as Debian, pkg, BSD ports,
>> or brew) is, in the current state of things, not desirable.
>> 
>> Gnulib is a source code library [1], and, although the documentation states
>> that the user has the choice between using the git repo and stable releases 
>> [2],
>> there have not been such stable releases for 4 years. That is, everyone uses
>> the git repo. And we are taking QA steps to ensure a high quality of the
>> code in the git repo.
> 
> I don't think this is how gnulib is usually used, and that's why regular
> releases are badly needed.
> By the way, several Linux distributions, e.g. Debian and Gentoo, do provide
> gnulib packages (updated at random moments).

Note that while Gentoo does have a gnulib package, it's mostly there
for esoteric reasons, and we don't use it in builds of packages.

So, we don't use it in builds, but I wish we could.

I do wish there was a way to unbundle it but that would require
solid versioning of gnulib. Right now, there's often (seemingly)
API breaks which mean consumers have to be adapted.

Often, bugs occur in e.g. coreutils which involve patching
gnulib rather than coreutils itself. It's even more frustrating
when fixing a build failure on e.g. a new platform
that has its roots in gnulib and we have to patch every
single gnulib consumer until they: 1. pull down a new gnulib,
And 2. make new releases (which might be years).

Best,
sam



signature.asc
Description: Message signed with OpenPGP

Re: [PATCH] sigsegv: Fix build on ppc/musl

[Sam]

> On 13 Mar 2022, at 14:17, Bruno Haible  wrote:
> 
> Eric Blake wrote:
>> On Wed, Mar 09, 2022 at 11:37:14PM -0800, Khem Raj wrote:
>>> mcontext is not a standard layout so glibc and musl differ sadly.
>>> 
>>> Fixes
>>> ../../m4-1.4.19/lib/sigsegv.c: In function 'sigsegv_handler':   
>>> 
>>> ../../m4-1.4.19/lib/sigsegv.c:223:75: 
>>> error: 'mcontext_t' has no member named 'uc_regs'; did you mean 'gregs'?
>>> 
>>> 223 | #define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) 
>>> ucp)->uc_mcontext.uc_regs->gregs[1] 
>>>   | 
>>>   ^~~
>> 
>> Thanks for the report.  As this file comes from gnulib, the fix needs
>> to go there first.
> 
> Thanks for the report. I'm adding this patch to GNU libsigsegv:
> https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=commitdiff;h=a6ff69873110c0a8ba6f7fd90532dbc11224828c
> 
> and then this (derived) patch to Gnulib.
> 
> I couldn't verify that it works, since there is no Linux distro that is based
> on musl libc and is ported to Linux/powerpc (32-bit).

There's at least Gentoo, Adélie, and at least for now, Void.

Thanks for adding the patch and thanks to Khem for reporting it.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: c-stack test fails on SPARC

[Sam James]

> On 3 Feb 2021, at 03:45, Sam James  wrote:
> [snip]


>> What's the result of
>> grep LIBCSTACK config.status
>> ? I.e. is GNU libsigsegv in use? And if yes, which version?
> 
> # grep LIBCSTACK config.status
> S["LTLIBCSTACK"]=""
> S["LIBCSTACK"]=""
> 
> So no, I think.
> 
> I then installed GNU libsigsegv 2.12, reran configure, and `make`, then `make 
> check` passed!
> 

For good measure, yes, it did indeed detect it once installed:
# grep LIBCSTACK config.status
S["LTLIBCSTACK"]="-lsigsegv"
S["LIBCSTACK"]="-lsigsegv"

>> [snip]
>> 

Thanks,
Sam



signature.asc
Description: Message signed with OpenPGP

Re: c-stack test fails on SPARC

[Sam James]

Hi,

> On 3 Feb 2021, at 03:23, Bruno Haible  wrote:
> 
> Hi,
> 

Hey, thanks for the quick reply.

> What's the result of
>  grep LIBCSTACK config.status
> ? I.e. is GNU libsigsegv in use? And if yes, which version?

# grep LIBCSTACK config.status
S["LTLIBCSTACK"]=""
S["LIBCSTACK"]=""

So no, I think.

I then installed GNU libsigsegv 2.12, reran configure, and `make`, then `make 
check` passed!

Manually:
# ./test-c-stack
test-c-stack: stack overflow

> Also, it would be helpful to know
>  - the version of Linux (from 'uname srm'),
>  - the libc version,
>  - whether the 'test-c-stack' is a 32-bit or 64-bit executable.
> 

# uname -srm
Linux 5.9.6-gentoo sparc

I’ll see about getting a newer kernel.

I’m using glibc (glibc-2.32-r6) which is 2.32 with some backports applied [0].

# file test-c-stack
test-c-stack: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, 
version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux.so.2, for 
GNU/Linux 3.2.0, with debug_info, not stripped

[0] https://gitweb.gentoo.org/fork/glibc.git/log/?h=gentoo/2.32

> Bruno
> 



signature.asc
Description: Message signed with OpenPGP

c-stack test fails on SPARC

[Sam James]

Hi,

This issue was noticed through grep 3.5 and 3.6’s stack-overflow test failing 
[0] on SPARC on Gentoo GNU/Linux.

Following Paul Eggert’s instructions in that bug to test gnulib’s c-stack 
component, I had the following
in /gltests/test-suite.log:

"FAIL: test-c-stack.sh
=

./test-c-stack.sh: line 7: 3238828 Segmentation fault  (core dumped) 
${CHECKER} ./test-c-stack${EXEEXT} 2> t-c-stack.tmp
FAIL test-c-stack.sh (exit status: 1)

I didn’t get much particularly useful out of gdb yet:

Reading symbols from ./test-c-stack...
(gdb) r
Starting program: /tmp/gnulib/foo/gltests/test-c-stack

Program received signal SIGSEGV, Segmentation fault.
0x01000c64 in recurse_1 (n=, p=0x) at 
test-c-stack.c:35
35  {
(gdb) bt
#0  0x01000c64 in recurse_1 (n=, p=0x) 
at test-c-stack.c:35
#1  0x0007 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)"

The grep investigation was similar:

"(gdb) r
Starting program: /var/tmp/portage/sys-apps/grep-3.6/work/grep-3.6/src/grep -E 
-f in
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x01026908 in peek_token (token=0x1aa9f30, input=0x1aa9f30, 
syntax=1099522809648) at regcomp.c:1784
1784{
(gdb) bt
#0  0x01026908 in peek_token (token=0x1aa9f30, input=0x1aa9f30, 
syntax=1099522809648) at regcomp.c:1784
#1  0x01aa9f38 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)"

Please let me know what further information I can provide and how to better 
debug this, thanks a bunch!

[0] https://lists.gnu.org/archive/html/bug-grep/2021-02/msg0.html.

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

> * Bruno Haible  [2019-06-25 19:11:03 +0200]:
>
>> $ find . -name \*alloc\*.o
>> ./lib/allocator.o
>> ./src/alloc.o
>
> Oh, this is surprising.

aha!

I re-run gnulib-tool and it fixed it.
(alas, emacs maintainers pushed the changes before me ;-)

thanks and sorry about bothering you!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://iris.org.il http://no2bds.org http://mideasttruth.com
Do not worry about which side your bread is buttered on: you eat BOTH sides.

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

> * Bruno Haible  [2019-06-25 17:00:58 +0200]:
>
> Sam Steingold wrote:
>> I get this error when linking Emacs:
>> 
>> --8<---cut here---start->8---
>>   CCLD temacs
>> Undefined symbols for architecture x86_64:
>>   "_freea", referenced from:
>>   _rpl_realpath in libgnu.a(canonicalize-lgpl.o)
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> make[1]: *** [temacs] Error 1
>> --8<---cut here---end--->8---
>> 
>> I also reported this as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36356
>> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/msg01229.html)
>
> 1) After your latest "git pull" from emacs, have you done a "make distclean"
>followed by a reconfiguration?

no, I did "make bootstrap" which re-runs configure

> If you don't remember: Does the issue persist after a "make distclean"
> followed by a reconfiguration?

yes, I just did "make distclean; ../configure ...; make bootstrap" and
got the above error.

> 2) Which symbols does
>   nm lib/malloca.o
> show?

--8<---cut here---start->8---
$ find . -name \*alloc\*.o
./lib/allocator.o
./src/alloc.o
$ nm ./lib/allocator.o
 U _free
 U _malloc
 U _realloc
 S _stdlib_allocator
--8<---cut here---end--->8---



> If, as I would expect, it lists '_mmalloca' but not '_freea', it means
> that the macro HAVE_ALLOCA was defined in the compilation unit
> canonicalize-lgpl.c but not defined in the compilation unit malloca.c.
> Can you investigate why this is so? (Where is HAVE_ALLOCA defined? In
> config.h, I would guess. It is undefined somewhere? I would guess no.

right:
--8<---cut here---start->8---
./src/config.h:#define HAVE_ALLOCA 1
./src/config.h:#define HAVE_ALLOCA_H 1
--8<---cut here---end--->8---

> What are the preprocessor symbols that are defined [use "$CC -E
> -dM"] in the compilation unit canonicalize-lgpl.c, versus the
> compilation unit malloca.c?

--8<---cut here---start->8---
$ gcc -Isrc -I../src -E -dM ../lib/malloca.c > m
$ gcc -Isrc -I../src -E -dM ../lib/canonicalize-lgpl.c > c
$ diff -u m c|grep -i ^[-+].*alloc
+#define MAXALLOCSAVE (2 * CLBYTES)
+#define _PC_ALLOC_SIZE_MIN 16
$ diff -u m c|grep -i ^[-+].*free

--8<---cut here---end--->8---

However, I see no malloca.o in lib (where canonicalize-lgpl.o is found)
I wonder if there is some magic autoconf place where canonicalize-lgpl
is mentioned but malloca is not.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://think-israel.org http://www.memritv.org https://jihadwatch.org
He who laughs last thinks slowest.

macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

Hi,
I get this error when linking Emacs:

--8<---cut here---start->8---
  CCLD temacs
Undefined symbols for architecture x86_64:
  "_freea", referenced from:
  _rpl_realpath in libgnu.a(canonicalize-lgpl.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [temacs] Error 1
--8<---cut here---end--->8---

I also reported this as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36356
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/msg01229.html)

Since this involves libgnu, I was wondering if someone here might have
an insight.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://americancensorship.org http://mideasttruth.com
XML is like violence. If it doesn't solve the problem, use more.

no-c++.m4: bug fix: egrep: repetition-operator operand invalid

[Sam Steingold]

Hi,

On Darwin (Mac OS) the gt_NO_CXX test fails because "Is g++" is not a
valid repetition-operator operand.

The attached patch fixes the problem.

>From d5d949b838c7cf4adb0e6e615795003ac7b0f1c3 Mon Sep 17 00:00:00 2001
From: Sam Steingold <s...@gnu.org>
Date: Tue, 5 Dec 2017 11:02:33 -0500
Subject: [PATCH] Avoid the "egrep: repetition-operator operand invalid" error
 on Darwin

---
 m4/no-c++.m4 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/m4/no-c++.m4 b/m4/no-c++.m4
index ed06b22b6..b2fa0184f 100644
--- a/m4/no-c++.m4
+++ b/m4/no-c++.m4
@@ -7,14 +7,14 @@ dnl with or without modifications, as long as this notice is preserved.
 # Support for C source files that cannot be compiled by a C++ compiler.
 # Set NO_CXX to the C++ compiler flags needed to request C mode instead of
 # C++ mode.
-# So far only g++ is supported.
+# So far only g++ and clang++ are supported.
 
 AC_DEFUN([gt_NO_CXX],
 [
   NO_CXX=
-  AC_EGREP_CPP([Is g++], [
+  AC_EGREP_CPP([Is c plus plus], [
 #if defined __GNUC__ && defined __cplusplus
-  Is g++
+  Is c plus plus
 #endif
 ],
 [NO_CXX="-x c"])
-- 
2.15.1


Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
https://ffii.org http://no2bds.org https://jihadwatch.org http://camera.org
The world is coming to an end.  Please log off.

fnmatch does not compile with c++ (clang)

[Sam Steingold]

Hi,
fnmatch cannot be compiled using c++ on mac os x:

--8<---cut here---start->8---
g++ -DHAVE_CONFIG_H -I. -I../../src/gllib -I..  -I../intl 
-I/usr/local/include -I/usr/local/opt/readline/include  -W -Wswitch -Wcomment 
-Wpointer-arith -Wreturn-type -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW 
-DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY -DUNIX_BINARY_DISTRIB 
-DENABLE_UNICODE -DNO_GETTEXT   -MT fnmatch.o -MD -MP -MF $depbase.Tpo -c -o 
fnmatch.o ../../src/gllib/fnmatch.c &&\
mv -f $depbase.Tpo $depbase.Po
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is 
deprecated
In file included from ../../src/gllib/fnmatch.c:172:
../../src/gllib/fnmatch_loop.c:152:20: error: assigning to 'const char *' from 
incompatible type 'void *'
  endp = MEMCHR (n, (flags & FNM_FILE_NAME) ? L_('/') : L_('\0'),
   ^ 
../../src/gllib/fnmatch_loop.c:205:27: error: expected unqualified-id
register bool not;
  ^
../../src/gllib/fnmatch_loop.c:222:17: error: expected expression
not = (*p == L_('!') || (posixly_correct < 0 && *p == L_('^')));
^
../../src/gllib/fnmatch_loop.c:223:20: error: expected expression
if (not)
   ^
../../src/gllib/fnmatch_loop.c:864:21: error: expected expression
if (!not)
^
../../src/gllib/fnmatch_loop.c:937:20: error: expected expression
if (not)
   ^
../../src/gllib/fnmatch_loop.c:269:29: error: cannot jump from this goto 
statement to its label
goto normal_bracket;
^
../../src/gllib/fnmatch_loop.c:424:26: note: jump bypasses variable 
initialization
bool is_range = false;
 ^
../../src/gllib/fnmatch_loop.c:238:21: error: cannot jump from this goto 
statement to its label
goto normal_bracket;
^
../../src/gllib/fnmatch_loop.c:424:26: note: jump bypasses variable 
initialization
bool is_range = false;
 ^
In file included from ../../src/gllib/fnmatch.c:269:
../../src/gllib/fnmatch_loop.c:205:27: error: expected unqualified-id
register bool not;
  ^
../../src/gllib/fnmatch_loop.c:222:17: error: expected expression
not = (*p == L_('!') || (posixly_correct < 0 && *p == L_('^')));
^
../../src/gllib/fnmatch_loop.c:223:20: error: expected expression
if (not)
   ^
../../src/gllib/fnmatch_loop.c:864:21: error: expected expression
if (!not)
^
../../src/gllib/fnmatch_loop.c:937:20: error: expected expression
if (not)
   ^
../../src/gllib/fnmatch_loop.c:269:29: error: cannot jump from this goto 
statement to its label
goto normal_bracket;
^
../../src/gllib/fnmatch_loop.c:424:26: note: jump bypasses variable 
initialization
bool is_range = false;
 ^
../../src/gllib/fnmatch_loop.c:238:21: error: cannot jump from this goto 
statement to its label
goto normal_bracket;
^
../../src/gllib/fnmatch_loop.c:424:26: note: jump bypasses variable 
initialization
bool is_range = false;
 ^
../../src/gllib/fnmatch.c:313:28: error: assigning to 'wchar_t *' from 
incompatible type 'void *'
  wpattern = malloc (totsize * sizeof (wchar_t));
   ^ ~~~
16 errors generated.
make[3]: *** [fnmatch.o] Error 1
--8<---cut here-------end--->8---

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://camera.org http://www.memritv.org
http://iris.org.il http://dhimmi.org http://ffii.org
-Nervous?  -Yes!  -First time?  -No, I've been nervous before!

Re: [bug-gettext] gettext 0.18.2 fails to compile without optimisations

[Sam Thursfield]

On 01/17/2013 09:18 AM, Daiki Ueno wrote:

Paul Eggert egg...@cs.ucla.edu writes:


On 01/16/13 01:08, Daiki Ueno wrote:

I'm not 100% sure if this is the right fix, so Cc'ed bug-gnulib.


This patch looks good to me.  Might there be other files
with the same problem?  Maybe gettext should be changed to
use gnulib-tool to import modules from gnulib, as that would
help avoid similar issues in the future.


Thanks.  I've modified the patch to use gnulib-tool for libasprintf, and
pushed it to the master.  For libintl, perhaps we may want to consider
doing the auto-sync between gettext - gnulib.


Thanks for the patch, it works perfectly for me. Interesting that you 
couldn't reproduce except with a cross-compiler -- I'm using a 
custom-built (native) GCC, so I suppose mine is lacking something that 
would otherwise cover up the problem. Or potentially your distro's GCC 
forces -finline-functions. I believe Ubuntu at least force some 
optimisation flags for compatibility with their built binaries.


Thanks for looking at it anyway
Sam

_GL_UNISTD_H _GL_INCLUDING_WINSOCK2_H

[Sam Steingold]

Hi,
gllib/unistd.h says:

#if 1  1 \
   !defined _GL_INCLUDING_WINSOCK2_H
# define _GL_INCLUDING_WINSOCK2_H
# include winsock2.h
# undef _GL_INCLUDING_WINSOCK2_H
#endif

#if !defined _GL_UNISTD_H  !defined _GL_INCLUDING_WINSOCK2_H
#define _GL_UNISTD_H

so when compiling with i686-pc-mingw32-gcc _GL_INCLUDING_WINSOCK2_H is
undef'ed and so _GL_UNISTD_H is __NOT__ defined thus I get

.../modules/rawsock/rawsock.c:691:3: warning: implicit declaration of function 
`close_used_without_including_unistd_h'

why?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://openvotingconsortium.org http://truepeace.org http://www.memritv.org
http://mideasttruth.com http://ffii.org http://iris.org.il http://camera.org
What garlic is to food, insanity is to art.

Re: _GL_UNISTD_H _GL_INCLUDING_WINSOCK2_H

[Sam Steingold]

 * Sam Steingold f...@tah.bet [2011-08-25 12:09:34 -0400]:

 .../modules/rawsock/rawsock.c:691:3: warning: implicit declaration of
 function `close_used_without_including_unistd_h'

the immediate cause appears to be that I include unistd.h after some
other headers (specifically,

#include alloca.h
#include stdlib.h
#include sys/types.h
#include stdbool.h
#include windows.h

) and then it bails out.
are you sure this is right?!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://jihadwatch.org http://ffii.org http://mideasttruth.com
http://iris.org.il http://truepeace.org http://www.PetitionOnline.com/tap12009/
If you're being passed on the right, you're in the wrong lane.

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-08-14 14:51:55 +0200]:

 Sam, if 'canonicalize' gets this support, would you be willing to use
 'canonicalize'

Let me reiterate that the size of canonicalize is plain absurd:
https://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00143.html.
150+ files to implement a single function which takes ~160 lines of C code.
These files includes things like hash.c and fchownat.c (why?!)
as well as __BOTH__ malloc.c and xmalloc.c.

 instead of 'canonicalize-lgpl' in clisp?

For the record, I am _not_ using `canonicalize-lgpl'.

I have been reluctant to pull this code bloat into clisp so far,
but if it does provide a clear advantage of handling cygwin symlinks on
pure win32 builds, I will reconsider.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://openvotingconsortium.org http://www.PetitionOnline.com/tap12009/
http://www.memritv.org http://memri.org http://camera.org
Single tasking: Just Say No.

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-08-23 08:03:02 -0600]:

 On 08/23/2011 07:56 AM, Sam Steingold wrote:
 Let me reiterate that the size of canonicalize is plain absurd:
 https://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00143.html.
 150+ files to implement a single function which takes ~160 lines of C code.
 These files includes things like hash.c and fchownat.c (why?!)

 hash.c in order to properly detect ELOOP, which must be done as part of
 an unlimited-depth link following algorithm.  (If we didn't have the GNU
 mantra of no arbitrary limits, then we could declare ELOOP at
 SYMLOOP_MAX instead.)

ELOOP at SYMLOOP_MAX sounds good to me.
Please note that gnulib's mandate (as far as _I_ understand it) is
to turn a random system into a POSIX system, not a GNU system.
Please provide a separate module when you want to follow the GNU mantra,
like you do with fnmatch.

Thanks!

 fchownat.c because the openat module has too many functions.

I would say that all the f* (i.e., using FILE*) files are an overkill.

 Anyone willing to split openat into multiple modules, one per
 function, more like other gnulib modules?

Please!

 as well as __BOTH__ malloc.c and xmalloc.c.

 Depending on xmalloc is probably overkill - having a version of
 canonicalize that returns NULL with ENOMEM instead of abort()ing would
 indeed be nicer.  Anyone willing to contribute patches to break that
 part of the dependency chain()

Please!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://pmw.org.il http://iris.org.il http://ffii.org http://honestreporting.com
http://www.PetitionOnline.com/tap12009/ http://openvotingconsortium.org
(let((a'(list'let(list(list'a(list'quote a)))a)))`(let((a(quote ,a))),a))

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-08-23 08:46:00 -0600]:

 On 08/23/2011 08:41 AM, Sam Steingold wrote:
 * Eric Blakeroy...@erqung.pbz  [2011-08-23 08:03:02 -0600]:

 On 08/23/2011 07:56 AM, Sam Steingold wrote:
 Let me reiterate that the size of canonicalize is plain absurd:
 https://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00143.html.
 150+ files to implement a single function which takes ~160 lines of C code.
 These files includes things like hash.c and fchownat.c (why?!)

 hash.c in order to properly detect ELOOP, which must be done as part of
 an unlimited-depth link following algorithm.  (If we didn't have the GNU
 mantra of no arbitrary limits, then we could declare ELOOP at
 SYMLOOP_MAX instead.)

 ELOOP at SYMLOOP_MAX sounds good to me.

 Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable
 change.  If not, then how do you propose implementing canonicalize on
 Hurd, without imposing a limit not already present by the system?

Are you saying that you want to replace realpath on a GNU system?
Are you trying to be holier than the pope?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://jihadwatch.org http://memri.org
http://palestinefacts.org http://thereligionofpeace.com http://iris.org.il
main(a){a=main(a){a=%c%s%c;printf(a,34,a,34);};printf(a,34,a,34);}

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-08-23 10:35:52 -0600]:

 On 08/23/2011 10:28 AM, Sam Steingold wrote:
 Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable
 change.  If not, then how do you propose implementing canonicalize on
 Hurd, without imposing a limit not already present by the system?

 Are you saying that you want to replace realpath on a GNU system?

 Have you read the canonicalize module?  It does _not_ provide
 canonicalize() (which is a thin wrapper around realpath(), but which is
 inherently limited in what it can do), but a broader API
 canonicalize_filename_mode(const char *name, canonicalize_mode_t mode),
 where the extra argument mode allows you to canonicalize whether a file
 name can be created (all its parents exist), or even to canonicalize
 what exists but leave the suffix intact (multiple parents still need
 creation).  That is, there is no libc functions that do what we want in
 a single blow, not even realpath(), so we have to do a lot of work to
 get the extended functionality, all of which is useful in coreutils'
 realpath(1).

I see. So, the canonicalize module is an extension, not a
portability module, i.e., it offers new non-posix functionality
instead of making sure that the weird platforms conform to posix.
Thanks for explaining.

 ... enhanced with gpl code to parse symlinks left by cygwin even when
 running as a non-cygwin native windows program.  But why?  Windows
 doesn't have symlinks, and cygwin is free to change its symlink
 emulation in the future.  Does it really make sense to teach
 non-cygwin programs about cygwin file formats?

First of all, newer windows do have symlinks.
Second, canonicalize is already an extension module, so why not extend
it to work well with a popular extension of a popular platform? :-)

 Maybe we should rename the canonicalize module to instead be
 canonicalize_filename_mode, since it does _not_ provide canonicalize()
 (well, canonicalize_filename_mode(file, CAN_EXISTING) is identical to
 canonicalize(), but the other modes are what introduce the baggage).

yes, I think there should be a very minimalist realpath module whose job
is to provide the posix realpath with minimum dependencies (well,
minimum dependencies is my constant mantra, applicable to extension
modules just as much as to portability ones).

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://thereligionofpeace.com http://camera.org
http://dhimmi.com http://memri.org http://truepeace.org
Be sure brain is in gear before engaging mouth.

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-08-23 11:47:57 -0600]:

 On 08/23/2011 11:31 AM, Sam Steingold wrote:

 Maybe we should rename the canonicalize module to instead be
 canonicalize_filename_mode, since it does _not_ provide canonicalize()
 (well, canonicalize_filename_mode(file, CAN_EXISTING) is identical to
 canonicalize(), but the other modes are what introduce the baggage).

 yes, I think there should be a very minimalist realpath module whose job
 is to provide the posix realpath with minimum dependencies (well,
 minimum dependencies is my constant mantra, applicable to extension
 modules just as much as to portability ones).

 canonicalize-lgpl _is_ the minimalize realpath()/canonicalize()
 module.

http://article.gmane.org/gmane.comp.lib.gnulib.bugs:26452

Indeed, much better:

$ wc `hg st -u | cut -c2-`
  378  1324 10439 src/gllib/canonicalize-lgpl.c
   53   261  2011 src/gllib/dosname.h
   91   490  3191 src/gllib/lstat.c
   48   227  1525 src/gllib/pathmax.h
   74   347  2355 src/gllib/readlink.c
  105   458  3425 src/gllib/stat.c
  658  2489 18324 src/gllib/sys_stat.in.h
  249  1093  9223 src/gllib/time.in.h
   94   274  2986 src/glm4/canonicalize.m4
   38   212  1621 src/glm4/double-slash-root.m4
   69   274  2652 src/glm4/lstat.m4
   1355   441 src/glm4/pathmax.m4
   62   210  2218 src/glm4/readlink.m4
   66   250  2436 src/glm4/stat.m4
   82   259  3278 src/glm4/sys_stat_h.m4
  109   305  4247 src/glm4/time_h.m4
 2189  8528 70372 total

Still I get 2000+ lines to replace 200- lines I have.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://mideasttruth.com
http://openvotingconsortium.org http://ffii.org http://dhimmi.com
Why do you never call me back after I scream that I will never talk to you 
again?!

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

On Sun, Aug 14, 2011 at 8:51 AM, Bruno Haible br...@clisp.org wrote:

 Sam, if 'canonicalize' gets this support, would you be willing to use
 'canonicalize' instead of 'canonicalize-lgpl' in clisp?

yes.

-- 
Sam Steingold http://sds.podval.org

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

Hi Bruno,

On Sat, Aug 13, 2011 at 1:52 PM, Bruno Haible br...@clisp.org wrote:

 The feature request is a bit odd, because it mixes the notion of
 native Windows and Cygwin. Cygwin is a platform that runs inside Windows.
 When you build mingw programs, and redistribute them, they are meant to
 run in a native Windows environment, in which no Cygwin symlinks exist.

I have not seen a windows machine without cygwin for longer than it
took me to install it.
CLISP understands those /cygdrive/c/autoexec.bat pathnames just
fine, and understanding symlinks is just another step forward.

 Other non-Cygwin applications don't understand Cygwin symlinks either.

Emacs understands the cygdrive pathnames and I am sure it will
appreciate an opportunity to understand symlinks as well.

-- 
Sam Steingold http://sds.podval.org

rpl_socket on windows

[Sam Steingold]

with clisp built with the latest gnulib:
(defparameter *server* (socket-server))
- success, rpl_socket (domain=2, type=1, protocol=0) is called.
(socket-connect (socket-server-port *server*) localhost :timeout 0)
failure the same rpl_socket (domain=2, type=1, protocol=0) is called:
*** - POSIX library error 0: No error

[4] (socket-connect (socket-server-port *server*) localhost :timeout 0)

Breakpoint 18, 0x0055ec4a in rpl_socket (domain=2, type=1, protocol=0)
at ../../src/gllib/w32sock.h:58
58errno = (err  1  err  10025) ? err - 1 : err;
(gdb) s
0x00560f1d in gl_sockets_startup (version=257) at ../../src/gllib/w32sock.h:58
58errno = (err  1  err  10025) ? err - 1 : err;
(gdb) finish
Run till exit from #0  0x00560f1d in gl_sockets_startup (version=257)
at ../../src/gllib/w32sock.h:58
0x0055ec56 in rpl_socket (domain=2, type=1, protocol=0)
at ../../src/gllib/w32sock.h:58
58errno = (err  1  err  10025) ? err - 1 : err;
Value returned is $6 = 0
(gdb) s
0x004f571a in ANSIC_error () at ../src/lispbibl.d:14619
14619 if (!symbolp(obj))

for some reason gdb seems not to be working properly.
clisp (and gnulib) was compiled with i686-w64-mingw32-gcc.
CYGWIN_NT-5.2-WOW64 sds 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://jihadwatch.org http://mideasttruth.com
http://memri.org http://ffii.org http://honestreporting.com http://pmw.org.il
Heck is a place for people who don't believe in gosh.

REPLACE_TOWLOWER='1'

[Sam Steingold]

why is tolower replaced on linux?
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://iris.org.il http://palestinefacts.org http://honestreporting.com
http://thereligionofpeace.com http://www.PetitionOnline.com/tap12009/
Why use Windows, when there are Doors?

Re: top_srcdir in Makefile.am Makefile.in

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-07-30 02:20:08 +0200]:

 Sam Steingold wrote:
 clisp directory structure is:
 clisp - top level; hand-written configure script (ask Bruno)
 clisp/src - most sources, configure.in, configure, aclocal.m4
 clisp/src/gllib, clisp/src/glm4 - imported from gnulib
 clisp/src/build-aux - imported from many places, mostly gnulib

 So, in clisp, $(top_srcdir) ought to be clisp/src.

thanks.

 You can get in trouble here if you use fake configure.ac / configure
 file that are present at the moment 'automake' is run but are removed
 afterwards.

I get the exact same files if I run aclocal on clisp/src/configure.ac as
on clisp/configure.ac.

 $ grep top_srcdir src/gllib/Makefile.am
 appears to indicate that top_srcdir should point to clisp.

 Maybe this is related to this hack in clisp/Makefile.devel:

 src/gllib/Makefile.in : src/gllib/Makefile.am src/configure.in src/aclocal.m4
 cd src  automake gllib/Makefile  \
 sed -i -e 
 's,$$(top_srcdir)/src/build-aux,$$(CLISP_LIBDIR)/build-aux,' \
   -e 's,$$(top_srcdir)/$$cl_cv_clisp_libdir,$$(CLISP_LIBDIR),' \
 gllib/Makefile.in

you are out of date, the current hack is

src/gllib/Makefile.in : src/gllib/Makefile.am src/configure.in src/aclocal.m4
cd src  automake --gnits gllib/Makefile  \
sed -i -e 's,$$(top_srcdir)/src/build-aux,$$(top_srcdir)/build-aux,' \
gllib/Makefile.in

(whose intent you should approve of)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://pmw.org.il http://palestinefacts.org http://ffii.org
http://thereligionofpeace.com http://openvotingconsortium.org http://memri.org
The difference between theory and practice is that in theory there isn't any.

Re: REPLACE_TOWLOWER='1'

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-08-01 09:00:07 -0600]:
 On 08/01/2011 08:56 AM, Sam Steingold wrote:
 why is tolower replaced on linux?

 Did you mean towlower rather than tolower?

towlower, sorry

 What does config.log say?

configure:29272: checking whether towlower is declared
configure:29272: gcc -c   conftest.c 5
configure:29272: $? = 0
configure:29272: result: yes

| #define HAVE_DECL_TOWLOWER 1

ac_cv_have_decl_towlower=yes

REPLACE_TOWLOWER='1'

these are the only mentions of towlower in config.log

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://truepeace.org http://palestinefacts.org http://iris.org.il
http://ffii.org http://thereligionofpeace.com http://jihadwatch.org
20% of people do 80% of work; also 80% of people think they are in those 20%.

Re: regex.m4: how do I know that the included regex is used?

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-07-29 01:39:59 +0200]:

 At any rate, if gnulib regex is included in libgnu.a, then regex.h
 should be copied (or linked) to $(builddir) or $(builddir)/gllib.
 The current situation is clearly wrong: regex is the only gnulib package
 which requires prepending -I$(srcdir)/gllib to CPPFLAGS!

 It is the package's responsibility to be consistent about $(builddir)
 vs. $(srcdir). Don't use
-I$(srcdir)/gllib
 or
-I$(builddir)/gllib
 in isolation. Always use
-I$(builddir)/gllib -I$(srcdir)/gllib
 so that -I options that come before it take precedence, -I options that come
 after have lower precedence, and files in $(builddir)/gllib hide possible
 (accidentally leftover) files in $(srcdir)/gllib.

well, instead of adding -I$(srcdir)/gllib, I symlink (shudder!!!) the
necessary headers into -I$(builddir):
in makemake.in:

GLLIB_MODULE_HEADERS=regex.h
for f in localcharset.h ${GLLIB_MODULE_HEADERS} ${UNICODE_EXTRA}; do
  link_dep ${f} `find ${SRCDIR}gllib/ -name ${f}`
done

which results in

regex.h : ../src/gllib/regex.h
-$(RM) regex.h
-$(LN_S) ../src/gllib/regex.h regex.h

streq.h : ../src/gllib/streq.h
-$(RM) streq.h
-$(LN_S) ../src/gllib/streq.h streq.h

cjk.h : ../src/gllib/uniwidth/cjk.h
-$(RM) cjk.h
-$(LN_S) ../src/gllib/uniwidth/cjk.h cjk.h

uninames.h : ../src/gllib/uniname/uninames.h
-$(RM) uninames.h
-$(LN_S) ../src/gllib/uniname/uninames.h uninames.h

the reason I cannot do -I$(srcdir)/gllib is clear: it will not catch
uninames.h  cjk.h.
on the other hand, it does not look like streq.h, uninames.h and cjk.h
are included in any clisp sources (only in gnulib).

so, I guess TRT is to remove the linking and add -I$(srcdir)/gllib to CPPFLAGS..

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://iris.org.il http://honestreporting.com http://openvotingconsortium.org
http://mideasttruth.com http://www.PetitionOnline.com/tap12009/ http://ffii.org
A man paints with his brains and not with his hands.

top_srcdir in Makefile.am Makefile.in

[Sam Steingold]

Hi,
clisp directory structure is:
clisp - top level; hand-written configure script (ask Bruno)
clisp/src - most sources, configure.in, configure, aclocal.m4
clisp/src/gllib, clisp/src/glm4 - imported from gnulib
clisp/src/build-aux - imported from many places, mostly gnulib

$ grep top_srcdir src/gllib/Makefile.am
appears to indicate that top_srcdir should point to clisp.
however,
$ cd src  automake gllib/Makefile  cd ..
$ grep top_srcdir src/gllib/Makefile.in
has these:
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.in
depcomp = $(SHELL) $(top_srcdir)/build-aux/depcomp
echo ' cd $(top_srcdir)  $(AUTOMAKE) --gnits gllib/Makefile'; \

how come?!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://honestreporting.com http://ffii.org
http://truepeace.org http://mideasttruth.com http://palestinefacts.org
Someone has changed your life.  Save? (y/n)

Re: top_srcdir in Makefile.am Makefile.in

[Sam Steingold]

A related issue is this section of gllib/Makefile.in

$(srcdir)/Makefile.in:  $(srcdir)/Makefile.am  $(am__configure_deps)
@for dep in $?; do \
  case '$(am__configure_deps)' in \
*$$dep*) \
  ( cd $(top_builddir)  $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
 { if test -f $@; then exit 0; else break; fi; }; \
  exit 1;; \
  esac; \
done; \
echo ' cd $(top_srcdir)  $(AUTOMAKE) --gnits gllib/Makefile'; \
$(am__cd) $(top_srcdir)  \
  $(AUTOMAKE) --gnits gllib/Makefile

the penultimate line must be

$(am__cd) $(top_srcdir)/src  \

how do I effect that?

 * Sam Steingold f...@tah.bet [2011-07-29 14:16:46 -0400]:

 clisp directory structure is:
 clisp - top level; hand-written configure script (ask Bruno)
 clisp/src - most sources, configure.in, configure, aclocal.m4
 clisp/src/gllib, clisp/src/glm4 - imported from gnulib
 clisp/src/build-aux - imported from many places, mostly gnulib

 $ grep top_srcdir src/gllib/Makefile.am
 appears to indicate that top_srcdir should point to clisp.
 however,
 $ cd src  automake gllib/Makefile  cd ..
 $ grep top_srcdir src/gllib/Makefile.in
 has these:
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/configure.in
 depcomp = $(SHELL) $(top_srcdir)/build-aux/depcomp
 echo ' cd $(top_srcdir)  $(AUTOMAKE) --gnits gllib/Makefile'; \

 how come?!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://truepeace.org http://www.memritv.org http://memri.org http://iris.org.il
http://openvotingconsortium.org http://www.PetitionOnline.com/tap12009/
A clear conscience is usually the sign of a bad memory.

Re: regex.m4: how do I know that the included regex is used?

[Sam Steingold]

 * Paolo Bonzini obam...@tah.bet [2011-07-28 12:15:38 +0200]:

 On 07/27/2011 05:11 PM, Sam Steingold wrote:
 When the included regex is used I must prepend -I$(srcdir)/gllib to
 CPPFLAGS to ensure that the gnulib regex.h is included in the sources.
 (when this is not the case, I_must_  not do that!)
   ^^

 This is not true AFAIK.

If I prepend -I$(srcdir)/gllib to CPPFLAFS, then

#include regex.h

will read the gnulib header, not the system header.
How can you be sure that this will not lead to any problems given that
the libgnu.a does _not_ include regex.o?
If course, you can claim that, if gnulib regex.h were incompatible with
the system one, then configure would have detected that and included
gnulib regex in libgnu.a.
In that case, why the file fnmatch.in.h not called fnmatch.h?
At any rate, if gnulib regex is included in libgnu.a, then regex.h
should be copied (or linked) to $(builddir) or $(builddir)/gllib.
The current situation is clearly wrong: regex is the only gnulib package
which requires prepending -I$(srcdir)/gllib to CPPFLAFS!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://mideasttruth.com http://memri.org http://dhimmi.com http://truepeace.org
http://www.PetitionOnline.com/tap12009/ http://camera.org
MS Windows: error: the operation completed successfully.

Re: regex.m4: how do I know that the included regex is used?

[Sam Steingold]

 * Paolo Bonzini obam...@tah.bet [2011-07-28 16:54:12 +0200]:

 The current situation is ugly---apart from the inconsistency in syntax
 definitions, there is no reason indeed why regex shouldn't use
 regex.in.h too, and no reason why it should require prepending
 -I$(srcdir)/gllib to CPPFLAGS.

Is it going to be fixed?  I need to decide whether I must commit the
prepending -I$(srcdir)/gllib to CPPFLAGS hack or wait for a gnulib fix.
Thanks.

 But it is not true that regex requires different CPPFLAGS depending on
 whether the included regex is used.

OK, I will take your word for that and redirect the future bug reports
(if any) to you.  Thanks. :-)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://dhimmi.com http://pmw.org.il http://ffii.org http://camera.org
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
recursion, n: See recursion.

how do I build libgnu.so?

[Sam Steingold]

Hi,
Make in gllib creates libgnu.a but not libgnu.so (or libgnu.dll).
How do I create the shared library?
Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://mideasttruth.com http://thereligionofpeace.com http://pmw.org.il
http://ffii.org http://www.PetitionOnline.com/tap12009/
Bus error -- driver executed.

Re: new module 'stdalign'

[Sam Steingold]

Hi Bruno,

On Thu, Jul 28, 2011 at 7:47 PM, Bruno Haible br...@clisp.org wrote:
 For alignof, whether you want to use gnulib's alignof.h depends on what you
 need - the necessary alignment and the optimal alignment.

so, what does clisp need?

-- 
Sam Steingold http://sds.podval.org

regex.m4: how do I know that the included regex is used?

[Sam Steingold]

Hi,
When the included regex is used I must prepend -I$(srcdir)/gllib to
CPPFLAGS to ensure that the gnulib regex.h is included in the sources.
(when this is not the case, I _must_ not do that!)
This raises 2 questions:

1. how do I know elsewhere in the configuration process that the
   included regex is used? the authoritative variable is
   ac_use_included_regex, but it is not cached, so sub-configures cannot
   access it.

2. what if there is some other gnulib package xeger with the same modus
   operandi? (i.e., if xeger is used, I must prepend -I$(srcdir)/gllib
   to CPPFLAGS and if it is not, I must not).
   what if regex IS used but xeger is NOT?

I propose that regex.h is replaced with regex.in.h just like
fnmatch.in.h (which has no @@ either).  This would solve the problem
without any action from the users of gnulib.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://openvotingconsortium.org http://ffii.org http://truepeace.org
http://camera.org http://thereligionofpeace.com http://www.memritv.org
Bus error -- please leave by the rear door.

Re: new module 'stdalign'

[Sam Steingold]

Hi Bruno,
1. There is already alignof module - is this a replacement?
2. alignof.h uses offsetof macro - where is it defined?
3. clisp/src/lispbibl.d defines offsetof, offsetofa, alignof - which
   gnulib modules should they be imported from? (or should I just leave
   them defined in clisp?)
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://thereligionofpeace.com http://jihadwatch.org http://dhimmi.com
http://honestreporting.com http://camera.org http://iris.org.il
Oral sex was invented by mermaids.

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

 * Sam Steingold f...@tah.bet [2011-05-17 14:11:54 -0400]:

 it appears that neither canonicalize nor canonicalize-lgpl support win32
 shortcuts (either used directly or as used by cygwin).
 it would be nice if they did - then we would be able to use
 canonicalize-lgpl in clisp.

 now clisp uses file w32shell.c:
 http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/raw-file/363f5b952505/src/w32shell.c
 which works like a charm for us.
 it would be wonderful if we could shift the burden of maintaining it to you.

Alas, clisp only supports the *.lnk style cygwin symlinks, not the now
default cookie style.
You will need to extract parts of winsup/cygwin/path.cc to support both styles.
My feature request still stands.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://ffii.org http://www.memritv.org http://pmw.org.il http://dhimmi.com
http://openvotingconsortium.org http://thereligionofpeace.com
Takeoffs are optional.  Landings are mandatory.

undefined reference when linking a dll

[Sam Steingold]

/sds/src/clisp/current/modules/rawsock/rawsock.c:1267: undefined 
reference to `_rpl_getsockopt'
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1275: undefined 
reference to `_rpl_getsockopt'
rawsock.o: In function `set_sock_opt':
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1356: undefined 
reference to `_rpl_setsockopt'
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1375: undefined 
reference to `_rpl_setsockopt'
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1378: undefined 
reference to `_rpl_setsockopt'
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1382: undefined 
reference to `_rpl_setsockopt'
/cygdrive/c/sds/src/clisp/current/modules/rawsock/rawsock.c:1393: undefined 
reference to `_rpl_setsockopt'
collect2: ld returned 1 exit status
./clisp-link: failed in /cygdrive/c/sds/src/clisp/current/build-mingw-g/full
make: *** [full] Error 1

$ nm libgnu.a | grep rpl_setsockopt
00c8 T _rpl_setsockopt
$ nm lisp.exe | grep rpl_setsockopt
0055dfbc T _rpl_setsockopt
$ grep rpl_setsockopt lisp.def
lisp.exe._rpl_setsockopt

this is despite lisp.exe._rpl_setsockopt et al being present in
lisp.def IMPORTS section.
note that all the other (non-gnulib) symbols in lisp.exe mentioned in
rawsock.o link just fine, e.g.:

asciz_to_string
$ nm rawsock/rawsock.o | grep asciz_to_string
 U __imp__asciz_to_string
$ nm lisp.exe | grep asciz_to_string
0044731c T _asciz_to_string
$ grep asciz_to_string lisp.def
lisp.exe.asciz_to_string

and there are no errors about asciz_to_string.

this is because asciz_to_string is declared with __declspec(dllexport)
where it is defined.
there seems to be no way to add such a declaration to the rpl_setsockopt
et al.

if, instead, I add libgnu.a to the command line, I get

libgnu.a(sendto.o): In function `rpl_sendto':
/cygdrive/c/sds/src/clisp/current/build-mingw-g/gllib/../../src/gllib/sendto.c:36:
 undefined reference to `__imp__sendto@24'

so, how do I create a dll which refers to the gnulib functionality?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.PetitionOnline.com/tap12009/ http://iris.org.il http://dhimmi.com
http://www.memritv.org http://openvotingconsortium.org http://camera.org
Two wrongs don't make a right, but three rights make a left.

Re: HAVE_RELIABLE_FIONREAD ioctl

[Sam Steingold]

: declaration of C function 'int ioctl(int, unsigned int, 
void*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, int, void*)' 
conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, long unsigned 
int, void*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, long int, 
void*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, size_t, 
void*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, socklen_t, 
void*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, unsigned int, .
..)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
conftest.c:471: error: declaration of C function 'int ioctl(int, int, ...)' 
conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c 5
configure:36267: $? = 0
configure:36296: result: extern int ioctl (int, unsigned long, ...);

$ grep IOCTL config.h
#define GNULIB_TEST_IOCTL 1
#define HAVE_IOCTL 1
#define HAVE_RAW_DECL_IOCTL 1
#define HAVE_SYS_IOCTL_H 1
/* #undef IOCTL_ARGUMENT_T */
#define IOCTL_DOTS /**/
#define IOCTL_REQUEST_T unsigned long
#define NEED_SYS_IOCTL_H /**/
#define WINSIZE_NEED_SYS_IOCTL_H /**/


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://truepeace.org http://dhimmi.com http://www.memritv.org
http://jihadwatch.org http://memri.org http://camera.org
Press any key to continue or any other key to quit.

Re: HAVE_RELIABLE_FIONREAD ioctl

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-07-22 00:18:04 +0200]:

 -extern DIR *fdopendir (int);
 +extern
 +# ifdef __cplusplus
 +C
 +# endif
 +DIR *fdopendir (int);

that's pretty awful.
maybe there is a way to use the m4 magic to avoid replacing 1 line with 5?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://memri.org http://www.PetitionOnline.com/tap12009/ http://dhimmi.com
http://camera.org http://mideasttruth.com http://honestreporting.com
DRM access management == prison freedom management.

Re: HAVE_LC_MESSAGES

[Sam Steingold]

 * Sam Steingold f...@tah.bet [2011-07-14 17:57:10 -0400]:

 * Bruno Haible oe...@pyvfc.bet [2011-07-14 23:18:41 +0200]:

 Sam Steingold asked:
 Does clisp need to know whether LC_MESSAGES is supported by the system,
 or is a fake one defined by libintl or gnulib.
 ...
  No, this is not needed: gettext's libintl.h already defines LC_MESSAGES 
  when
  needed, and clisp uses libintl.h.
 
 CLISP includes libintl.h only if ENABLE_NLS is defined (i.e., when
 gettext is present).
 It uses HAVE_LC_MESSAGES in spvw_ctype.d:init_ctype which is called
 unconditionally in spvw.d.
 I.e., on platforms without gettext where LC_MESSAGES is not defined
 init_ctype is still called and its call
 
   setlocale(LC_MESSAGES,);
 
 must be guarded by either #if HAVE_LC_MESSAGES or #ifdef LC_MESSAGES.

 By looking at the clisp code history:
   $ hg annotate -r 11858 spvw_ctype.d
   $ hg diff -r 3562 -r 3563
 I think the point was to allow the setlocale() call to be enabled even on
 platforms where locale.h does not have LC_MESSAGES (namely, native 
 Windows).
 The macro HAVE_LC_MESSAGES means
   - on Unix platforms, that LC_MESSAGES was found in locale.h,
   - on Windows platforms, that gettext is in use (always).

 what are the benefits of this very complex approach (autoconf, win32 c c)
 over a simple ifdef LC_MESSAGES?

 I think you can remove the #if because all Unix platforms nowadays have
 LC_MESSAGES.

 what about windows without gettext?

also, can I now remove gt_LC_MESSAGES from configure.in?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://openvotingconsortium.org
http://truepeace.org http://iris.org.il http://camera.org http://ffii.org
If at first you don't suck seed, try and suck another seed.

strerror_r replaced on linux?

[Sam Steingold]

Hi,

./config.log:REPLACE_STRERROR_R='1'

why do I see this on
Linux 2.6.18-238.9.1.el5
gcc (GCC) 4.1.2 20080704
glibc-2.5-58.el5_6.3

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://iris.org.il http://dhimmi.com
http://ffii.org http://palestinefacts.org http://camera.org
A man paints with his brains and not with his hands.

unistd sys/socket

[Sam Steingold]

Hi,
in what order do I include sys/socket and unistd?
sys_socket.in.h:
#if @HAVE_WINSOCK2_H@  !defined _GL_UNISTD_H
# if !(defined __cplusplus  defined GNULIB_NAMESPACE)
#  undef close
#  define close close_used_without_including_unistd_h
# else
   _GL_WARN_ON_USE (close,
close() used without including unistd.h);
# endif
#endif

so, on windows, I must include unistd before sys/socket, otherwise close
will not work.

otoh:
unistd.in.h:
#if @GNULIB_GETHOSTNAME@
/* Get all possible declarations of gethostname().  */
# if @UNISTD_H_HAVE_WINSOCK2_H@
#  if !defined _GL_SYS_SOCKET_H
#   if !(defined __cplusplus  defined GNULIB_NAMESPACE)
#undef socket
#define socket  socket_used_without_including_sys_socket_h

so I must include sys/socket before unistd, otherwise socket (and many
others) will not work.

so, what is the right order?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://openvotingconsortium.org http://mideasttruth.com
http://iris.org.il http://pmw.org.il http://www.memritv.org
Lisp: it's here to save your butt.

Re: unistd sys/socket

[Sam Steingold]

 * Eric Blake roy...@erqung.pbz [2011-07-14 07:43:40 -0600]:

 On 07/14/2011 07:37 AM, Sam Steingold wrote:
 Hi,
 in what order do I include sys/socket and unistd?
 sys_socket.in.h:
 #if @HAVE_WINSOCK2_H@  !defined _GL_UNISTD_H
 # if !(defined __cplusplus  defined GNULIB_NAMESPACE)
 #  undef close
 #  define close close_used_without_including_unistd_h
 # else
_GL_WARN_ON_USE (close,
 close() used without including unistd.h);
 # endif
 #endif
 
 so, on windows, I must include unistd before sys/socket, otherwise close
 will not work.
 
 otoh:
 unistd.in.h:
 #if @GNULIB_GETHOSTNAME@
 /* Get all possible declarations of gethostname().  */
 # if @UNISTD_H_HAVE_WINSOCK2_H@
 #  if !defined _GL_SYS_SOCKET_H
 #   if !(defined __cplusplus  defined GNULIB_NAMESPACE)
 #undef socket
 #define socket  socket_used_without_including_sys_socket_h
 
 so I must include sys/socket before unistd, otherwise socket (and many
 others) will not work.
 
 so, what is the right order?

 Do you have an actual compilation error, or are you just trying to
 understand the code?

this is an actual error, please see
http://article.gmane.org/gmane.lisp.clisp.devel:22588
and the whole thread.

 Both orders should work, if you are using the
 gnulib modules for both headers.

I have both modules.
unistd is requested explicitly.
sys_socket comes from a dependency.

 Note that in unistd.in.h, on mingw, sys/socket.h is included prior to
 this snippet of @GNULIB_GETHOSTNAME@, such that _GL_SYS_SOCKET_H is
 defined and you never get the
 socket_used_without_including_sys_socket_h, if you were using both
 gnulib modules.

the first mention of sys/socket.h in unistd.in.h is line 155:
  socket() used without including sys/socket.h);


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://mideasttruth.com http://www.memritv.org
http://dhimmi.com http://palestinefacts.org http://iris.org.il
Single tasking: Just Say No.

Re: HAVE_LC_MESSAGES

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-07-14 23:18:41 +0200]:

 Sam Steingold asked:
 Does clisp need to know whether LC_MESSAGES is supported by the system,
 or is a fake one defined by libintl or gnulib.
 ...
  No, this is not needed: gettext's libintl.h already defines LC_MESSAGES 
  when
  needed, and clisp uses libintl.h.
 
 CLISP includes libintl.h only if ENABLE_NLS is defined (i.e., when
 gettext is present).
 It uses HAVE_LC_MESSAGES in spvw_ctype.d:init_ctype which is called
 unconditionally in spvw.d.
 I.e., on platforms without gettext where LC_MESSAGES is not defined
 init_ctype is still called and its call
 
   setlocale(LC_MESSAGES,);
 
 must be guarded by either #if HAVE_LC_MESSAGES or #ifdef LC_MESSAGES.

 By looking at the clisp code history:
   $ hg annotate -r 11858 spvw_ctype.d
   $ hg diff -r 3562 -r 3563
 I think the point was to allow the setlocale() call to be enabled even on
 platforms where locale.h does not have LC_MESSAGES (namely, native Windows).
 The macro HAVE_LC_MESSAGES means
   - on Unix platforms, that LC_MESSAGES was found in locale.h,
   - on Windows platforms, that gettext is in use (always).

what are the benefits of this very complex approach (autoconf, win32 c c)
over a simple ifdef LC_MESSAGES?

 I think you can remove the #if because all Unix platforms nowadays have
 LC_MESSAGES.

what about windows without gettext?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://honestreporting.com http://openvotingconsortium.org http://memri.org
http://jihadwatch.org http://truepeace.org http://palestinefacts.org
Oral sex was invented by mermaids.

HAVE_LC_MESSAGES

[Sam Steingold]

Hi,
What's the point of HAVE_LC_MESSAGES?
I understand that HAVE_LC_MESSAGES is defined whenever config.h is
included while LC_MESSAGES is only defined if locale.h is included.
However, how is

 #if HAVE_LC_MESSAGES
  setlocale(LC_MESSAGES,);
 #endif

better than

 #ifdef LC_MESSAGES
  setlocale(LC_MESSAGES,);
 #endif

??

thanks!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://iris.org.il http://palestinefacts.org http://dhimmi.com
http://thereligionofpeace.com http://ffii.org http://honestreporting.com
Flying is not dangerous; crashing is.

Re: HAVE_LC_MESSAGES

[Sam Steingold]

Hi,

 * Bruno Haible oe...@pyvfc.bet [2011-07-13 21:12:49 +0200]:
 Sam Steingold wrote:
 What's the point of HAVE_LC_MESSAGES?

 The point is to tell whether LC_MESSAGES is supported by the system,
 or is a fake one defined by libintl or gnulib.

does clisp need to know the difference?

 This #if or #ifdef is outdated. The gettext manual [1] explains why.
 [1] http://www.gnu.org/software/gettext/manual/html_node/Triggering.html

are you suggesting that clisp should import the locale gnulib module instead?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://truepeace.org http://jihadwatch.org http://honestreporting.com
http://ffii.org http://pmw.org.il http://palestinefacts.org http://iris.org.il
Oral sex was invented by mermaids.

Re: HAVE_LC_MESSAGES

[Sam Steingold]

 * Bruno Haible oe...@pyvfc.bet [2011-07-13 22:44:49 +0200]:

 Sam Steingold wrote:
 does clisp need to know the difference?
 
  This #if or #ifdef is outdated. The gettext manual [1] explains why.
  [1] http://www.gnu.org/software/gettext/manual/html_node/Triggering.html

 The gettext manual answers this question.

Sorry, I need more help here. I read the page and I see no answer to the
question:

Does clisp need to know whether LC_MESSAGES is supported by the system,
or is a fake one defined by libintl or gnulib.

Please remember that I am an English-only bigot who believes that all
i18n/l12n efforts are a waste of time :-) so I know very little about
gettext et al and I wish I knew even less.

 are you suggesting that clisp should import the locale gnulib module instead?

 No, this is not needed: gettext's libintl.h already defines LC_MESSAGES when
 needed, and clisp uses libintl.h.

CLISP includes libintl.h only if ENABLE_NLS is defined (i.e., when
gettext is present).
It uses HAVE_LC_MESSAGES in spvw_ctype.d:init_ctype which is called
unconditionally in spvw.d.
I.e., on platforms without gettext where LC_MESSAGES is not defined
init_ctype is still called and its call

  setlocale(LC_MESSAGES,);

must be guarded by either #if HAVE_LC_MESSAGES or #ifdef LC_MESSAGES.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://memri.org http://iris.org.il http://www.PetitionOnline.com/tap12009/
http://thereligionofpeace.com http://truepeace.org http://dhimmi.com
If at first you don't suck seed, try and suck another seed.

errno -- errno name ?

[Sam Steingold]

I think it would be a useful addition to the errno/strerror/whatever
modules to be able to convert from the numeric errno to the symbolic
one.
e.g.,

char * errno_name () {
  switch (errno) {
  #ifdef ENOENT
   case ENOENT : return ENOENT;
  #endif
   default: return NULL;
  }
}

the idea is that the error explanation (returned by strerror) is
different on different platforms (and especially if i18n is involved)
and is hard to search for on the web and in docs, while strings like
ENOENT et al are quite canonical and tell the expert everything they
need to know.

I am not proposing replacing strerror, of course; this is merely an
_addition_.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://jihadwatch.org http://dhimmi.com http://palestinefacts.org
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
What was there first: the Compiler or its Source code?

Re: errno -- errno name ?

[Sam Steingold]

Hi Bruno,

 * Bruno Haible oe...@pyvfc.bet [2011-06-06 22:52:14 +0200]:
 I think it would be a useful addition to the errno/strerror/whatever
 modules to be able to convert from the numeric errno to the symbolic
 one.
 e.g.,
 
 char * errno_name () {
   switch (errno) {
   #ifdef ENOENT
case ENOENT : return ENOENT;
   #endif
default: return NULL;
   }
 }
 
 the idea is that the error explanation (returned by strerror) is
 different on different platforms (and especially if i18n is involved)
 and is hard to search for on the web and in docs, while strings like
 ENOENT et al are quite canonical and tell the expert everything they
 need to know.

 Good point. The code for doing this is already present in
 clisp/src/errunix.d and strace/**/errnoent.h.

moreover, most of it can be easily generated from the list of all
possible errno values:
-
char * errno_name () {
  switch (errno) {
#include errno_cases.h
default: return NULL;
  }
}

and a simple awk command which would convert a file:
-
ENOENT
ENOTDIR
...
-
into errno_cases.h

note that the windows version would have to operate on the values of
GetLastError() instead of errno.

 Question to Sam: Are you willing to contribute such a module to gnulib
 (and maintain it)?

Absolutely not.  The whole point of my request is that I will be
maintaining _less_ code, not more.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://pmw.org.il http://palestinefacts.org http://openvotingconsortium.org
http://www.memritv.org http://iris.org.il http://thereligionofpeace.com
Just because you're paranoid doesn't mean they AREN'T after you.

apology

[Sam Steingold]

I guess I should apologize for constantly harping about dependency creep
in gnulib.  No, gnulib is not the worst here.  By far!
I just did yum install perl-Net-SSH-Perl.noarch and it pulled 26
(that's right, twenty six!) packages for dependencies, including
perl-Math-GMP and perl-Math-Pari.
That's right, to interact with an ssh client, perl needs to do be able
to do number theoretical computer algebra system.
Can you believe it?!
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://iris.org.il http://camera.org http://ffii.org
http://honestreporting.com http://palestinefacts.org http://pmw.org.il
Two wrongs don't make a right, but three rights make a left.

Re: need for computer algebra

[Sam Steingold]

Hi Bruno,

 * Bruno Haible oe...@pyvfc.bet [2011-05-26 21:19:55 +0200]:

 That's right, to interact with an ssh client, perl needs to do be able
 to do number theoretical computer algebra system.
 Can you believe it?!

 a good candidate is elliptic-curve cryptography.

yes, it turned out that the packages reimplements an ssh client rather
than being an interface to an existing external one, in which case pari
would obviously be not necessary.

incidentally, I was not able to get it working on either Cygwin of
CentOS, using either pre-supplied package managers or cpan.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://openvotingconsortium.org http://www.PetitionOnline.com/tap12009/
http://memri.org http://jihadwatch.org http://palestinefacts.org
Professionalism is being dispassionate about your work.

new files imported without new modules added

[Sam Steingold]

Hi,
I updated gnulib and found that it now wants to add these files to
CLISP:

src/gllib/glthread/lock.c
src/gllib/glthread/lock.h
src/gllib/glthread/threadlib.c
src/gllib/strerror-impl.h
src/gllib/strerror_r.c
src/glm4/strerror_r.m4

I did not import any new modules.
what has happened?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://www.memritv.org http://mideasttruth.com
http://www.PetitionOnline.com/tap12009/ http://pmw.org.il http://dhimmi.com
Any programming language is at its best before it is implemented and used.