progreloc.c - what module?

[Ben Pfaff]

The file lib/progreloc.c is not in any module (as far as I can
tell).  Also, there is no header file that prototypes its
functions.  Is this intentional?

-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: progreloc.c - what module?

[Ben Pfaff]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> The file lib/progreloc.c is not in any module (as far as I can
> tell).  Also, there is no header file that prototypes its
> functions.  Is this intentional?

The latter I've now noticed I'm wrong about, but I'm still pretty
sure that the former is true.
-- 
"Sanity is not statistical."
--George Orwell

Re: SKIP_FTRUNCATE_CHECK

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> A gnulib testdir with the module 'ftruncate', cross-compiled to mingw
> (--host=i386-pc-mingw32), showed me this:
>
> configure: error: Your system lacks the ftruncate function.
>   Please report this, along with the output of "uname -a", to the
>   bug-coreutils@gnu.org mailing list.  To continue past this point,
>   rerun configure with SKIP_FTRUNCATE_CHECK=yes.
>   E.g., ./configure SKIP_FTRUNCATE_CHECK=yes
>
> Since mingw will still be around for a few years, we need to keep this module.
> (But if you didn't have many reports like this and if mingw is not among the
> porting targets of coreutils, you may of course drop this module from 
> coreutils.)
>
> The ftruncate.m4 has a FIXME with the date 2007. Does this mean that you can
> now remove the SKIP_FTRUNCATE_CHECK? Having to rerun configure is a bit
> annoying for the installer.

Thanks for the report.
This is the first I've heard about anyone hitting that diagnostic.
For now, I'll push the date back to 2010.

* m4/ftruncate.m4: Adjust comment to give this module a 3-year reprieve.
Prompted by a report from Bruno Haible that mingw lacks ftruncate.

Index: m4/ftruncate.m4
===
RCS file: /sources/gnulib/gnulib/m4/ftruncate.m4,v
retrieving revision 1.12
diff -u -p -r1.12 ftruncate.m4
--- m4/ftruncate.m4 19 Feb 2007 02:24:42 -  1.12
+++ m4/ftruncate.m4 19 Feb 2007 18:19:29 -
@@ -1,4 +1,4 @@
-#serial 11
+#serial 12

 # See if we need to emulate a missing ftruncate function using fcntl or chsize.

@@ -7,8 +7,10 @@
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.

-# FIXME: remove this macro, along with all uses of HAVE_FTRUNCATE in 2007,
-# if the check below provokes no reports.
+# FIXME: remove this macro, along with all uses of HAVE_FTRUNCATE in 2010,
+# if the check below provokes no more reports.  So far, the only report
+# arose from a test build of this gnulib module, cross-compiling to mingw:
+# 

 AC_DEFUN([gl_FUNC_FTRUNCATE],
 [

Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored

[Paul Eggert]

Following up on today's bug-bison message
.

This seems to be due to the new stdlib module in gnulib.  stdlib uses
the new trick of something like this:

  #include "///usr/include/stdlib.h"
  ... gnulib fixups go here ...

But Bison has exposed a problem with this approach.  The approach
causes GCC to treat /usr/include/stdlib.h as if it were not a system
include header, which in turn causes GCC to issue diagnostics that it
would not otherwise generate (since GCC is more tolerant of problems
inside system include headers).  In this particular case, GCC
complains about the following line in /usr/include/stdlib.h, which is
probably bogus with GCC 4.1.1 (the __malloc__ attribute isn't
documented, so I'm not sure):

 extern int posix_memalign (void **__memptr, size_t __alignment, size_t __size)
 __THROW __attribute_malloc__;

A simple fix would be for gnulib stdlib.h to include the system
stdlib.h this way:

  #if HAVE_INCLUDE_NEXT
  # include_next 
  #else
  # include "///usr/include/stdlib.h"
  #endif
  ... gnulib fixups go here ...

I worry a bit that this would not work in some non-GCC compilers; they
would complain about the include_next even though they're not
executing it.  But perhaps we can cross this bridge when we come
to it (if we ever do).

Another possibility would be to change the Makefile so that it
replaces "#include @ABSOLUTE_STDLIB_H@" with "#include_next
" on GCC platforms.  This will work with ordinary
compilations, but as I understand it Bruno wants to be able to
generate .h files that can be included by arbitrary compilers.

Another, even trickier possibility, would be to fiddle with #pragma
GCC system_header, but I'd rather avoid that if I can.

Perhaps we should try the HAVE_INCLUDE_NEXT method first.  If it
works, we're done.  Otherwise we can fall back on the trickier
possibilities.

Re: question about getcwd

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Does the following accurately describe the behaviour of getcwd() in gnulib?
> I'm asking because lib/getcwd.c mentions a certain GNU extension, whereas
> lib/getcwd.h merely refers to the POSIX spec.

I think the intent was to implement the GNU extension.

FYI: getcwd.c fix: don't use closed FD

[Jim Meyering]

I don't know of a system on which this bug can be exercised.
I found it only by manually building getcwd.o, even though
this system already has a mostly-working one.
The symptom is that getcwd would always fail with ENOENT.

Don't use FD after a successful "fdopendir (fd)".
* lib/getcwd.c (__getcwd) [AT_FDCWD]: fdopendir (fd) usually closes fd.
Reset it by calling dirfd on the just-obtained DIR*.

Index: lib/getcwd.c
===
RCS file: /sources/gnulib/gnulib/lib/getcwd.c,v
retrieving revision 1.19
diff -u -p -r1.19 getcwd.c
--- lib/getcwd.c19 Feb 2007 02:24:42 -  1.19
+++ lib/getcwd.c19 Feb 2007 20:03:17 -
@@ -234,6 +234,8 @@ __getcwd (char *buf, size_t size)
   dirstream = fdopendir (fd);
   if (dirstream == NULL)
goto lose;
+  /* Reset fd.  It may have been closed by fdopendir.  */
+  fd = dirfd (dirstream);
   fd_needs_closing = false;
 #else
   dirstream = __opendir (dotlist);

Re: question about getcwd

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> Does the following accurately describe the behaviour of getcwd() in gnulib?
> I'm asking because lib/getcwd.c mentions a certain GNU extension, whereas
> lib/getcwd.h merely refers to the POSIX spec.
>
> /* Get the name of the current working directory, and put it in SIZE bytes
>of BUF.
>Return BUF if successful, or NULL if the directory couldn't be determined
>or SIZE was too small.
>See the POSIX:2001 specification
>.
>Additionally, the gnulib module 'getcwd' guarantees the following GNU
>extension: If BUF is NULL, an array is allocated with 'malloc'; the array
>is SIZE bytes long, unless SIZE == 0, in which case it is as big as
>necessary.  */
> extern char * getcwd (char *buf, size_t size);

It omits an important detail:
Unlike most other getcwd implementations, this one may *potentially*
return a name that is arbitrarily long (and hence much longer than PATH_MAX).

Currently that doesn't ever happen because the only systems
that have openat support also have a mostly-working getcwd,
and *it* imposes the PATH_MAX maximum.

However, if a system were to have a getcwd that fails the mostly-working
test and does have openat support (or if you just include "openat.h"
near the top of getcwd.c to use /proc-based openat emulation), then
the replacement getcwd function can return a very long name.  I've just
tested it using the following patch:

  [note the addition of the dirfd call -- otherwise, it didn't work at all;
   the fdopendir call would end up closing fd.  I've just checked in that
   latter hunk. ]

Index: getcwd.c
===
RCS file: /sources/gnulib/gnulib/lib/getcwd.c,v
retrieving revision 1.19
diff -u -p -r1.19 getcwd.c
--- getcwd.c19 Feb 2007 02:24:42 -  1.19
+++ getcwd.c19 Feb 2007 19:36:04 -
@@ -27,6 +27,7 @@
 #include 
 #include 

+#include "openat.h"
 #include  /* For AT_FDCWD on Solaris 9.  */

 #ifndef __set_errno
@@ -234,6 +235,7 @@ __getcwd (char *buf, size_t size)
   dirstream = fdopendir (fd);
   if (dirstream == NULL)
goto lose;
+  fd = dirfd (dirstream);
   fd_needs_closing = false;
 #else
   dirstream = __opendir (dotlist);

and the following main program:

#include 
#include 
#include 
#include 
#include "error.h"
int
main()
{
  char *t = getcwd (0, 0);
  if (t == NULL)
error (1, errno, "getcwd failed");
  printf ("%s\n", t);
  free (t);
  return 0;
}
=
Running it from the bottom of a hierarchy 20001 levels deep, with
each directory having a 1-letter name, I get this:

$ z-run /cu/lib/a.out|wc -c
40003

That is why save-cwd.c uses chdir_long (not chdir) to process
a name returned by getcwd.

Re: question about getcwd

[Jim Meyering]

I wrote:
...
> Unlike most other getcwd implementations, this one may *potentially*
> return a name that is arbitrarily long (and hence much longer than PATH_MAX).
>
> Currently that doesn't ever happen because the only systems
> that have openat support also have a mostly-working getcwd,
> and *it* imposes the PATH_MAX maximum.

To dot an "i", there is no explicit PATH_MAX-based limitation in this
implementation, since indeed, PATH_MAX need not be defined at all.

But in an environment where PATH_MAX is defined, this function can return
a directory name that is longer, and is thus not easy to manipulate with
standard functions, like open, stat, chdir, rmdir, etc.

Re: progreloc.c - what module?

[Bruno Haible]

Ben Pfaff wrote:
> The file lib/progreloc.c is not in any module (as far as I can
> tell).

Yes [1]. This "relocatable" stuff is in a temporary state. Ideally it should
be integrated into autoconf and automake. Do you have time to work on that
with me?

   Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00108.html

Printf for gnulib?

[Daniel Jacobowitz]

This is actually unrelated to my printf-args question from a couple
of months ago - but I may be back to that depending on the answer.

Is there any interest in a full C99 printf in gnulib?  Right now,
there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
The problem with these is that they punt to the system's underlying
printf for some things.  That's an issue e.g. with Windows's %I64d
versus %lld, and with C99 formats like %a.

If there is interest, I'm sure I'll have further questions (starting
with "is there anyone who wants to do it for me" :-).

My motivation is for GDB; we recently discussed adding support for
printing hex floating point, but the implementation relied on the
system's printf already having support for it.

Of course I'm pretty sure there are easier ways to solve that problem
than this one.  So if there's only lukewarm interest, I may do
something specific to hex float.  We already have routines to
decompose FP numbers.

-- 
Daniel Jacobowitz
CodeSourcery

Re: progreloc.c - what module?

[Daniel Jacobowitz]

On Mon, Feb 19, 2007 at 11:27:26PM +0100, Bruno Haible wrote:
> Ben Pfaff wrote:
> > The file lib/progreloc.c is not in any module (as far as I can
> > tell).
> 
> Yes [1]. This "relocatable" stuff is in a temporary state. Ideally it should
> be integrated into autoconf and automake. Do you have time to work on that
> with me?

Is that really necessary?  I know that GCC manages something similar
that doesn't require any makefile adjustment - at most some defines
added to config.h.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Printf for gnulib?

[Bruce Korb]

Daniel Jacobowitz wrote:
> This is actually unrelated to my printf-args question from a couple
> of months ago - but I may be back to that depending on the answer.
> 
> Is there any interest in a full C99 printf in gnulib?  Right now,
> there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
> The problem with these is that they punt to the system's underlying
> printf for some things.  That's an issue e.g. with Windows's %I64d
> versus %lld, and with C99 formats like %a.
> 
> If there is interest, I'm sure I'll have further questions (starting
> with "is there anyone who wants to do it for me" :-).

Gary Vaughan wrote an extensible printf library:
https://savannah.nongnu.org/projects/libsnprintfv/
that features the ability to register callback functions
for various formatting characters.  The extensions are
pretty easy.  My crucial requirement was to have an
argv style of interface, so for every "v*printf" interface,
this library also has a "*printfv" interface.

It isn't very active because it works pretty well (leastwise
for the way I use it).

Cheers -Bruce

Re: SKIP_FTRUNCATE_CHECK

[Bruno Haible]

Hello Jim,

>   * m4/ftruncate.m4: Adjust comment to give this module a 3-year reprieve.
>   Prompted by a report from Bruno Haible that mingw lacks ftruncate.

I also meant to make life easier to people using mingw. mingw will not have
gone away in three years - that's more a matter of 10-15 years. How about this?


2007-02-19  Bruno Haible  <[EMAIL PROTECTED]>

* m4/ftruncate.m4 (gl_FUNC_FTRUNCATE): Don't request a complaint mail
from mingw users.

*** m4/ftruncate.m4 19 Feb 2007 18:19:34 -  1.13
--- m4/ftruncate.m4 19 Feb 2007 23:14:50 -
***
*** 1,4 
! #serial 12
  
  # See if we need to emulate a missing ftruncate function using fcntl or 
chsize.
  
--- 1,4 
! #serial 13
  
  # See if we need to emulate a missing ftruncate function using fcntl or 
chsize.
  
***
*** 15,34 
  AC_DEFUN([gl_FUNC_FTRUNCATE],
  [
AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
AC_CHECK_FUNCS_ONCE([ftruncate])
if test $ac_cv_func_ftruncate = no; then
  HAVE_FTRUNCATE=0
  AC_LIBOBJ([ftruncate])
  gl_PREREQ_FTRUNCATE
! # If someone lacks ftruncate, make configure fail, and request
! # a bug report to inform us about it.
! if test x"$SKIP_FTRUNCATE_CHECK" != xyes; then
!   AC_MSG_FAILURE([Your system lacks the ftruncate function.
! Please report this, along with the output of "uname -a", to the
! bug-coreutils@gnu.org mailing list.  To continue past this point,
! rerun configure with SKIP_FTRUNCATE_CHECK=yes.
! E.g., ./configure SKIP_FTRUNCATE_CHECK=yes])
! fi
fi
  ])
  
--- 15,41 
  AC_DEFUN([gl_FUNC_FTRUNCATE],
  [
AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
+   AC_REQUIRE([AC_CANONICAL_HOST])
AC_CHECK_FUNCS_ONCE([ftruncate])
if test $ac_cv_func_ftruncate = no; then
  HAVE_FTRUNCATE=0
  AC_LIBOBJ([ftruncate])
  gl_PREREQ_FTRUNCATE
! case "$host_os" in
!   mingw*)
! # Yes, we know mingw lacks ftruncate.
! ;;
!   *)
! # If someone lacks ftruncate, make configure fail, and request
! # a bug report to inform us about it.
! if test x"$SKIP_FTRUNCATE_CHECK" != xyes; then
!   AC_MSG_FAILURE([Your system lacks the ftruncate function.
! Please report this, along with the output of "uname -a", to the
! bug-coreutils@gnu.org mailing list.  To continue past this point,
! rerun configure with SKIP_FTRUNCATE_CHECK=yes.
! E.g., ./configure SKIP_FTRUNCATE_CHECK=yes])
! fi
! esac
fi
  ])
  

Re: check for C99-compliant snprintf

[Albert Chin]

On Fri, Feb 16, 2007 at 04:57:15PM -0800, Ben Pfaff wrote:
> RCS file: /sources/gnulib/gnulib/m4/vsnprintf.m4,v
> retrieving revision 1.2
> diff -u -p -r1.2 vsnprintf.m4
> --- m4/vsnprintf.m4   23 Jan 2005 08:06:57 -  1.2
> +++ m4/vsnprintf.m4   17 Feb 2007 00:56:09 -
> @@ -1,12 +1,27 @@
> -# vsnprintf.m4 serial 2
> -dnl Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc.
> +# vsnprintf.m4 serial 3
> +dnl Copyright (C) 2002, 2003, 2004, 2007 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
>  dnl with or without modifications, as long as this notice is preserved.
>  
>  AC_DEFUN([gl_FUNC_VSNPRINTF],
>  [
> -  AC_REPLACE_FUNCS(vsnprintf)
> +  AC_REQUIRE([gl_AC_NATIVE_W32])
> +  AC_CHECK_FUNCS_ONCE(vsnprintf)
> +  AC_MSG_CHECKING([for C99-compliant vsnprintf])
> +  if test $ac_cv_func_vsnprintf = no || test $gl_cv_native_w32 = yes; then
> +AC_LIBOBJ(vsnprintf)
> +AC_DEFINE(vsnprintf, rpl_vsnprintf,
> +  [Define to rpl_vsnprintf if the replacement function should be used.])
> +AC_MSG_RESULT([no])
> +  else
> +AC_MSG_RESULT([yes])
> +  fi
> +  if test $gl_cv_native_w32 = yes; then
> +AC_LIBOBJ(_vsnprintf)
> +AC_DEFINE(_vsnprintf, rpl__vsnprintf,
> +  [Define to rpl__vsnprintf if the replacement function should be used.])
> +  fi
>AC_CHECK_DECLS_ONCE(vsnprintf)
>gl_PREREQ_VSNPRINTF
>  ])

Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
case on some systems. And, we found that Solaris and AIX 5.1 do not
have a C99-compliant vsnprintf(). The attached program returns -1 on
Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
example.

-- 
albert chin ([EMAIL PROTECTED])
#include 
#include 
#include 

int
doit(char * s, ...)
{
  char buffer[32];
  va_list args;
  int r;

  /* AIX 5.1 and Solaris seems to have a half-baked vsnprintf()
 implementation. The above will return 7 but if you replace
 the size of the buffer with 0, it borks! */
  va_start(args, s);
  r = vsnprintf(buffer, 0, s, args);
  va_end(args);
printf("r: %d\n", r);

  if (r != 7)
exit(1);

  exit(0);
}

int
main(void)
{
  doit("1234567");
  exit(1);
}

Re: SKIP_FTRUNCATE_CHECK

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>>  * m4/ftruncate.m4: Adjust comment to give this module a 3-year reprieve.
>>  Prompted by a report from Bruno Haible that mingw lacks ftruncate.
>
> I also meant to make life easier to people using mingw. mingw will not have
> gone away in three years - that's more a matter of 10-15 years. How about 
> this?
>
>
> 2007-02-19  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * m4/ftruncate.m4 (gl_FUNC_FTRUNCATE): Don't request a complaint mail
>   from mingw users.

Hi Bruno,

Now that you've done it, that's fine.  Let's hope that if it's still in
use after a few more years, someone will have added ftruncate support.

BTW, since you seem to care about mingw, can you tell us which part
of lib/ftruncate.c is used on that system?  And does the replacement
function actually work?

If we're no closer to removing the module, then we should document those
things while we're at it, since some of that code is very dusty.

Re: Printf for gnulib?

[Ben Pfaff]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> Is there any interest in a full C99 printf in gnulib?  Right now,
> there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
> The problem with these is that they punt to the system's underlying
> printf for some things.  That's an issue e.g. with Windows's %I64d
> versus %lld, and with C99 formats like %a.

I'd be very pleased to have a full C99 printf in gnulib, mainly
because I'm getting tired of not being able to write %zu to print
a size_t.
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> I'm applying this:
>
> 2007-02-19  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * lib/stdlib_.h: Use "#pragma GCC system_header" to suppress some gcc
>   warnings.
>   Reported by Joel E. Denny <[EMAIL PROTECTED]> via Paul Eggert.

Would it be possible to apply a similar fix to string_.h?  Under
mingw, I see the following warnings when compiling a file that
just contains the single line "#include ":

[EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$ i586-mingw32msvc-gcc -c 
-I. -Drestrict=  -Wmissing-prototypes include-string.c 
In file included from ./string.h:23,
 from include-string.c:1:

///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:97:
 warning: no previous prototype for 'strcasecmp'

///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:103:
 warning: no previous prototype for 'strncasecmp'
[EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$ 

Sorry about the overlong lines.
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: Printf for gnulib?

[Bruce Korb]

Ben Pfaff wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> 
>> Is there any interest in a full C99 printf in gnulib?  Right now,
>> there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
>> The problem with these is that they punt to the system's underlying
>> printf for some things.  That's an issue e.g. with Windows's %I64d
>> versus %lld, and with C99 formats like %a.
> 
> I'd be very pleased to have a full C99 printf in gnulib, mainly
> because I'm getting tired of not being able to write %zu to print
> a size_t.

Hi Gary, Paolo,

OK Guys, shall we dust this "snprintfv" thing off, polish a bit and
hand off to the interested gnulib folks?  :)  It'd be nice to have it
have first class support.   Heck, I'd like to see some of the add-on
interfaces made more widely available anyway.  :)

Cheers - Bruce

Re: check for C99-compliant snprintf

[Ben Pfaff]

Albert Chin <[EMAIL PROTECTED]> writes:

> Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
> has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
> case on some systems. And, we found that Solaris and AIX 5.1 do not
> have a C99-compliant vsnprintf(). The attached program returns -1 on
> Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
> example.

It's not hard to check at runtime whether [v]snprintf is
C99-compliant, as your example shows.  A previous version of my
proposed change did just that.  Paul Eggert requested that I try
to make it a compile- or link-time check, because the alternative
was to assume that [v]snprintf needed to be replaced if we were
cross-compiling.  I wasn't aware that these other systems have
non-compliant [v]snprintf, so I didn't check for them.

Is it better to try to enumerate non-compliant systems at
compile/link time, or to assume non-compliance when
cross-compiling?  Neither choice is ideal.  What's more likely to
be accepted into gnulib?
-- 
On Perl: "It's as if H.P. Lovecraft, returned from the dead and speaking by
seance to Larry Wall, designed a language both elegant and terrifying for his
Elder Things to write programs in, and forgot that the Shoggoths didn't turn
out quite so well in the long run." --Matt Olson

Re: Printf for gnulib?

[Gary V. Vaughan]

Hi Bruce, Paolo,

On 19 Feb 2007, at 16:53, Bruce Korb wrote:

Ben Pfaff wrote:

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:


Is there any interest in a full C99 printf in gnulib?  Right now,
there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
The problem with these is that they punt to the system's underlying
printf for some things.  That's an issue e.g. with Windows's %I64d
versus %lld, and with C99 formats like %a.


I'd be very pleased to have a full C99 printf in gnulib, mainly
because I'm getting tired of not being able to write %zu to print
a size_t.


Hi Gary, Paolo,

OK Guys, shall we dust this "snprintfv" thing off, polish a bit and
hand off to the interested gnulib folks?  :)  It'd be nice to have it
have first class support.   Heck, I'd like to see some of the add-on
interfaces made more widely available anyway.  :)


That sounds like a splendid idea!  I'll even have some time to spend
on it starting next month.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part

Re: check for C99-compliant snprintf

[Albert Chin]

On Mon, Feb 19, 2007 at 03:53:10PM -0800, Ben Pfaff wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> 
> > Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
> > has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
> > case on some systems. And, we found that Solaris and AIX 5.1 do not
> > have a C99-compliant vsnprintf(). The attached program returns -1 on
> > Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
> > example.
> 
> It's not hard to check at runtime whether [v]snprintf is
> C99-compliant, as your example shows.  A previous version of my
> proposed change did just that.  Paul Eggert requested that I try
> to make it a compile- or link-time check, because the alternative
> was to assume that [v]snprintf needed to be replaced if we were
> cross-compiling.  I wasn't aware that these other systems have
> non-compliant [v]snprintf, so I didn't check for them.
> 
> Is it better to try to enumerate non-compliant systems at
> compile/link time, or to assume non-compliance when
> cross-compiling?  Neither choice is ideal.  What's more likely to
> be accepted into gnulib?

How about assuming compliance when cross-compliance but enumerate,
when cross-compiling, the systems that fail? When not cross-compiling,
let's perform the compile-time check.

-- 
albert chin ([EMAIL PROTECTED])

Re: SKIP_FTRUNCATE_CHECK

[Bruno Haible]

Hi Jim,

> Now that you've done it, that's fine.

OK, I'm committing it now, after you are saying that it's fine.

> BTW, since you seem to care about mingw, can you tell us which part
> of lib/ftruncate.c is used on that system?

It uses a call to 'chsize'. 'chsize' is a documented function of the Windows
runtime library (MSVCRT).

> And does the replacement function actually work?

This, I can't tell, as I'm only cross-compiling. I can't do more than "nm"
on the object files.

> If we're no closer to removing the module, then we should document those
> things while we're at it, since some of that code is very dusty.

Like this? There's also some background about the other two alternatives at
http://www.unixguide.net/unix/faq/3.3.shtml .


--- lib/ftruncate.c 19 Feb 2007 02:24:42 -  1.12
+++ lib/ftruncate.c 19 Feb 2007 23:56:54 -
@@ -66,7 +66,7 @@
 }
 
 # else /* not F_CHSIZE nor F_FREESP */
-#  if HAVE_CHSIZE
+#  if HAVE_CHSIZE  /* native Windows, e.g. mingw */
 
 int
 ftruncate (int fd, off_t length)

Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored

[Bruno Haible]

Ben Pfaff wrote:

> Would it be possible to apply a similar fix to string_.h?  Under
> mingw, I see the following warnings when compiling a file that
> just contains the single line "#include ":
> 
> [EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$ i586-mingw32msvc-gcc -c 
> -I. -Drestrict=  -Wmissing-prototypes include-string.c 
> In file included from ./string.h:23,
>  from include-string.c:1:
> 
> ///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:97:
>  warning: no previous prototype for 'strcasecmp'
> 
> ///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:103:
>  warning: no previous prototype for 'strncasecmp'
> [EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$ 

Ok, I'm applying this.

2007-02-19  Bruno Haible  <[EMAIL PROTECTED]>

* lib/string_.h: Use "#pragma GCC system_header" to suppress some gcc
warnings.
Reported by Ben Pfaff <[EMAIL PROTECTED]>.

*** lib/string_.h   17 Feb 2007 22:21:32 -  1.26
--- lib/string_.h   20 Feb 2007 00:09:04 -
***
*** 19,24 
--- 19,30 
  #ifndef _GL_STRING_H
  #define _GL_STRING_H
  
+ /* This #pragma avoids a warning with "gcc -Wmissing-prototypes" on some
+mingw systems.  */
+ #ifdef __GNUC__
+ # pragma GCC system_header
+ #endif
+ 
  #include @ABSOLUTE_STRING_H@
  
  

Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored

[Bruno Haible]

Paul Eggert wrote:
> Following up on today's bug-bison message
> .
> 
> This seems to be due to the new stdlib module in gnulib.  stdlib uses
> the new trick of something like this:
> 
>   #include "///usr/include/stdlib.h"
>   ... gnulib fixups go here ...
> 
> But Bison has exposed a problem with this approach.  The approach
> causes GCC to treat /usr/include/stdlib.h as if it were not a system
> include header, which in turn causes GCC to issue diagnostics that it
> would not otherwise generate (since GCC is more tolerant of problems
> inside system include headers).  In this particular case, GCC
> complains about the following line in /usr/include/stdlib.h, which is
> probably bogus with GCC 4.1.1 (the __malloc__ attribute isn't
> documented, so I'm not sure):
> 
>  extern int posix_memalign (void **__memptr, size_t __alignment, size_t 
> __size)
>  __THROW __attribute_malloc__;

Yes. This declaration is bogus with the current gccs, since the return type
is not a pointer type. This was fixed in glibc on 2005-07-15, but glibcs
older than this are still much in use.

> A simple fix would be for gnulib stdlib.h to include the system
> stdlib.h this way:
> 
>   #if HAVE_INCLUDE_NEXT
>   # include_next 
>   #else
>   # include "///usr/include/stdlib.h"
>   #endif
>   ... gnulib fixups go here ...
> 
> I worry a bit that this would not work in some non-GCC compilers; they
> would complain about the include_next even though they're not
> executing it.  But perhaps we can cross this bridge when we come
> to it (if we ever do).
> 
> Another possibility would be to change the Makefile so that it
> replaces "#include @ABSOLUTE_STDLIB_H@" with "#include_next
> " on GCC platforms.  This will work with ordinary
> compilations, but as I understand it Bruno wants to be able to
> generate .h files that can be included by arbitrary compilers.
> 
> Another, even trickier possibility, would be to fiddle with #pragma
> GCC system_header, but I'd rather avoid that if I can.

Thanks for both suggestions. They both work. For a gcc specific problem,
I think it's ok to use a gcc specific workaround. Since the gcc doc
says the following about #include_next:

  The use of `#include_next' can lead to great confusion.  We
   recommend it be used only when there is no other alternative.  In
   particular, it should not be used in the headers belonging to a specific
   program; it should be used only to make global corrections along the
   lines of `fixincludes'.

but there's no obvious drawback of the #pragma approach, I'm applying this:


2007-02-19  Bruno Haible  <[EMAIL PROTECTED]>

* lib/stdlib_.h: Use "#pragma GCC system_header" to suppress some gcc
warnings.
Reported by Joel E. Denny <[EMAIL PROTECTED]> via Paul Eggert.

*** lib/stdlib_.h   19 Feb 2007 00:08:40 -  1.3
--- lib/stdlib_.h   19 Feb 2007 22:51:33 -  1.4
***
*** 18,29 
--- 18,45 
  
  #if defined __need_malloc_and_calloc
  /* Special invocation convention inside glibc header files.  */
+ 
+ /* This #pragma avoids a warning with "gcc -Wall" on some glibc systems
+on which  has an inappropriate declaration, see
+.  */
+ #ifdef __GNUC__
+ # pragma GCC system_header
+ #endif
+ 
  #include @ABSOLUTE_STDLIB_H@
+ 
  #else
  /* Normal invocation convention.  */
  #ifndef _GL_STDLIB_H
  #define _GL_STDLIB_H
  
+ /* This #pragma avoids a warning with "gcc -Wall" on some glibc systems
+on which  has an inappropriate declaration, see
+.  */
+ #ifdef __GNUC__
+ # pragma GCC system_header
+ #endif
+ 
  #include @ABSOLUTE_STDLIB_H@
  
  

Re: check for C99-compliant snprintf

[Ben Pfaff]

Albert Chin <[EMAIL PROTECTED]> writes:

> On Mon, Feb 19, 2007 at 03:53:10PM -0800, Ben Pfaff wrote:
>> Albert Chin <[EMAIL PROTECTED]> writes:
>> 
>> > Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
>> > has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
>> > case on some systems. And, we found that Solaris and AIX 5.1 do not
>> > have a C99-compliant vsnprintf(). The attached program returns -1 on
>> > Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
>> > example.
>> 
>> It's not hard to check at runtime whether [v]snprintf is
>> C99-compliant, as your example shows.  A previous version of my
>> proposed change did just that.  Paul Eggert requested that I try
>> to make it a compile- or link-time check, because the alternative
>> was to assume that [v]snprintf needed to be replaced if we were
>> cross-compiling.  I wasn't aware that these other systems have
>> non-compliant [v]snprintf, so I didn't check for them.
>> 
>> Is it better to try to enumerate non-compliant systems at
>> compile/link time, or to assume non-compliance when
>> cross-compiling?  Neither choice is ideal.  What's more likely to
>> be accepted into gnulib?
>
> How about assuming compliance when cross-compliance but enumerate,
> when cross-compiling, the systems that fail? When not cross-compiling,
> let's perform the compile-time check.

I'm willing to fix my proposed change so that it does this.

It appears, based on online documentation, that snprintf is C99
compliant in AIX 5.2 and above.  Is that correct?  If so, then
will the following successfully detect the systems with broken
snprintf: 
#if defined _AIX && !defined _AIX52
/* broken */
#endif

How do you test for Solaris 6 through 9?  The list at
predef.sf.net is not very helpful on this, because it doesn't
give any hint how to test for a range of Solaris versions, only
for particular versions.
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: progreloc.c - what module?

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Ben Pfaff wrote:
>> The file lib/progreloc.c is not in any module (as far as I can
>> tell).
>
> Yes [1]. This "relocatable" stuff is in a temporary state. Ideally it should
> be integrated into autoconf and automake. Do you have time to work on that
> with me?

Yes, I have a little bit of time.  It looks like you've done most
of the work already.  It seems that what is left is:

- Prepare a gnulib module that encapsulates the lib and
  m4 files that are needed and makes the proper Autoconf
  calls.

- Adding support to Automake to avoid the need to add or
  modify rules for relocatability.

Does that look accurate?  I'm willing to work on this, as it
should be useful to me.
-- 
"In this world that Hugh Heffner had made,
 he alone seemed forever bunnyless."
--John D. MacDonald

Re: check for C99-compliant snprintf

[Eric Blake]

> > Is it better to try to enumerate non-compliant systems at
> > compile/link time, or to assume non-compliance when
> > cross-compiling?  Neither choice is ideal.  What's more likely to
> > be accepted into gnulib?
> 
> How about assuming compliance when cross-compliance but enumerate,
> when cross-compiling, the systems that fail? When not cross-compiling,
> let's perform the compile-time check.

I would rather see the following: when not cross-compiling (or even
when cross-compiling, but the cross-executable can be run), use a
configure-time run check to decide up front whether the gnulib module
should even be used.  When cross-compiling, assume that the
gnulib module is required (but of course, this can be overridden
by presetting the appropriate cache variable to configure).  At
runtime, the gnulib module then performs a sanity check on first
usage; if it passes, then configure was pessimistic, and all further
*printf calls defer to the system (the cost is a slightly slower, slightly
larger executable); if it fails, then use the gnulib implementation.
That way, we can guarantee C99 semantics for all users,
regardless of whether cross-compiling was unable to detect
brokenness.

-- 
Eric Blake

snprintfv (was: Re: Printf for gnulib?)

[Bruno Haible]

Hi Gary,

> > OK Guys, shall we dust this "snprintfv" thing off, polish a bit and
> > hand off to the interested gnulib folks?  :)  It'd be nice to have it
> > have first class support.   Heck, I'd like to see some of the add-on
> > interfaces made more widely available anyway.  :)
> 
> That sounds like a splendid idea!  I'll even have some time to spend
> on it starting next month.

This would be welcome. The presence in gnulib offers for your library:
  - a tool for integration into other packages ("gnulib-tool --import 
snprintfv")
and for standalone testing ("gnulib-tool --create-testdir snprintfv"),
  - some people who proofread the code and do nitpicking, (*)
  - more visibility; possibly other library codes will rely on it.

Now that gnulib supports subdirectories, you can even have all sources remain
in a lib/snprintfv/ directory.

snprintfv also has an interesting abstraction of "stream". This resembles
the output streams that I've been using in GNU gettext lately. (And it's a
pain to do this in C, rather than the ever-more-ugly C++.):
  ostream   
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  fd-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/fd-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  file-ostream  
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/file-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  memory-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/memory-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  term-ostream  
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/term-ostream.oo.h?content-type=text%2Fplain&rev=1.2&root=gettext
  iconv-ostream 
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/iconv-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  html-ostream  
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/html-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
  
But I think the *printf replacements should continue to be based on the
vasnprintf code, because of object code size. On a Linux/x86 system:

  $ size vasnprintf.o
 textdata bss dec hex filename
 6669   0   066691a0d vasnprintf.o
  $ ld -r -o snprintfv.o libsnprintfvc_la-*.o
  $ size snprintfv.o
 textdata bss dec hex filename
179841020 416   194204bdc snprintfv.o

Not everyone want to spend 18 KB of object code in a facility that "nearly"
is contained in the standard libc. regex.o being even bigger is not much of
a justification because only ca. 20% of the programs need regex, whereas
100% need printf.

  $ size regex.o   [this one is compiled with -fPIC]
 textdata bss dec hex filename
620795964   0   68043   109cb regex.o

Bruno


(*) The snprintfv in smalltalk-2.3.2 has this compiler warning which really
looks like a bug:
printf.c: In function `stream_printfv':
printf.c:658: warning: assignment makes pointer from integer without a cast

Re: progreloc.c - what module?

[Bruno Haible]

Ben Pfaff wrote:
> It seems that what is left is:
> 
> - Prepare a gnulib module that encapsulates the lib and
>   m4 files that are needed and makes the proper Autoconf
>   calls.
> 
> - Adding support to Automake to avoid the need to add or
>   modify rules for relocatability.
> 
> Does that look accurate?

Yes, that's it essentially. When you look at
  http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html
you see that the points
  - config.libpath, reloc-ldflags, install-reloc,
  - lib/ sources,
  - lib/Makefile.am,
  - m4/ macros,
  - m4/Makefile.am,
  - configure.ac
can all be accomodated into a gnulib module. The section "Your sources"
should probably be documented in a .texi file, and the section
"Your Makefile.am" is automake work.

The best starting point is probably the gettext-runtime/src/Makefile.am in
the gettext CVS, together with a fresh GNU hello for making experiments.

> I'm willing to work on this, as it should be useful to me.

Wonderful!!

Bruno

Re: snprintfv

[Bruce Korb]

Bruno Haible wrote:
> This would be welcome. The presence in gnulib offers for your library:
>   - a tool for integration into other packages ("gnulib-tool --import 
> snprintfv")
> and for standalone testing ("gnulib-tool --create-testdir snprintfv"),
>   - some people who proofread the code and do nitpicking, (*)
>   - more visibility; possibly other library codes will rely on it.

That's what I was thinking, too.

> But I think the *printf replacements should continue to be based on the
> vasnprintf code, because of object code size. On a Linux/x86 system:

With typical new systems using 1GB ram and 150GB disk,
we're talking 1/10 of the RAM and less than ten millionths
of one percent of disk space.  Just for a work station.  Convenience
is more important, but pushing on the issue isn't worth it either.

> Not everyone want to spend 18 KB of object code in a facility that "nearly"
> is contained in the standard libc. regex.o being even bigger is not much of
> a justification because only ca. 20% of the programs need regex, whereas
> 100% need printf.

I'm sure some people care.  I used to.  I surely don't any more.

==

An amusing adjunct project for gnulib would be a gnulib wrapper.
It figures out what backfills are needed for a particular platform,
and constructs a header file and shared library.  Very similar to
a proposal I wrote for an autotool bake-off contest some half dozen
years ago.  Only with the gnulib project available now, there'd
be little work left to do   :-D

With that, a project merely has to test for the existence of the
backfill library and bypass 99.99% of the configure script.  Whew!!

Not today tho.  Just an amusing thought.

Cheers - Bruce

Re: Printf for gnulib?

[Bruno Haible]

Daniel Jacobowitz and Ben Pfaff wrote:
> > Is there any interest in a full C99 printf in gnulib?  Right now,
> > there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
> > The problem with these is that they punt to the system's underlying
> > printf for some things.  That's an issue e.g. with Windows's %I64d
> > versus %lld, and with C99 formats like %a.
> 
> I'd be very pleased to have a full C99 printf in gnulib, mainly
> because I'm getting tired of not being able to write %zu to print
> a size_t.

A full C99 printf is not enough for internationalized programs, since it
doesn't support argument reordering through the "%m$" syntax. Therefore I'm
in favour of targetting directly POSIX:2001 (it's a superset of C99 printf).

Am I understanding it right, that for POSIX support, compared to what all
systems already provide, we need:
  1) support for "ll", "z", ... size flags,  [mingw]
  2) support for "%m$" reordering,   [mingw, NetBSD, older cygwin]
  3) support of "%n",[HP-UX]
  4) support for "a", "A" conversion,[?]
  5) correct return value of snprintf[HP-UX at least]
?

The goal of the gnulib *printf modules, so far, has been to provide the
particular function if it is missing. vasnprintf already does part of the
POSIX functionality because, historically, I borrowed the implementation
from GNU gettext, which had 1), 2), and 3) already implemented.

I agree that gnulib should offer POSIX compliant *printf functions. However,
since just having the function _at_all_, without requiring full POSIX,
has been good enough for many packages, and vasnprintf.c is a big chunk of
code that many people probably don't want to see added to every executable
unless absolutely necessary, I would like that gnulib proposes two offers:

  (A) The "minimal" offer: just ensure that the function exists.
  Modules: snprintf, vsnprintf,
   asprintf, vasprintf.

  (B) Full POSIX offer: override the system functions if they are not POSIX
  compliant.
  Modules: snprintf-posix, vsnprintf-posix,
   sprintf-posix, vsprintf-posix,
   fprintf-posix, vfprintf-posix,
   printf-posix, vprintf-posix,
   asprintf-posix, vasprintf-posix.

This dual offer is similar to what we do with "fnmatch-posix" and
"fnmatch-gnu".

I include [v]asprintf in this list, because although it's not a POSIX function,
NetBSD has asprintf but it does not support POSIX format strings ( 2) missing).

With this offer, everyone should be served, I think?

Bruno

Re: Printf for gnulib?

[Daniel Jacobowitz]

On Mon, Feb 19, 2007 at 04:59:02PM -0700, Gary V. Vaughan wrote:
> That sounds like a splendid idea!  I'll even have some time to spend
> on it starting next month.

I have some motivation to work on this, though no urgency.  Especially
if there's already code available to start from (it's already FSF
assigned, right?).  Want to give me a pointer, or would you rather do
it yourself?

-- 
Daniel Jacobowitz
CodeSourcery

Re: snprintfv for gnulib?

[Bruce Korb]

Daniel Jacobowitz wrote:
> On Mon, Feb 19, 2007 at 04:59:02PM -0700, Gary V. Vaughan wrote:
>> That sounds like a splendid idea!  I'll even have some time to spend
>> on it starting next month.
> 
> I have some motivation to work on this, though no urgency.  Especially
> if there's already code available to start from (it's already FSF
> assigned, right?).  Want to give me a pointer, or would you rather do
> it yourself?

Hi Daniel,

We all have day jobs and any time we don't have to spend on one
thing becomes available for something else.  You are very welcome
to help provide the massaging necessary to make libsnprintfv
play nice with gnulib:

https://savannah.nongnu.org/projects/libsnprintfv/
Also, btw:
https://savannah.gnu.org/projects/autogen
has another copy of the stuff.  It likely needs some
reconciling.

I don't think Gary has assigned rights to FSF though.
Still he knows it is necessary, so I doubt it is an
issue at all.  He has assigned rights to his labors
on several other projects.

Cheers - Bruce

Re: check for C99-compliant snprintf

[Bruno Haible]

Ben Pfaff wrote on Friday/Saturday:
> The following patch attempts to remedy the situation.

I cannot see the big picture in this change. You want a snprintf() whose
return value is correct but which still doesn't support argument reordering
on NetBSD and doesn't support %n on HP-UX? And an unchanged printf() and
fprintf()? Please see the other mail ("Printf for gnulib") for a proposal
how to get it all right.

> I traced it to the following in libintl.h:
> #undef snprintf
> #define snprintf libintl_snprintf
> where libintl_snprintf is a wrapper around the system snprintf,
> which is still of course broken.  I'm not sure how to work around
> this problem.

Don't worry about it yet. We can get it fixed afterwards.

> vsnprintf is problematic even with --disable-nls, because mingw
>  contains:
> __CRT_INLINE int __cdecl
> vsnprintf (char* s, size_t n, const char* format, __VALIST arg)
>   { return _vsnprintf ( s, n, format, arg); }
> When vsnprintf expands to rpl_vsnprintf, this turns rpl_vsnprintf
> into a wrapper around the broken _vsnprintf.

The usual way to work around such redefines in header files is to
write an  substitute which #includes the original 
and _then_ does
  #define vsnprintf rpl_vsnprintf

This way, you don't even need to know about _vsnprintf.

Bruno

Re: snprintfv for gnulib?

[Gary V. Vaughan]

On 19 Feb 2007, at 20:29, Bruce Korb wrote:

Daniel Jacobowitz wrote:

On Mon, Feb 19, 2007 at 04:59:02PM -0700, Gary V. Vaughan wrote:

That sounds like a splendid idea!  I'll even have some time to spend
on it starting next month.


I have some motivation to work on this, though no urgency.   
Especially

if there's already code available to start from (it's already FSF
assigned, right?).  Want to give me a pointer, or would you rather do
it yourself?


We all have day jobs and any time we don't have to spend on one
thing becomes available for something else.  You are very welcome
to help provide the massaging necessary to make libsnprintfv
play nice with gnulib:

https://savannah.nongnu.org/projects/libsnprintfv/
Also, btw:
https://savannah.gnu.org/projects/autogen
has another copy of the stuff.  It likely needs some
reconciling.


Yes it does.  I'm not sure which is which now either.  I remember that
I did much of the work on a v2 release, and Paolo did something very
similar but we each did the work independently of the other.  There is
some reconciling to be done there too.

I have my very latest (i.e. 3 years old) version on disk here if anyone
would like a copy to cherrypick...


I don't think Gary has assigned rights to FSF though.
Still he knows it is necessary, so I doubt it is an
issue at all.  He has assigned rights to his labors
on several other projects.


I assigned copyright when I released the work into Autogen, and have
the papers at home somewhere.  It should be listed in the relevant
files on fencepost too.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part

Re: Printf for gnulib?

[Bruce Korb]

Bruno Haible wrote:

> I agree that gnulib should offer POSIX compliant *printf functions. However,
> since just having the function _at_all_, without requiring full POSIX,
> has been good enough for many packages, and vasnprintf.c is a big chunk of
> code that many people probably don't want to see added to every executable
> unless absolutely necessary, I would like that gnulib proposes two offers:
> 
>   (A) The "minimal" offer: just ensure that the function exists.
>   Modules: snprintf, vsnprintf,
>asprintf, vasprintf.
> 
>   (B) Full POSIX offer: override the system functions if they are not POSIX
>   compliant.
>   Modules: snprintf-posix, vsnprintf-posix,
>sprintf-posix, vsprintf-posix,
>fprintf-posix, vfprintf-posix,
>printf-posix, vprintf-posix,
>asprintf-posix, vasprintf-posix.
> 
> This dual offer is similar to what we do with "fnmatch-posix" and
> "fnmatch-gnu".
> 
> I include [v]asprintf in this list, because although it's not a POSIX 
> function,
> NetBSD has asprintf but it does not support POSIX format strings ( 2) 
> missing).
> 
> With this offer, everyone should be served, I think?

libsnprintfv has argument ordering also.  It really has absolutely everything.
If you can define a good way of expressing, "these are the features I need
from the *printf* functions", then you can use that information to determine
if the native implementation covers it.  It all sounds pretty messy to me.
Especially since it is hard to remember what printf features I use in my code.
Now maybe I'm not using "%zd" in my code, but if I add it tomorrow, just
how in heck am I to remember to fix up my configure testing?  It ain't worth
the "savings".

For my own purposes, I find it easier to not worry over whether or not the
native functionality is sufficient.  Then again, I don't care a whit about
code size.  :)

Whatever.  Cheers - Bruce

Re: snprintfv

[Bruno Haible]

Bruce Korb wrote:
> > But I think the *printf replacements should continue to be based on the
> > vasnprintf code, because of object code size. On a Linux/x86 system:
> 
> With typical new systems using 1GB ram and 150GB disk,
> we're talking 1/10 of the RAM and less than ten millionths
> of one percent of disk space.

And how much of the L1 instruction cache? Intel's Pentium, Pentium Pro,
Pentium III, Celeron 1.7 GHz each have only 8 KB of it. Make one call to
snprintfv, and the cache is emptied. AMD64 has 64 KB of it; it's a bit better.

Bruno

Re: check for C99-compliant snprintf

[Albert Chin]

On Mon, Feb 19, 2007 at 04:47:47PM -0800, Ben Pfaff wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Feb 19, 2007 at 03:53:10PM -0800, Ben Pfaff wrote:
> >> Albert Chin <[EMAIL PROTECTED]> writes:
> >> 
> >> > Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
> >> > has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
> >> > case on some systems. And, we found that Solaris and AIX 5.1 do not
> >> > have a C99-compliant vsnprintf(). The attached program returns -1 on
> >> > Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
> >> > example.
> >> 
> >> It's not hard to check at runtime whether [v]snprintf is
> >> C99-compliant, as your example shows.  A previous version of my
> >> proposed change did just that.  Paul Eggert requested that I try
> >> to make it a compile- or link-time check, because the alternative
> >> was to assume that [v]snprintf needed to be replaced if we were
> >> cross-compiling.  I wasn't aware that these other systems have
> >> non-compliant [v]snprintf, so I didn't check for them.
> >> 
> >> Is it better to try to enumerate non-compliant systems at
> >> compile/link time, or to assume non-compliance when
> >> cross-compiling?  Neither choice is ideal.  What's more likely to
> >> be accepted into gnulib?
> >
> > How about assuming compliance when cross-compliance but enumerate,
> > when cross-compiling, the systems that fail? When not cross-compiling,
> > let's perform the compile-time check.
> 
> I'm willing to fix my proposed change so that it does this.
> 
> It appears, based on online documentation, that snprintf is C99
> compliant in AIX 5.2 and above.  Is that correct?

Correct.

> If so, then will the following successfully detect the systems with
> broken snprintf: 
> #if defined _AIX && !defined _AIX52
> /* broken */
> #endif
> 
> How do you test for Solaris 6 through 9?  The list at
> predef.sf.net is not very helpful on this, because it doesn't
> give any hint how to test for a range of Solaris versions, only
> for particular versions.

I doubt anyone is cross-compiling on Solaris or AIX so I just wouldn't
worry about the cross-compiler case for them.

-- 
albert chin ([EMAIL PROTECTED])

Re: check for C99-compliant snprintf

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Ben Pfaff wrote on Friday/Saturday:
>> The following patch attempts to remedy the situation.
>
> I cannot see the big picture in this change. You want a snprintf() whose
> return value is correct but which still doesn't support argument reordering
> on NetBSD and doesn't support %n on HP-UX? And an unchanged printf() and
> fprintf()? 

I want a [v]snprintf that always null-terminates its output
string (if the size argument is greater than zero), so that I can
safely call [v]snprintf, then treat the result as a
null-terminated string without having to check the return value
at all.  The pre-C99 [v]snprintfs don't necessarily do this, and
in particular Microsoft documents its _[v]snprintf to *not*
null-terminate if the output is too long.

> Please see the other mail ("Printf for gnulib") for a proposal
> how to get it all right.

Since there's momentum to fix all these problems at the same
time, I'll withdraw my proposal for a module, and work around the
problem for now.
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: snprintfv for gnulib?

[Paolo Bonzini]

Yes it does.  I'm not sure which is which now either.  I remember that
I did much of the work on a v2 release, and Paolo did something very
similar but we each did the work independently of the other.  There is
some reconciling to be done there too.


My copy is in ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.3.3.tar.gz

AFAIK, I have all the bugfixes from Gary and Bruce's stuff there.

Paolo

Re: snprintfv

[Paolo Bonzini]

And how much of the L1 instruction cache? Intel's Pentium, Pentium Pro,
Pentium III, Celeron 1.7 GHz each have only 8 KB of it. Make one call to
snprintfv, and the cache is emptied. AMD64 has 64 KB of it; it's a bit better.


Let's talk L2 cache.  I doubt glibc has a smaller printf, and anyway I 
won't hope my L1 cache to contain much more than the program's currently 
running hot loop.


Paolo

Re: snprintfv for gnulib?

[Gary V. Vaughan]

On 19 Feb 2007, at 23:17, Paolo Bonzini wrote:
Yes it does.  I'm not sure which is which now either.  I remember  
that

I did much of the work on a v2 release, and Paolo did something very
similar but we each did the work independently of the other.   
There is

some reconciling to be done there too.


My copy is in ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.3.3.tar.gz

AFAIK, I have all the bugfixes from Gary and Bruce's stuff there.


Then we should probably take that one as the basis for submission to  
gnulib,

unless there is a consensus that Bruce's version is preferable for some
reason.  Either way, having a single flavour maintained outside of both
smalltalk, autogen (and m4 eventually) is a big win all round.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part