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

[Alfred M. Szmidt]

   > they are also very non-standard.

   Assuming you mean "produces non-GCS-compliant output", that's now
   easily fixed in the case of gengetopt, which itself produces
   standard C code, so does not change the dependency footprint for
   users of projects that use it.

By non-standard, I meant not available on POSIX systems or random GNU
systems where maintainers develop.  argp is more standard in this
regard since it comes with gnulib.  gengetopt/autoopt aren't installed
as widley as automake/autoconf either.

   > In GNU the war rages on between argp and getopt (both
   > are in gnulib and easy to use).

   They're both a pain for maintenance as neither supports a single
   source for option description.  Both require far more code to be
   written than the few lines needed by typical gengetopt usage.

All options are described in argp_option, wether one finds argp hard
to maintain is a personal opinion.  I for example have no problem
maintaining argp code.

I only took a quick glance at gengetopt, and it requires about the
same amount of code, indeed it is basically argp but where the
argp_option structutre has been replaced by a different grammar that
isn't as flexible.

In either case, I don't think the GCS is the proper place for this
type of documentation.  The code quality project mentioned before
sounds like a nice place for it.

   > Valgrind isn't portable, it only works on GNU/Linux x86.

   >>From the Valgrind home page: "It runs on the following platforms:
   X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux,
   S390X/Linux, ARM/Android (2.3.x), X86/Darwin and AMD64/Darwin (Mac OS
   X 10.6 and 10.7)."

Thanks, so that has changed to two systems (Android runs Linux); but
that is no where near portable.  It doesn't run on GNU/Hurd,
OpenSolaris, any of the numerous BSDs, etc.  It doesn't run on MIPS,
Sparc, SH, or MC68k.  The claim stands firm, valgrind is not portable.

Also another thing that I think would be better in another document.

   > Passing -Wundef/-Wconversion is simple enough using CFLAGS, the
   > point is to not make code ugly for the sake of some tool.

   Again, the balance is wrong. Maintainers should be encouraged to
   use GCC's warnings, gnulib's syntax checks &c. Just occasionally
   this will require some code uglification, but it's well worth it
   (as witness the major GNU components that use all these tools, and,
   in the case of the gnulib syntax checks, invented the tools!).

I think this is better suited for a different document, e.g. the
quality document mentioned by Karl.

   >   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?

   Just search for "zero". The first, second and fifth occurrences
   would better be "NULL"; the sixth and seventh would be better as
   "false" (as in stdbool.h); the eighth would be better removed
   (there's really no need to make the point about NULL–zero
   equivalence in the GCS); the third, fourth and ninth to eleventh
   are all fine.

I don't see where the GCS insists on calling NULL for zero.  Please
point out the exact line where it does so.

stdbool.h is not available on many platforms, specifically C89
systems.

Please try to stick to one single issue at a time.

   > one might not be able to use gnulib in all situations,

   How could it be not possible to use gnulib in a GNU project? At
   least, commonly enough to warrant separate documentation in the
   GCS?

gnulib is quite big, and might not be worth the extra payload for a
small program of which we have many.  This is another good example
where automake/autoconf might just be a tad bit overkill and why
having the information about portable make is important.

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

   Plenty of GNU code is not yet written in C99, granted (though you
   might be surprised to see how many projects do use C99). But
   there's no reason specifically to document C89 techniques today,
   just as the GCS currently mentions K&R C, but does not go into
   detail about how to write it.

And as I said, multiple times now, I think this is a good idea.
Please raise it.  It won't get done by it self, nor by repeating it.