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