Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

[Bruno Haible]

Paul Eggert wrote:
> > How about changing this to use __builtin_constant_p instead of 
> > __OPTIMIZE__? I.e., use the comma expression if __builtin_constant_p 
> > (status), and use the statement expression otherwise.
> 
> I gave that a shot by installing the attached.

Oh, I see now what you meant. That's clever. So clever that it
deserves comments :-)


2023-06-03  Bruno Haible  

error: Improve comments.
* lib/error.in.h (__gl_error_call): Add more comments.

diff --git a/lib/error.in.h b/lib/error.in.h
index 279258f63e..ef4b3c3815 100644
--- a/lib/error.in.h
+++ b/lib/error.in.h
@@ -50,13 +50,21 @@
 #endif
 
 /* Helper macro for supporting the compiler's control flow analysis better.
-   It evaluates its arguments only once.  It uses __builtin_constant_p
-   and comma expressions to work around GCC false positives.
+   It evaluates its arguments only once.
Test case: Compile copy-file.c with "gcc -Wimplicit-fallthrough".  */
 #ifdef __GNUC__
+/* Use 'unreachable' to tell the compiler when the function call does not
+   return.  */
 # define __gl_error_call1(function, status, ...) \
 ((function) (status, __VA_ARGS__), \
  (status) != 0 ? unreachable () : (void) 0)
+/* If STATUS is a not a constant, the function call may or may not return;
+   therefore -Wimplicit-fallthrough will produce a warning.  Use a compound
+   statement in order to evaluate STATUS only once.
+   If STATUS is a constant, we don't use a compound statement, because that
+   would trigger a -Wimplicit-fallthrough warning even when STATUS is != 0,
+   when not optimizing.  This causes STATUS to be evaluated twice, but
+   that's OK since it does not have side effects.  */
 # define __gl_error_call(function, status, ...) \
 (__builtin_constant_p (status) \
  ? __gl_error_call1 (function, status, __VA_ARGS__) \

Re: [PATCH] propername-lite: new module

[Bruno Haible]

Paul Eggert wrote:
> * pygnulib/GLEmiter.py (GLEmiter.po_Makevars):
> Treat proper_name_lite like proper_name_utf8.

The preferred implementation of gnulib-tool is still the shell script.
Therefore we need to do gnulib-tool changes to both implementations, in sync.
I'm therefore applying this:


2023-06-03  Bruno Haible  

gnulib-tool: Keep in sync with last change to gnulib-tool.py.
* gnulib-tool (func_emit_po_Makevars): Treat proper_name_lite like
proper_name_utf8.

diff --git a/gnulib-tool b/gnulib-tool
index 91461042cd..13e3ff2970 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -4046,6 +4046,7 @@ XGETTEXT_OPTIONS = \
   --keyword=_ --flag=_:1:pass-c-format \
   --keyword=N_ --flag=N_:1:pass-c-format \
   --keyword='proper_name:1,"This is a proper name. See the gettext manual, 
section Names."' \
+  --keyword='proper_name_lite:1,"This is a proper name. See the gettext 
manual, section Names."' \
   --keyword='proper_name_utf8:1,"This is a proper name. See the gettext 
manual, section Names."' \
   --flag=error:3:c-format --flag=error_at_line:5:c-format
 

Re: [PATCH] propername-lite: new module

[Bruno Haible]

Paul Eggert wrote:
> +/* Return the localization of the name spelled NAME_ASCII in ASCII,
> +   and NAME_UTF8 in UTF-8.  This function needs less infrastructure
> +   than proper_name and proper_name_utf8.  */
> +extern const char *proper_name_lite (const char *name_ascii,
> + const char *name_utf8);

What are the functional differences between proper_name_lite and
proper_name_utf8 ? This comment does not tell it. I'm therefore
adding these comments:


2023-06-03  Bruno Haible  

propername-lite: Improve documentation.
* lib/propername.h: Describe functional differences between
proper_name_lite and proper_name_utf8.

diff --git a/lib/propername.h b/lib/propername.h
index eced2e86da..7bd57b24a4 100644
--- a/lib/propername.h
+++ b/lib/propername.h
@@ -45,7 +45,7 @@
  ...
  Written by Danilo Segan and Bruno Haible.
 
-   The 'propername' and 'propername-lite’ modules do this. Plus, for
+   The 'propername' and 'propername-lite' modules do this. Plus, for
languages that do not use the Latin alphabet, they allow a translator
to write the name using that different writing system. In that case the
propername and propername_utf8 output will look like this:
@@ -75,7 +75,7 @@
 proper_name_utf8 should use octal escapes, not UTF-8 - e.g.,
 "Fran\303\247ois Pinard", not "François Pinard".  Doing it
 this way can avoid mishandling non-ASCII characters if the
-source is recoded to non-UTF8, or if the compiler does not
+source is recoded to non-UTF-8, or if the compiler does not
 treat UTF-8 as-is in character string contents.
 
 (Optionally, here you can also add / * TRANSLATORS: ... * / comments
@@ -88,6 +88,17 @@
 In the original Cyrillic it is "Данило Шеган".  * /
 proper_name_utf8 ("Danilo Segan", "Danilo \305\240egan"),
 proper_name ("Bruno Haible"));
+
+   Differences between proper_name_utf8 and proper_name_lite:
+   * proper_name_lite uses the localization provided by the translator.
+ If there is no localization, it uses the name with Unicode characters
+ only in UTF-8 locales, otherwise it uses the original name in English.
+   * proper_name_utf8 is more elaborate:
+ - It uses the name with Unicode characters also when the locale encoding
+   is not UTF-8 but contains the necessary characters (e.g. ISO-8859-x or
+   GB18030).
+ - If there is a localization, it produces a better result when the
+   translator has given a poor localization.
  */
 
 #ifndef _PROPERNAME_H

Re: gnulib-tool.py consider automake_subdir=false support

[Bruno Haible]

Hi Mitch,

> I hope to have some semi-quality patches to submit soon enough.
> ...
> I do see sed being used in a few other places.  Of
> course I could likely put a patch together to emulate that in python as
> well.

It's nice that you consider enhancing gnulib-tool.py. But don't underestimate
the task:
  - It's less about hacking than about testing. For every change that one
makes in gnulib-tool.py, one needs to prepare a module or Makefile.am
for testing it, run gnulib-tool and gnulib-tool.py with the same options,
and compare the results.
  - Last time I worked on syncing gnulib-tool.py with gnulib-tool (in August
2022), I noticed that there's still at least 1 man-month of work to be
done.

> I have been very grateful for gnulib-tool.py as it results in some massive
> bootstrap speed improvements (over 10x) on Windows.

In which environment did you make these measurements? Cygwin? MSYS2? WSL?
I would expect that WSL is faster than Cygwin or MSYS2 regarding process
forking and shell script execution.

On Unix, gnulib-tool.py is only about 2-3x as fast as gnulib-tool.

You could consider installing a Linux distro and using that for running
gnulib-tool.

Bruno

classpath, csharpexec: Avoid "candidate for attribute 'malloc'" warning

[Bruno Haible]

In GNU gettext, I see these warnings when compiling with gcc 13, warnings,
and -O2:

gettext-tools/gnulib-lib/classpath.c:97:1: warning: function might be candidate 
for attribute 'malloc' [-Wsuggest-attribute=malloc]
gettext-tools/gnulib-lib/csharpexec.c:36:23: warning: function might be 
candidate for attribute 'malloc' [-Wsuggest-attribute=malloc]
gettext-tools/gnulib-lib/csharpexec.c:57:23: warning: function might be 
candidate for attribute 'malloc' [-Wsuggest-attribute=malloc]

This patch follows the advice.


2023-06-03  Bruno Haible  

classpath, csharpexec: Avoid "candidate for attribute 'malloc'" warning.
* lib/classpath.h (set_classpath): Mark with attribute 'malloc'.

diff --git a/lib/classpath.h b/lib/classpath.h
index abcb4cbe40..65123140cf 100644
--- a/lib/classpath.h
+++ b/lib/classpath.h
@@ -15,6 +15,11 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see .  */
 
+/* This file uses _GL_ATTRIBUTE_MALLOC.  */
+#if !_GL_CONFIG_H_INCLUDED
+ #error "Please include config.h first."
+#endif
+
 /* Return the new CLASSPATH value.  The given classpaths are prepended to
the current CLASSPATH value.   If use_minimal_classpath, the current
CLASSPATH is ignored.  */
@@ -25,7 +30,8 @@ extern char * new_classpath (const char * const *classpaths,
 /* Set CLASSPATH and returns a safe copy of its old value.  */
 extern char * set_classpath (const char * const *classpaths,
  unsigned int classpaths_count,
- bool use_minimal_classpath, bool verbose);
+ bool use_minimal_classpath, bool verbose)
+ _GL_ATTRIBUTE_MALLOC;
 
 /* Restore CLASSPATH to its previous value.  */
 extern void reset_classpath (char *old_classpath);

Re: gnulib-tool.py consider automake_subdir=false support

[Mitch Capper]

> It's nice that you consider enhancing gnulib-tool.py. But don't
underestimate
the task:

Yes, this suggestion was _only_ to support situations where no
automake-subdir was required and we stripped the path.I have automated
several build packages so could likely automate testing of the
gnulib-tool.py vs gnulib-tool on them both and seeing the differences.   Is
there a set of packages normally tested against?  Right now with the manual
sed hack I am using it successfully with tar, patch, gzip, findutils,
bash.  The other patches I mention are targeting the greater gnulib library
rather than gnulib-tool.py specifically (as for many packages it has been
working just great).

> > I have been very grateful for gnulib-tool.py as it results in some
massive
> > bootstrap speed improvements (over 10x) on Windows.

>In which environment did you make these measurements? Cygwin? MSYS2? WSL?

MSYS2.  I have WSL and plenty of linux machines but my current side project
is native MSYS2 MSVC/cl.exe compiling.  Honestly the 10x was conservative.
With AV off, on a fairly quality SSD drive running bootstrap on tar (with a
good number of gnulib modules) the speed is:

time /WIN64LinuxBuild/build/f_tar_build.sh
./bootstrap: gnulib/gnulib-tool.py  --no-changelog
--aux-dir=build-aux --doc-base=doc --lib=libgnu --m4-base=m4/
  --source-base=gnu/ --tests-base=tests --local-dir=gl
 --without-tests --symlink --import ...

real0m35.359s
user0m4.792s
sys 0m18.634s

vs shell bootstrapper:
real17m40.540s
user3m18.828s
sys 8m44.022s

Which is a good 30x speedup.

I will also note that it is running the python version and then running the
shell version with no actual module changes.  I would assume that to be one
of the fastest bootstrapping options.

Obviously WSL with native forking will destroy windows process creation any
day, and dealing with it isn't an issue.  When you have dozens of processes
being created and destroyed every few seconds https://imgur.com/a/M96S72J
it is easy to get the why. I am just mentioning how nice the tool has been
when I can use it for packages.  As I sometimes was running the bootstrap
process a few dozen times a day it would be the difference between waiting
and tabbing away to do something else:)

~Mitch (they/them)