gnulib bugs on OSX & C++

Here is a simple program to demonstrate two problems with current gnulib: file main.cc: // config.h defines GNULIB_NAMESPACE as gnulib #include #include #include #include int main() { char * dir = gnulib::strndup(gnulib::getcwd(NULL, 32), gnulib::strnlen("Hello!", 5)); int fd = gnulib::

[PATCH] Add missing parenthesis in manywarnings example

--- ChangeLog |5 + doc/manywarnings.texi |2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6ff91cb..be00156 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-04-08 James Youngman + + * doc/manywarnings.tex

Re: portability of 'printf' command

Karl wrote: > I fully recognize that people are still running Solaris 7 (and probably > older versions) on mission-critical and other systems. But, how many of > those systems are (a) installing brand-new GNU packages (which > presumably wouldn't be happening on mission-critical systems) *and* >

Re: portability of 'printf' command

It seems that a conclusion has been reached that it is ok to depend on printf. Cheers! Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: portability of 'printf' command

Bob Friesenhahn wrote: > The versions of SunOS which were implied to be too old to support were > versions prior to Solaris 8 (SunOS 5.8), rather than SunOS 4. Solaris 5.6 (released in 1997) also already had /usr/bin/printf. Bruno

Re: portability of 'printf' command

"Dr. David Kirkby" writes: > Solaris 7 lacks this, so one does not have to go back as far as you believe. No, Solaris 7 has /usr/bin/printf. If memory serves, it also has a /bin/ksh that supports printf. See, for example,

Re: portability of 'printf' command

Hi Harlan, >From my POV, as long as one can bootstrap to the point where there is a sufficient base of utilities, all is well. I agree. "we can't get there from here". As has been said: install (say) coreutils-8.4, which does not require printf. This gives you printf. Then proceed

Re: portability of 'printf' command

Solaris 7 lacks this, so one does not have to go back as far as you believe. I fully recognize that people are still running Solaris 7 (and probably older versions) on mission-critical and other systems. But, how many of those systems are (a) installing brand-new GNU packages (which presu

Re: Os2

On 5-04-10 15:35, Eric Blake wrote: Hi Eric, Any news about some testing ? [adding bug-gnulib] On 04/03/2010 03:48 PM, Elbert Pol wrote: Hello all, I tried today to port it to OS2 I used Gcc 4.4.2 and the make fails here: In file included from fnmatch.c:175: fnmatch_loop.c: In function

Re: portability of 'printf' command

Bob Friesenhahn wrote: > On Wed, 7 Apr 2010, Karl Berry wrote: >> >> In any event, I suspect that anyone using such an ancient system *and* >> installing a brand-new version of package foo that uses printf in its >> autoconfery would also have installed coreutils (or at least sh-utils), >> and ther

Re: portability of 'printf' command

Karl Berry wrote: > And the reason that I would _like_ to have printf(1) added to the list > of portable tools is because of the number of non-portable shell scripts > that are currently using 'echo -n', which is doomed to failure in some > shells, instead of printf because printf w

Re: portability of 'printf' command

Karl Berry wrote: And the reason that I would _like_ to have printf(1) added to the list of portable tools is because of the number of non-portable shell scripts that are currently using 'echo -n', which is doomed to failure in some shells, instead of printf because printf was not

Re: portability of 'printf' command

On Wed, 7 Apr 2010, Karl Berry wrote: In any event, I suspect that anyone using such an ancient system *and* installing a brand-new version of package foo that uses printf in its autoconfery would also have installed coreutils (or at least sh-utils), and therefore will have printf after all. I

Re: portability of 'printf' command

And the reason that I would _like_ to have printf(1) added to the list of portable tools is because of the number of non-portable shell scripts that are currently using 'echo -n', which is doomed to failure in some shells, instead of printf because printf was not listed in the permi

[PATCH] maint.mk: add a PATH crosschecking syntax-check rule

Just pushed: Here's a new syntax-check. It has spotted inconsistencies in at least two projects already. >From bfffe408f8b375fd0989266bd8c01580be26d1a8 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 7 Apr 2010 13:45:59 +0200 Subject: [PATCH] maint.mk: add a PATH crosschecking syntax-check