progreloc.c - what module?

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 <[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. --

Re: SKIP_FTRUNCATE_CHECK

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"

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

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 Biso

Re: question about getcwd

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

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/ge

Re: question about getcwd

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

Re: question about getcwd

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

Re: progreloc.c - what module?

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/ht

Printf for gnulib?

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 tha

Re: progreloc.c - what module?

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 ti

Re: Printf for gnulib?

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 xvaspr

Re: SKIP_FTRUNCATE_CHECK

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-

Re: check for C99-compliant snprintf

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 @

Re: SKIP_FTRUNCATE_CHECK

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 a

Re: Printf for gnulib?

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

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

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 poss

Re: Printf for gnulib?

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 t

Re: check for C99-compliant snprintf

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

Re: Printf for gnulib?

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

Re: check for C99-compliant snprintf

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 Solari

Re: SKIP_FTRUNCATE_CHECK

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

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

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= -

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

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" > ...

Re: check for C99-compliant snprintf

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 >> >

Re: progreloc.c - what module?

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 > wi

Re: check for C99-compliant snprintf

> > 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 cro

snprintfv (was: Re: Printf for gnulib?)

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

Re: progreloc.c - what module?

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

Re: snprintfv

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 a

Re: Printf for gnulib?

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

Re: Printf for gnulib?

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

Re: snprintfv for gnulib?

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 ava

Re: check for C99-compliant snprintf

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 unchang

Re: snprintfv for gnulib?

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. E

Re: Printf for gnulib?

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 se

Re: snprintfv

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 on

Re: check for C99-compliant snprintf

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 > >> >

Re: check for C99-compliant snprintf

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 Ne

Re: snprintfv for gnulib?

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/smalltal

Re: snprintfv

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

Re: snprintfv for gnulib?

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