Re: [gnu-prog-discuss] An experimental GNU Assembly

[Alfred M. Szmidt]

   > I can't agree that as a whole, the GCS are out of touch with reality. 
Perhaps
   > 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
POSIX-like system.

   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
        "GNU make.)

        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:
        .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
   own.

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:
      
        Don’t 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
is?

   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
      trivia.

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
   supports it).

This code is definitly OK.  C99 is not widley used amongst other
systems, even on GNU systems.