bug-standards
[Top][All Lists]
Advanced

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

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


From: Reuben Thomas
Subject: Re: [gnu-prog-discuss] An experimental GNU Assembly
Date: Tue, 13 Dec 2011 20:58:41 +0000

On 12 December 2011 21:34, Alfred M. Szmidt <address@hidden> wrote:
>
>   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",

Gengetopt is indeed easy to use (at least, I found it so, and Simon
Josefsson agrees), and I've filed sufficient bug reports to make its
output conform to the GCS. (For one or two bugs I've also filed
patches.)

There's also argp, which is in glibc.

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

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

The GCS doesn't have anything helpful to say about Python build
systems anyway. I have recently used automake to install a python
library (in the 'file' program) and found a bug; however, the Python
support is by and large fine. I'm sure the automake maintainers would
love to hear about any shortcomings; I recently audited the autotools
for use with Lua, and found very little that would need to be added to
automake to support Lua as nicely as C.

> Sometimes we have to
> write things in plain make for whatever reason, having the quirky
> behaviour documented helps everyone and doesn't harm anyone.

Sure, but it's not needed often enough to put it front and centre in the GCS.

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

Not nearly enough.

> but we also want to encourage portablity.

And none of my suggestions diminishes portability: the GNU tools I'm
pushing are highly portable.

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

So list some of the best.

> nor can we can't force people to use emacs either.

We can't force people to do anything! Pretty much every line of the
GCS is contravened by some GNU program.

> | These standards cover the minimum of what is important when writing
> | a GNU package.

The trouble is that they don't cover the minimum that is useful, and
they cover many things that are of no use.

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

> Strace isn't available on many platforms.  Recommending non-portable
> tools is always a bad idea.

Not when they run on the platforms used by the vast majority of GNU hackers.

> 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!).

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

> Calling it a waste is unfair,

Studying this mishmash of material teaches one about a tiny fraction
of the portability problems of twenty years ago. That's exactly what I
call a waste of time and brain space. If portability's a problem, use
(and if necessary, study) gnulib. The brilliant thing about gnulib is
that often it's NOT necessary to study it.

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

> and explcitly listing these portability problems is a
> good thing.

It's not: it's a tiny and outdated subset that is listed here.

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

-- 
http://rrt.sc3d.org



reply via email to

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