Re: License of module "Perl" seems wrong

[Bruno Haible]

On Montag, 27. Februar 2023 21:58:13 CET Reuben Thomas wrote:
> On Mon, 27 Feb 2023 at 14:05, Bruno Haible  wrote:
> 
> > Hi Reuben,
> >
> > Reuben Thomas wrote:
> > > The perl module has a GPL license, but its only file, m4/perl.m4, has an
> > > "unlimited" license.
> >
> > The license of a module, in the module description, cannot be "wrong" since
> > that's the authoritative location where the license is noted.
> >
> 
> Thanks for fixing this!

Done as below.

> In this case, it doesn't make sense to me that a module whose module file
> is trivial and whose only contents is a file with an "unlimited" license
> doesn't have the same license. In general, I'd expect modules to have
> something like the strictest license of any of their dependencies.

If we were to do this, it could happen quite frequently that, through an
implementation change of a module, its license would change from a relaxed
license to a more strict license. This would be a problem for the Gnulib
users.

Therefore, we try to set the license of a module, hopefully once and never
change it, in particular never change it in the relaxed → strict direction.


2023-02-28  Bruno Haible  

perl: Allow this module to be used with 'gnulib-tool --lgpl'.
Reported by Reuben Thomas  in
.
* modules/perl (License): Relax to 'GPLed build tool'.
Approved by Jim Meyering in
.

diff --git a/modules/perl b/modules/perl
index 017ba57a37..6a27919845 100644
--- a/modules/perl
+++ b/modules/perl
@@ -14,7 +14,7 @@ Makefile.am:
 Include:
 
 License:
-GPL
+GPLed build tool
 
 Maintainer:
 Jim Meyering

Re: Apple LLVM 10 and `__fallthrough__`

[Bruno Haible]

Alexei Podtelezhnikov wrote:
> > > Wiki suggests __apple_build_version__ >= 1200
> > > https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2
> ...
> I wish I could directly test it. However, I could confirm that Swift
> release 5.3 (Xcode 12) was the first release with this line
> https://github.com/apple/llvm-project/blob/swift-5.3-RELEASE/clang/test/Sema/fallthrough-attr.c#L18

Thanks for the investigation. Although we can't test it, these are two
independent hints that __apple_build_version__ >= 1200 is OK. Applied:


2023-02-28  Bruno Haible  

dfa: Tweak the last patch.
Suggested by Alexei Podtelezhnikov .
* lib/dfa.c (FALLTHROUGH): Assume that Apple clang, in C mode, supports
__attribute__ ((__fallthrough__)) starting with version 1200.
References:

https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2

https://github.com/apple/llvm-project/blob/swift-5.3-RELEASE/clang/test/Sema/fallthrough-attr.c

diff --git a/lib/dfa.c b/lib/dfa.c
index 994900fea2..20502a802f 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -69,7 +69,7 @@ c_isdigit (char c)
 #  define FALLTHROUGH [[__fallthrough__]]
 # elif ((__GNUC__ >= 7) \
 || (defined __apple_build_version__ \
-? __apple_build_version__ >= 1400 \
+? __apple_build_version__ >= 1200 \
 : __clang_major__ >= 10))
 #  define FALLTHROUGH __attribute__ ((__fallthrough__))
 # else

Re: License of module "Perl" seems wrong

[Reuben Thomas]

On Mon, 27 Feb 2023 at 14:05, Bruno Haible  wrote:

> Hi Reuben,
>
> Reuben Thomas wrote:
> > The perl module has a GPL license, but its only file, m4/perl.m4, has an
> > "unlimited" license.
>
> The license of a module, in the module description, cannot be "wrong" since
> that's the authoritative location where the license is noted.
>

Thanks for fixing this!

In this case, it doesn't make sense to me that a module whose module file
is trivial and whose only contents is a file with an "unlimited" license
doesn't have the same license. In general, I'd expect modules to have
something like the strictest license of any of their dependencies.

Re: License of module "Perl" seems wrong

[Jim Meyering]

On Mon, Feb 27, 2023 at 6:05 AM Bruno Haible  wrote:
> Hi Reuben,
>
> Reuben Thomas wrote:
> > The perl module has a GPL license, but its only file, m4/perl.m4, has an
> > "unlimited" license.
>
> The license of a module, in the module description, cannot be "wrong" since
> that's the authoritative location where the license is noted.
>
> I guess your problem is that you passed gnulib-tool some --lgpl=... option
> and got an "incompatible license" warning. If so, then the patch below would
> fix the problem.
>
> Jim, do you agree to this patch?
>
>
> diff --git a/modules/perl b/modules/perl
> index 017ba57a37..6a27919845 100644
> --- a/modules/perl
> +++ b/modules/perl
> @@ -14,7 +14,7 @@ Makefile.am:
>  Include:
>
>  License:
> -GPL
> +GPLed build tool

Yes. Thank you.

Re: Updating in glibc and gnulib

[Florian Weimer]

* Bruno Haible:

> Florian Weimer wrote:
>> Does gnulib still override  unconditionally?
>
> Gnulib does not override , and never did.

Thanks for looking into this.  gnulib's libc-config.h does this:

| #ifndef __attribute_nonnull__
| /*  either does not exist, or is too old for Gnulib.
|Prepare to include , which is Gnulib's version of a
|more-recent glibc .  */
| …
| /* Include our copy of glibc .  */
| # include 

And as gnulib's  uses the same _SYS_CDEFS_H header guard as
glibc's, that effectively replaces  with gnulib's
.

> That is, when a package that uses Gnulib does
>   #include 
> it will get the  of the system (from glibc, *BSD, Cygwin,
> etc.).

Apparently not if it includes libc-config.h first.

I think what happened is that the order of backporting

commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82
Author: Paul Eggert 
Date:   Tue Sep 21 07:47:45 2021 -0700

regex: copy back from Gnulib

(which brought in __attribute_nonnull__) and

commit a643f60c53876be0d57b4b7373770e6cb356fd13
Author: Siddhesh Poyarekar 
Date:   Wed Oct 20 18:12:41 2021 +0530

Make sure that the fortified function conditionals are constant

was reversed on the glibc 2.34 branch, so the version check based on
__attribute_nonnull__ would signal that system  is too old.
But with the second commit for fortified functions, glibc 2.34 headers
started requiring other macros not present in gnulib's  copy,
so some projects using copied gnulib sources would start to fail.

I backported the regex sync to glibc 2.34 in November, so this should
now be solved because we now define __attribute_nonnull__ even on the
2.34 branch.  I think only the 2.34 branch had this problem.

I think we should have backported the __attribute_nonnull__-defining
commit to glibc 2.34 earlier, when we noticed problems.  Updating the
gnulib-bundled copy only (which is what happened at first) wasn't the
best resolution.

Thanks,
Florian

Re: License of module "Perl" seems wrong

[Bruno Haible]

Hi Reuben,

Reuben Thomas wrote:
> The perl module has a GPL license, but its only file, m4/perl.m4, has an
> "unlimited" license.

The license of a module, in the module description, cannot be "wrong" since
that's the authoritative location where the license is noted.

I guess your problem is that you passed gnulib-tool some --lgpl=... option
and got an "incompatible license" warning. If so, then the patch below would
fix the problem.

Jim, do you agree to this patch?


diff --git a/modules/perl b/modules/perl
index 017ba57a37..6a27919845 100644
--- a/modules/perl
+++ b/modules/perl
@@ -14,7 +14,7 @@ Makefile.am:
 Include:
 
 License:
-GPL
+GPLed build tool
 
 Maintainer:
 Jim Meyering

[PATCH] terminfo, termcap: Fix more spellos in a comment.

[Benno Schulenberg]

* lib/tparm.c: Fix misspellings and wording in the main comment.
---
 ChangeLog   | 5 +
 lib/tparm.c | 8 
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 25610ee51b..17bb762072 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2023-02-27  Benno Schulenberg(tiny change)
+
+   terminfo, termcap: Fix more spellos in a comment.
+   * lib/tparm.c: Fix misspellings and wording in the main comment.
+
 2023-02-27  ChuanGang Jiang  
 
fts: fail gracefully when out of memory
diff --git a/lib/tparm.c b/lib/tparm.c
index 17923787d7..e9214e292c 100644
--- a/lib/tparm.c
+++ b/lib/tparm.c
@@ -176,14 +176,14 @@ cvtchar (const char *sp, char *c)
 /* sigh... this has got to be the ugliest code I've ever written.
Trying to handle everything has its cost, I guess.
 
-   It actually isn't to hard to figure out if a given % code is supposed
+   It actually isn't too hard to figure out if a given % code is supposed
to be interpreted with its termcap or terminfo meaning since almost
all terminfo codes are invalid unless something has been pushed on
the stack and termcap strings will never push things on the stack
(%p isn't used by termcap). So where we have a choice we make the
-   decision by whether or not somthing has been pushed on the stack.
+   decision by whether or not something has been pushed on the stack.
The static variable termcap keeps track of this; it starts out set
-   to 1 and is incremented as each argument processed by a termcap % code,
+   to 1 and is incremented for each argument processed for a termcap % code,
however if something is pushed on the stack it's set to 0 and the
rest of the % codes are interpreted as terminfo % codes. Another way
of putting it is that if termcap equals one we haven't decided either
@@ -216,7 +216,7 @@ cvtchar (const char *sp, char *c)
 %O  logical or pop and pop and push the result
 %!  push the logical not of pop
 %? condition %t if_true [%e if_false] %;
-if condition evaulates as true then evaluate if_true,
+if condition evaluates as true then evaluate if_true,
 else evaluate if_false. elseif's can be done:
 %? cond %t true [%e cond2 %t true2] ... [%e condN %t trueN] [%e false] 
%;
 %i  add one to parameters 1 and 2. (ANSI)
-- 
2.39.2

Re: Apple LLVM 10 and `__fallthrough__`

[Alexei Podtelezhnikov]

> > > -# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
> > > +# elif ((__GNUC__ >= 7) \
> > > +|| (defined __apple_build_version__ \
> > > +? __apple_build_version__ >= 1400 \
> > > +: __clang_major__ >= 10))
> > >
> > > Wiki suggests __apple_build_version__ >= 1200
> > > https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2

Alternative Xcode versioning source found:
https://github.com/gsl-lite/gsl-lite/blob/master/include/gsl/gsl-lite.hpp#L534-L557

Re: 回复: lib/fts.c: return when malloc failed

[Pádraig Brady]

On 27/02/2023 11:36, ChuanGang Jiang wrote:

I found this by accident and then reproduce it through artificial mem pressure 
test.
And I update the patch as you said.

*lib/fts.c：return when malloc failed in function setup_dir()
---
  lib/fts.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/fts.c b/lib/fts.c
index 78584b2902..c2fa5ee8dc 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -979,7 +979,11 @@ next:   tmp = p;
  }
  free_dir(sp);
  fts_load(sp, p);
-setup_dir(sp);
+if (! setup_dir(sp)) {
+free_dir(sp);
+__set_errno (ENOMEM);
+return (NULL);
+}
  goto check_for_dir;
  }



Pushed.
I'll also apply this to the upcoming coreutils release for rm.

thanks,
Pádraig.

回复: lib/fts.c: return when malloc failed

[ChuanGang Jiang]

I found this by accident and then reproduce it through artificial mem pressure 
test.
And I update the patch as you said.

*lib/fts.c：return when malloc failed in function setup_dir()
--- 
 lib/fts.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/fts.c b/lib/fts.c
index 78584b2902..c2fa5ee8dc 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -979,7 +979,11 @@ next:   tmp = p;
 }
 free_dir(sp);
 fts_load(sp, p);
-setup_dir(sp);
+if (! setup_dir(sp)) {
+free_dir(sp);
+__set_errno (ENOMEM);
+return (NULL);
+}
 goto check_for_dir;
 }

--
2.36.1

Best Regards
ChuanGang Jiang

-邮件原件-
发件人: Pádraig Brady  代表 Pádraig Brady
发送时间: 2023年2月26日 23:30
收件人: ChuanGang Jiang ; bug-gnulib@gnu.org
主题: Re: lib/fts.c: return when malloc failed

On 26/02/2023 14:46, ChuanGang Jiang wrote:
> Hi，‘rm’ of coreutils was terminated with signal SIGSEGV, Segmentation fault.
> Here is the backtrace with gdb.
> 
> Core was generated by `/usr/bin/rm -rf test1/test2/'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
> ../lib/cycle-check.c:60
> 60assure (state->magic == CC_MAGIC);
> (gdb) bt full
> #0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
> ../lib/cycle-check.c:60
>  __PRETTY_FUNCTION__ = "cycle_check"
> #1  0x56296aa3d8bd in enter_dir (fts=0x56296ac28ae0, ent=0x56296ac29d90) 
> at ../lib/fts-cycle.c:108
>  st = 
>  ad = 
>  ad_from_table = 
> #2  0x56296aa3f031 in rpl_fts_read (sp=sp@entry=0x56296ac28ae0) at 
> ../lib/fts.c:1024
>  p = 0x56296ac29d90
>  tmp = 
>  instr = 
>  t = 
> #3  0x56296aa39858 in rm (file=, x=0x7ffc10c71c60) at 
> ../src/remove.c:597
>  ent = 
>  s = 
>  bit_flags = 
>  fts = 0x56296ac28ae0
>  rm_status = RM_OK
>  __PRETTY_FUNCTION__ = "rm"
> #4  0x56296aa388e2 in main (argc=, argv=0x7ffc10c71e88) at 
> ../src/rm.c:370
>  preserve_root = true
>  x = {ignore_missing_files = true, interactive = RMI_NEVER, 
> one_file_system = false, recursive = true, remove_empty_directories = false, 
> root_dev_ino = 0x56296aa480b0 , preserve_all_root = false,
>stdin_tty = true, verbose = false, require_restore_cwd = false}
>  prompt_once = 
>  c = 
>  n_files = 
>  file = 0x7ffc10c71e98
>  status = 
>  __PRETTY_FUNCTION__ = "main"
> 
> 
> I think it should return when malloc failed for ’fts->fts_cycle.state‘ 
> in ’setup_dir(sp)‘ and the patch below may fix this.
> 
> 
> *lib/fts.c：return when malloc failed in function setup_dir()
> ---
>   lib/fts.c | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/fts.c b/lib/fts.c
> index 78584b2902..374efa1be7 100644
> --- a/lib/fts.c
> +++ b/lib/fts.c
> @@ -979,7 +979,10 @@ next:   tmp = p;
>   }
>   free_dir(sp);
>   fts_load(sp, p);
> -setup_dir(sp);
> +if (! setup_dir(sp)) {
> +free_dir(sp);
> +return (NULL);
> +}
>   goto check_for_dir;
>   }
> 

I agree that assertion may trigger if setup_dir() fails.
free_dir() is safe to call upon setup_dir() failure, so the patch looks correct.
The only way that setup_dir() can really fail is due to no memory, so I'd also 
__set_errno (ENOMEM); in this case.

How did you notice this?
Did you apply artificial mem pressure for testing?

thanks!
Pádraig

License of module "Perl" seems wrong

[Reuben Thomas]

The perl module has a GPL license, but its only file, m4/perl.m4, has an
"unlimited" license.

-- 
https://rrt.sc3d.org

Re: Take account of splitting option in gendocs.sh

[Gavin Smith]

On Sun, Feb 26, 2023 at 09:52:08PM +0100, Bruno Haible wrote:
> Gavin Smith wrote:
> > I notice that this script also still supports texi2html, which is no
> > longer developed.  I could produce a patch to remove this support if
> > it was very likely that nobody was relying on it.
> 
> A web search on www.gnu.org shows that the manuals of at least the following
> packages still were generated using texi2html:
>   anubis, auctex, autogen, cfengine, cflow, classpath, combine, complexity,
>   cpio, freeimpi, freetalk, gama, gnats, gnu-pw-mgr, gnugo, gnuit, gnupod,
>   hurd, indent, libcdio, libjit, oleo, plotutils, radius, sqltutor, tar.
> 
> That's definitely more than nobody.
> 
> Bruno

OK it doesn't do any harm to keep the texi2html support in.

The patch I sent applied for both texi2html and texi2any, although I
hadn't tested it with texi2html.