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

[Reuben Thomas]

On 13 December 2011 22:24, Alfred M. Szmidt <address@hidden> wrote:
>   > 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

You can simply build it. Most GNU tools are not available on POSIX
systems (by definition!).

> or random GNU
> systems where maintainers develop.

apt-get install gengetopt

on a typical "random GNU system".

> All options are described in argp_option, wether one finds argp hard
> to maintain is a personal opinion.

Simon Josefsson says: "I used argp for several projects long time ago
(and worked on the initial import of argp into gnulib).  My experience
was that the code needed to support argp ended up being around the
same size of a hand-written parser a'la coreutils without its
flexibility."

> I only took a quick glance at gengetopt, and it requires about the
> same amount of code,

The important thing with gengetopt is that each item is only mentioned
once: no repeating for help messages, variable initialization code &c.

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

More importantly, several architectures; mostly importantly, the
architectures and OSes that most developers actually use.

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

I'm not sure what's so hard about searching for "zero", but here are
the line numbers for the current CVS standards.texi, from M-x occur.
It turns out that there are only ten instances (not eleven as in the
web page I browsed) but the numbering I gave above still holds; just
ignore "eleventh". The lines which would better say "NULL" than "zero"
are 630, 635, 2334.

    630:returned zero.  Check @code{realloc} even if you are making the block
    635:zero.  GNU @code{realloc} does not have this bug: if it fails, the
   1601:@item ignore-zeros
   2290:@item zeros
   2334:memory and give a fatal error if @code{malloc} returns zero.
   2586:/* Nonzero means truncate lines in the display;
   2587:   zero means continue them.  */
   2784:This example uses zero without a cast as a null pointer constant.
   2965:from zero.
   3839:should exit with nonzero status.

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

gnulib supplies it.

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

gnulib is huge, but a project only imports the bits it needs. I have
used automake and autoconf with one-file C projects precisely because
it makes the amount of code I have to write smaller, and makes it
faster to write, easier to build and more reliable (because I don't
invent the wheel for standard features). There is no project too small
for these tools.

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

I have raised it; my suggestion was rejected.

-- 
http://rrt.sc3d.org