bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash not portable to C23


From: Chet Ramey
Subject: Re: Bash not portable to C23
Date: Mon, 27 Mar 2023 20:06:27 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 3/26/23 7:53 PM, Paul Eggert wrote:
On 2023-03-24 12:04, Chet Ramey wrote:
However, Bash's devel branch still has old-style function definitions and therefore won't compile with a strict C23 compiler. For example, get_variable_value in variables.c is old-style. I assume there would be interest in fixing remaining areas where Bash won't port to C23?

Please report those as you find them.

I reported many of the ones I found to bug-bash just now. Many more such issues remain, unfortunately.

Well, since `strict C23' compilers won't be the default for a while, I
think we've got some time.


In looking into this I had some trouble reading the code - perhaps you could let me know if there's a roadmap for newbies? Or if there isn't one perhaps we could write one. That might help attract other people to make further improvements.

There's nothing like that per se; the closest thing is in the bash
distribution as

doc/aosa-bash-full.pdf

* Ignore everything under the CWRU directory, because it does not contribute anything to any builds. Similarly for lib/posixheaders.old and support/config.*.*. (What other code should I ignore, and what's the motivation for keeping the unused code in the repository?)

History, mostly. The devel repository is an auto-generated snapshot of
(most of) the tree I work in. I mostly concern myself with modifying the
sources that contribute to the current build, but there's a lot of history
there that I carry along.

But thanks for the inspiration to clean up some very old stuff.

* Ignore files like 'configure' and 'doc/bash.pdf' that are automatically generated. (Is there a list of which files these are? It's not clear to me.)

For the ultimate authority, look in the Makefiles. Usually the devel branch
`ships' with generated files in different stages of `currentness'; the
exception is y.tab.[ch], since anyone playing with the devel branch should
have bison available (those do get shipped with releases). The man page
and info documentation are usually current. But the documentation isn't
necessary for building with a C23 compiler; there are no source files in
doc/.

* Ignore lib/glob, lib/intl, lib/malloc, and lib/termcap as these are all taken from other projects and fixes should be sent there. (The other lib/* directories belong to Bash, though.)

That's a bad assumption. None of those are `taken from other projects';
bash has as few external dependencies as possible. lib/glob and lib/malloc
are private to bash, and the other two are carried along in case the build
platform doesn't supply them (there are a few that don't supply libintl,
and the configure process searches for ncurses). They're old snapshots --
the lib/termcap directory has existed in more-or-less its current form
since the mid-1990s.

Updating lib/intl is on the list, though, maybe for the next version,
depending on time.

You can feel free to ignore them beyond sending whatever fixes are needed
to compile on your chosen platform, if you like.

* Ignore most of the files in m4/* as they're taken from Gnulib. (Which files?)

All the files in m4/* were taken from gnulib at some point, possibly
filtered through coreutils.

* Ignore the po/* files as they're all automatically generated and/or synced from the Translation Project somehow.

These are not necessary for building on C23.

* Ignore support/config.guess and support/config.sub as it's taken from the GNU config upstream. Likewise for support/config.rpath, taken from GNU Libtool.

Sure.

PS. What are the procedures for syncing from upstream? Is it all done by hand? In other projects we automate this as much as possible - would a patch to do that be welcome?

I sync from upstream when I have to to support something new or modified.
I'm comfortable with that workflow for the time being.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]