[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnu-prog-discuss] An experimental GNU Assembly
Alfred M. Szmidt
Re: [gnu-prog-discuss] An experimental GNU Assembly
Mon, 12 Dec 2011 16:34:33 -0500
> I can't agree that as a whole, the GCS are out of touch with reality.
> there are a few minor points but they are minor.
Here's just a handful:
1. It talks about K&R C. Is there still a GNU project that's
K&R-compilable without some sort of deproto treatment? Twenty
years after C90, it's time to drop mentions of K&R.
I think this would be a good idea for a poll.
2. "Standards for command-line interfaces" says "The easiest way to do
this is to use getopt to parse them". Nothing about gengetopt or
autoopt, or the hand-rolled easier way that coreutils uses.
Neither gengetopt or autoopt are "easy", they are also very
non-standard. In GNU the war rages on between argp and getopt (both
are in gnulib and easy to use). I think the wording still applies
though, getopt is the easiest way to parse options on a standard
3. Too much low-level detail. For example, the section on "Makefile
conventions" contains the following:
Every Makefile should contain this line:
SHELL = /bin/sh
to avoid trouble on systems where the SHELL variable might be
inherited from the environment. (This is never a problem with
Different make programs have incompatible suffix lists and
"implicit rules, and this sometimes creates confusion or
"misbehavior. So it is a good idea to set the suffix list
explicitly "using only the suffixes you need in the particular
Makefile, like this:
.SUFFIXES: .c .o
All of this advice can be replaced by the advice "use automake". If
you choose not to use automake (which is fine), then you're on your
That is quite unkind to us maintainers, automake doesn't work for all
cases (Python being a good recent example). Sometimes we have to
write things in plain make for whatever reason, having the quirky
behaviour documented helps everyone and doesn't harm anyone.
But let's encourage the use of standard GNU tools which solve
problems for us so that we can avoid having to learn about them,
and use the time to improve GNU.
This is already encouraged, but we also want to encourage portablity.
4. There's no mention of code comprehension tools such as ctags,
let alone the extensive support in Emacs (CDE, Semantic &c.).
There are many such tools, listing all of them wouldn't be helpful,
nor can we can't force people to use emacs either. `make tags' is
already documented in the make-std.texi document in a general fashion.
The GCS and Maintainer guide is to codify standard behaviour and how
to get that behaviour or work around quirks on a system to get that
behaviour, not about specific tools. To wit:
| These standards cover the minimum of what is important when writing
| a GNU package. Likely, the need for additional standards will come
| up. Sometimes, you might suggest that such standards be added to
| this document. If you think your standards would be generally
| useful, please do suggest them.
| You should also set standards for your package on many questions not
| addressed or not firmly specified here. The most important point is
| to be self-consistent---try to stick to the conventions you pick,
| and try to document them as much as possible. That way, your
| program will be more maintainable by others.
There's only a passing mention of valgrind (which I managed to
get added recently).
Valgrind isn't portable, it only works on GNU/Linux x86.
There's no mention of strace.
Strace isn't available on many platforms. Recommending non-portable
tools is always a bad idea.
The following advice is given:
Dont make the program ugly just to placate static analysis
tools such as lint, clang, and GCC with extra warnings options
such as -Wconversion and -Wundef.
But programming with these tools in mind can be extremely
helpful: you can find many bugs with little effort, and
"placating" such tools helps you find more bugs. There should be
more emphasis on using the tools effectively, and less on not
becoming a slave to them.
Passing -Wundef/-Wconversion is simple enough using CFLAGS, the point
is to not make code ugly for the sake of some tool.
5. Insistence on calling NULL "zero". This is of course correct,
but it's outdated, and may confuse newer programmers who are
used to seeing "NULL" everywhere. Most recent GNU code uses
"NULL" when it means a null pointer.
I don't see any such refernces in GCS. Could you point me where it
6. The section "Writing Robust Programs" is a mish-mash of
miscellaneous information which should be integrated elsewhere
where appropriate (e.g. the paragraph about getopt_long), or in
some cases deleted: "You must expect free to alter the contents
of the block that was freed" is simply redundant. If you didn't
learn this from the man page or other manual, then you don't yet
understand free. Similarly, the paragraph about realloc is
subsumed by the advice "to be portable to non-GNU systems, use
gnulib". The GCS is not the place for detailed advice about
non-GNU systems, the "G" stands for "GNU".
We also support non-GNU systems, so documenting behaviour for this is
important as well if it affects alot of GNU programs.
7. Not enough reliance on gnulib. The section "Calling system
functions" now has a few paragraphs on gnulib, but still insists
on listing portability problems which are a) probably out of
date, and b) where they aren't, are solved by gnulib. Another
example of the GCS wasting hacker headspace with outdated
Calling it a waste is unfair, one might not be able to use gnulib in
all situations, and explcitly listing these portability problems is a
good thing. The information is neither a waste, or outdated.
8. Excessive historicisms:
For example, the following code is ok:
printf ("size = %lu\n", (unsigned long) sizeof array);
That code is NOT OK, it should be using a size_t specifier, %z. But
that's not possible until we recommend C99 (which we should, as GCC
This code is definitly OK. C99 is not widley used amongst other
systems, even on GNU systems.
- Re: [gnu-prog-discuss] An experimental GNU Assembly,
Alfred M. Szmidt <=