Paul Eggert <[EMAIL PROTECTED]> wrote:
> > -# define program_name program_invocation_name
>
> Let's omit this '#define', and change all uses of program_name to
> program_name in the rest of the code. The other arm of the #if can
> then contain
>
> #define program_invocation_name program_name ()
Simon,
Yoann Vandoorselaere wrote on 2005-10-25:
> As you point out above, the untested netinet/in.h and sys/socket.h
> change might lead to compilation warnings/failure on some systems. It
> would be a good idea to check this specific change on OpenBSD 3.4 for
> example.
I now checked the curren
Thanks for taking this on.
James Youngman <[EMAIL PROTECTED]> writes:
> --- doc/standards.texi25 Dec 2005 23:59:50 - 1.10
> +++ doc/standards.texi6 Jan 2006 11:35:14 -
This part we should funnel through the standards maintainer. There
shouldn't be any problem with i
Simon Josefsson wrote on 2005-10-25:
> I'm using gnulib-tool --lgpl in some projects. All of the *-tests
> modules that I wrote recently are GPL. There isn't really a need for
> these self tests to be available under LGPL, but gnulib-tool complain
> because I used --lgpl. I think it would be fin
Georg Schwarz wrote:
> > findutils 4.2.27 does not compile on IRIX 5.3:
>
> [...]
>
> > cfe: Error: ./mbchar.h: 157: Cannot open file wchar.h for #include
>
> [...]
>
> > IRIX 5.3 does not have wchar.h.
That was a bug in gnulib before 2005-09-26. Now, I believe everything is
fine in gnulib: wchar.
Hello,
I forward to the list this small patch for better
"included libintl" support for review. It is my
intention to do these other things to further improve
integration of intl with gnulib:
* make a gettext-included module that automatically
calls gettextize --intl
on gnulib-tool --import.
*
Paul Eggert wrote on 2005-11-18:
> I prefer putting type qualifiers like "const" after the types they
> modify, as that's more consistent. ...
>
> Not everyone agrees with this style, but I suspect this is often
> because they haven't thought through the consistency issues.
While I know that "cha
Peter Fales wrote on 2005-11-22:
> The error message occurs while building gnulib/lib (as part of
> findutils-4.2.26):
>
> $ make
> make all-am
> make[1]: Entering directory
> build/output/expmake/build/gnucoresrc/build/findutils/gnulib/lib'
> /opt/exp/gnu/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../..
Stepan Kasal wrote on 2005-10-25:
> would the following patch be welcome?
>
> 2005-10-24 Stepan Kasal <[EMAIL PROTECTED]>
>
> * c-stack.c, copy-file.c, execute.c, fatal-signal.c, findprog.c,
> getlogin_r.c, getlogin_r.h, pagealign_alloc.c, pipe.c, pipe.h,
> progreloc.c
* doc/standards.texi: Modify examples to show the new usage pattern
for program_name.
1) The fact that this is ensconced in the coding standards makes me
worry more than ever about compatibility. For one thing, why define the
same symbol program_name as a new, incompatib
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properly.
>
> Perhaps we could ch
Paul Eggert <[EMAIL PROTECTED]> writes:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.
If it's any help, I can tell you what libroken does; I suspect it's
emulating a BSD facility. (In case you don'
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properly.
>
> Perhaps we could ch
13 matches
Mail list logo
