Re: doc: Add appendix about Gnulib history
Hi Collin, > > doc: Add appendix about Gnulib history. > > * doc/gnulib-history.texi: New file. > > * doc/gnulib.texi: Include it. > > Interesting section, thanks. I wrote it also as an answer to misguided statements that "gnulib is mainly about porting to non-Linux platforms" [1]. Bruno [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/YWMNOEJ34Q7QLBWQAB5TM6A2SVJFU4RV/
Re: doc: Add appendix about Gnulib history
On 5/3/24 11:32 PM, Paul Eggert wrote: > Not quite, because it doesn't check for padding bits. Sorry, I should have clarified excluding that part... > Also, your code assumes that preprocessor arithmetic works the same as > runtime arithmetic. Although C23 guarantees this (because it > guarantees two's complement) I don't think C17 and earlier do. If > memory serves, they even allow mixed-runtime systems, where arithmetic > is sometimes ones' complement and sometimes two's. Ah, interesting. Thanks for the explanation. Collin
Re: doc: Add appendix about Gnulib history
On 2024-05-03 17:14, Collin Funk wrote: Also about this comment in intprops-internal.h: /* This include file assumes that signed types are two's complement without padding bits; the above macros have undefined behavior otherwise. If this is a problem for you, please let us know how to fix it for your host. This assumption is tested by the intprops-tests module. */ If you want to check this at compile time I think this should work: Not quite, because it doesn't check for padding bits. Also, your code assumes that preprocessor arithmetic works the same as runtime arithmetic. Although C23 guarantees this (because it guarantees two's complement) I don't think C17 and earlier do. If memory serves, they even allow mixed-runtime systems, where arithmetic is sometimes ones' complement and sometimes two's. (Almost nobody cares about this theoretical possibility of course, which is why the Gnulib manual says not to worry about it.)
Re: doc: Add appendix about Gnulib history
Hi Paul, On 5/3/24 2:50 PM, Paul Eggert wrote: >> The macros for compilers who don't support GCC's builtins are >> really clever. They don't look like they were too much fun to write >> though. :) > > Actually they were fun in a twisted sort of way. My secret was to not > work on them more than 30 minutes at a time (to prevent going > crazy...). Haha, nested ternary operators always hurt my brain. It would take me much longer than you. Also about this comment in intprops-internal.h: /* This include file assumes that signed types are two's complement without padding bits; the above macros have undefined behavior otherwise. If this is a problem for you, please let us know how to fix it for your host. This assumption is tested by the intprops-tests module. */ If you want to check this at compile time I think this should work: #if (−1 & 3) == 1 # error "signed magnitude" #elif (-1 & 3) == 2 # error "one's complement" #elif (-1 & 3) == 3 /* two's complement */ #endif /* or */ typedef _gl_intprops_verify_twos_complement[(-1 & 3) == 3 ? 1 : -1]; Collin
Re: doc: Add appendix about Gnulib history
Collin Funk wrote: > Maybe intprops.h and the stdckdint.h replacement are worth a mention > too. intprops.h is a masterpiece. But Gnulib has more than 1000 modules; therefore in a history section, we can only mention groups of modules (like "multithreading", "", etc.). Otherwise it would be too long to read; sorry. Bruno
Re: doc: Add appendix about Gnulib history
On 2024-05-03 14:14, Collin Funk wrote: The macros for compilers who don't support GCC's builtins are really clever. They don't look like they were too much fun to write though. :) Actually they were fun in a twisted sort of way. My secret was to not work on them more than 30 minutes at a time (to prevent going crazy...).
Re: doc: Add appendix about Gnulib history
Hi Bruno,
On 5/2/24 11:15 AM, Bruno Haible wrote:
> doc: Add appendix about Gnulib history.
> * doc/gnulib-history.texi: New file.
> * doc/gnulib.texi: Include it.
Interesting section, thanks.
> Providing a substitute / override for a system function was relatively easy.
> Providing a substitute / override for a system header file was significantly
> harder, but was done successively:
> for @code{stdint.h} in 2004,
I didn't realize the header replacements started this early. I'm a big
fan of them.
Maybe intprops.h and the stdckdint.h replacement are worth a mention
too. The macros for compilers who don't support GCC's builtins are
really clever. They don't look like they were too much fun to write
though. :)
> The @samp{gnulib-tool} rewrite in Python, that was started by Dmitry Selyutin
> in 2012 but lay unfinished for many years, was completed by Collin Funk and
> Bruno Haible in 2024.
Thanks for the mention. :)
Collin
doc: Add appendix about Gnulib history
Paul and Jim, feel free to correct this where I'm wrong...
2024-05-02 Bruno Haible
doc: Add appendix about Gnulib history.
* doc/gnulib-history.texi: New file.
* doc/gnulib.texi: Include it.
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index aa0eb57f62..55cf6ebcc9 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -89,6 +89,7 @@
* Build Infrastructure Files:: Non-modules files for the build system.
* Release Management Files::Non-modules files for preparing releases.
* GNU Free Documentation License:: Copying and sharing this manual.
+* Gnulib history::
* Index::
@end menu
@@ -7364,6 +7365,12 @@
@include fdl-1.3.texi
+@node Gnulib history
+@appendix Gnulib history
+
+@include gnulib-history.texi
+
+
@node Index
@unnumbered Index
=== doc/gnulib-history.texi ===
@c Gnulib history
@c Copyright 2024 Free Software Foundation, Inc.
@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.3 or
@c any later version published by the Free Software Foundation; with no
@c Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
@c copy of the license is at <https://www.gnu.org/licenses/fdl-1.3.en.html>.
In the beginning, Richard Stallman maintained the regular expression engine
of GNU and made it available to other GNU packages, such as
@code{sed}, @code{awk}, @code{grep}, so that they could use the same engine.
Recall that there was no GNU C library at the time.
A couple of years later, Jim Meyering, who was maintaining
the shell utilities, the file utilities, and the text processing utilities,
collected the common parts of these three packages in the same repository.
Paul Eggert joined in, with code coming from a few GNU packages that he
maintained,
and so did Bruno Haible, with reusable code from the GNU gettext package.
As they cared for portability, many changes in the C code were accompanied
by changes in the build infrastructure.
Copying these changes into packages --- it was all done manually --- became
cumbersome. So they wrote a program, called @samp{gnulib-tool}, that does
this job of copying the requested shared code into a particular package.
This was in 2002.
Providing a substitute / override for a system function was relatively easy.
Providing a substitute / override for a system header file was significantly
harder, but was done successively:
for @code{stdint.h} in 2004,
for @code{stdarg.h}, @code{sys/socket.h}, @code{sys/stat.h} in 2006,
for @code{sys/time.h}, @code{wchar.h} in 2007,
and the development of the corresponding idioms took until 2010.
Unicode string modules (that make up GNU libunistring) were added in 2007--2009.
Modules for numeric functions (@code{}) were added in 2010--2011.
Modules for container data structures were added between 2006 and 2018.
Versatile bit-set modules were added in 2018.
POSIX threads on non-POSIX platforms, as well as ISO C threads on all
platforms, were added in 2019.
The @code{posix_spawn} facility was brought to completion on native Windows
in 2022, providing the world's first @code{posix_spawn} implementation for
this platform.
Support for Android was added in 2023 and immediately used by GNU Emacs
for Android.
Functions for working with Unicode characters in multibyte representation,
based on @code{mbrtoc32}, were added in 2023.
Modules for manipulating the floating-point environment (@code{fenv.h}) were
added in 2023.
The @samp{gnulib-tool} rewrite in Python, that was started by Dmitry Selyutin
in 2012 but lay unfinished for many years, was completed by Collin Funk and
Bruno Haible in 2024.
