Re: libposix stuff

[Bruce Korb]

On 11/07/10 12:40, Bruno Haible wrote:
>>  /* The calling program should define program_name and set it to the
>>     name of the executing program.  */
>> -extern char *program_name;
>> +char *program_name;
>> ...
>> +      char const *p = program_name ? program_name : "unknown";
> 
> No, this is not OK, for two reasons:
>   1) It will cause a link error for all programs that define the 
> 'program_name'
>      variable, on all non-ELF platforms (mainly MacOS X and Woe32).

I remember back in the mid-70's writing C code that used that
very technique for declaring external variables.  "a.out" format:
    char *program_name;
this on a line by itself was both a declaration and a definition.
It strikes me as quite odd that new formats would come along and
require the "extern" keyword to make it a non-definition.  I believe
you, but still quite odd.

>> How's "d"?
> Yes, why not? You don't even need to fuss with modules/.gitignore. Just
> remove modules/libposix when you're done.
> 
> Or create this modules/libposix in a temporary directory:
>   $ mkdir tmp
>   $ mkdir tmp/modules
>   $ func_create_libposix_module > tmp/modules/libposix

OK, "e" then. :)

> There is some code for determining the program's name ad-hoc for MacOS X
> and Woe32 in progreloc.c. But for HP-UX, I don't know...
> 
> If you don't have access to these systems and no one else find a good
> solution, then you will likely have to document: "Before using libposix,
> you have to invoke set_program_name(argv[0]);" and add the module 'progname'
> to libposix. I think that's an acceptable compromise: many users of gnulib
> have done the same for the last 7 years.

We can add the convolution for platforms that support it, another day.
But in some ways, I am a stubborn cuss.  segfaulting is just not
an acceptable error reporting mechanism.  Instead:
    fputs("error call fails -- set_program_name not called\n", stderr);
    abort();
This is a hint to a developer's customer, too.

>> $ ls -1 $(allbut usr/local/include/*.h - $(
>>> > > egrep -l '#ifndef _LIBPOSIX_' usr/local/include/*.h) )
>> > usr/local/include/arg-nonnull.h
>> > usr/local/include/iconv_open-aix.h
>> > usr/local/include/iconv_open-hpux.h
>> > usr/local/include/iconv_open-irix.h
>> > usr/local/include/iconv_open-osf.h
>> > usr/local/include/iconv_open-solaris.h
>> > usr/local/include/inttypes.h
>> > usr/local/include/unitypes.h
>> > usr/local/include/unused-parameter.h
>> > usr/local/include/warn-on-use.h
> The only file in this list that contains public API is inttypes.h.
> The others should not be installed in a public location.
> 
> The 'Include:' section of the module descriptions tells you about
> this. Files that are not mentioned in the 'Include:' section of
> any module description are private.

This is all being driven off of a script.  Does this mean that this
script is expected to parse the contents of the modules files?
It would seem to me that when gnulib-tool constructs the makefile.am's,
it should ensure its correctness and not require my script to parse
modules files and re-edit its output.  What are you saying, please?

Thank you.  Regards, Bruce