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
