Re: patch for gettext.m4 for better included intl support

Title: Re: patch for gettext.m4 for better included intl support Hello Claudio, Sorry for not answering earlier: on 2006-01-06 I felt that I had to think a bit more about the possible drawbacks of your proposed patch. > assuming full autotools and gnulib support, > lib/, and lib/Makefile.am

Re: module 'fts-lgpl' not complete

Jim Meyering wrote: > One difference is the use of ENOTDIR rather than EINVAL, > since that what lstat does for names like "non-dir/.". You're right. Thanks. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/b

Re: [bug-gnulib] PATCH to stdint_.h for OpenBSD Sparc64

s _not_ define intptr_t and uintptr_t in ; you need also for these two typedefs. I am therefore committing the appended patch. Does it work for you? Bruno 2006-03-29 Mark D. Baushke <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> * stdint_.h: On OpenBSD, d

prepare for autoconf-2.60

Hi, It appears that autoconf-2.60 may be released soon. I added comments to longdouble.m4 and onceonly.m4 relating to the new macros in autoconf-2.59d. I also propose a similar comment to extensions.m4, see below. Bruno diff -c -3 -r1.5 longdouble.m4 *** longdouble.m4 18 Jan 2005 13:07:56

Re: prepare for autoconf-2.60

Paul Eggert wrote: > > + But about AC_CHECK_DECLS_ONCE: note that in > > + autoconf >= 2.60 the symbol separator is a comma, whereas here it is > > + whitespace. > > I hadn't noticed this incompatibility. It is a real hassle. The comma separator in autoconf's AC_CHECK_DECLS is a hassle, because i

Re: [bug-gnulib] gnulib-tool basics

Karl Berry wrote: > First, regarding gnulib-tool --help. > > --update isn't mentioned under "Operation modes:", although it is one > of the usages. I'm adding this doc: --update update the current package, restore files omitted from CVS > I suggest

Re: [bug-gnulib] libopts and gnulib?

Karl Berry wrote on 2006-02-13: > Bruce Korb implemented a library for straightforward config file > parsing (among other things). We thought it would make sense to use it > for GNU Hello, as an example of how it can be done. How come so few programs use this libopts? Let me look at the syntax of

Re: [bug-gnulib] Re: warning in AC_CHECK_DECL

Paul Eggert wrote on 2006-02-17: > > Either we need to update the various gnulib macros > > borrowed from CVS autoconf to override bugs in autoconf 2.59, or we need > > to release autoconf 2.60. > > We should do both, since we can't assume 2.60 will be adopted right > away. What changes need to

Re: [bug-gnulib] Re: translations

Sergey Poznyakoff wrote on 2006-02-25: > They should all go through TP, certainly. Apart from the reasons, listed > by Jim, there are two more: > > - TP checks that the translator fills assignment papers, which is > especially important for GNU programs. > - Other translators from the submitter'

Re: [bug-gnulib] Re: translations

Paul Eggert wrote on 2006-02-26: > While we're on the subject, is the translation project on hiatus right > now? They haven't updated the Bison .pot file even though I sent them > email thirteen days ago about the Bison 2.1a version (a version > generated principally in order to get translations),

Re: [bug-gnulib] fwriteerror() interface

ream. True. I probably missed that because in my uses of fwriteerror(), I use error (EXIT_FAILURE ...) in case of failure, and the state of the stream doesn't matter in this case. Thanks! 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * fwriteerror.c (fwriteerror): Call fclose

Re: [bug-gnulib] poll.h replacement

Ralf Wildenhues wrote on 2006-03-03: > On powerpc-ibm-aix5.3.0.0, poll is not deemed acceptable: the test in > m4/poll.m4 fails because polling on /dev/null does not work. It does > work to poll on regular files, though. Polling on /dev/tty does not > work either. Thanks for the report. I'm chan

Re: [bug-gnulib] poll.h replacement

n AIX.) With your patch in, the variable POLL_H is modified 37 lines after it has already been AC_SUBSTed. To keep the macro maintainable, I rearrange it a bit. Bruno 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * poll.m4 (gl_FUNC_POLL): Rearrange code, so that POLL_H gets

Re: [bug-gnulib] support for AM_CPPFLAGS

Claudio Fontana wrote on 2006-03-04: > while trying to improve current support in gnulib for internal gettext, > I produced this patch, which I use successfully in the packages I > maintain to support per-package additions to AM_CPPFLAGS. > > The patch is a unified p1 diff. > I suggest this for in

Re: [bug-gnulib] more unistd improvements

plying the same change to all modules borrowed from gettext, except 'setenv' (which is also used for the "relocatable" facility and therefore cannot assume the full gnulib infrastructure). Bruno 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * copy-file.c:

Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module

Paul Eggert wrote on 2006-03-10: > I recently redisovered the fact that asctime_r and ctime_r, like > asctime and ctime, are unsafe functions in the same sense that gets is > unsafe: they can overrun their output buffers and there's no simple > way for the user to detect in advance whether this wil

Re: [bug-gnulib] What happened to latest versions of GNU Patch?

Antonio Diaz Diaz wrote on 2006-03-16: > By the way. Just now I have found the file patch-2.5.9.tar.gz (date > 1-Jun-2004) in the directory ftp://alpha.gnu.org/gnu/diffutils/ after > spending more than ten hours patching and cleaning patch-2.5.4 (the > latest stable release). :-( When looking f

new module: iconvstring

ADD += $(LTLIBICONV) Include: "iconvstring.h" License: GPL Maintainer: Bruno Haible = lib/iconvstring.h === /* Charset conversion. Copyright (C) 2001-2003, 2006 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL

Re: [bug-gnulib] badly sorted #include directives

x, that additionally will sort all the #include <...> before all the #include "..." (as is common gnulib style). Bruno 2006-04-25 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_import): Output the include directives in three blocks, sorted separ

Re: [bug-gnulib] deprecated functions

Paul Eggert wrote: > The next POSIX will allow the current Solaris behavior, along with > worse behaviors, so I think it's better if we wash our hands of these > functions entirely. asctime and ctime are only historical curiosities > now, and asctime_r and ctime_r are well-intentioned mistakes. O

Re: [bug-gnulib] wait-process module

Derek, > Since there have been no new objections raised to the patch proposed in > this thread > for > well-nigh a year, now, I've installed the change. This is not an acceptable way of working together. The 'wait-process' modul

Re: [bug-gnulib] deprecated functions

Paul Eggert wrote: > But glibc asctime does not have the problem, since it never has > undefined behavior. The glibc manual isn't really intended to be a > manual for porting code to non-glibc systems OK, then the Linux manual pages are not the right place either. > Perhaps we could add a portab

Re: [bug-gnulib] Re: bootstrap script failing due to gettext AM_CPPFLAGS change

Paul Eggert wrote: > 2006-04-25 Paul Eggert <[EMAIL PROTECTED]> > > * bootstrap: Comment out the AM_CPPFLAGS line, since we don't use > that variable and the line breaks the bootstrap. Problem reported > by Juan M. Guerrero. Another fix would be to define AM_CPPFLAGS to empty

Re: [bug-gnulib] Re: bootstrap script failing due to gettext AM_CPPFLAGS change

Paul Eggert wrote: > As I understand it, the long-term goal is to eliminate the -I../intl > approach entirely, since it had problems and core utilities don't use > it any more. "gettextize --intl" is not recommended any more for a few years, but there are no plans to remove it. > I'd prefer it if

Re: [bug-gnulib] wait-process module

Derek, > I apologize for the misunderstanding. You hadn't replied to new points > raised by three different people Noone raised an important change request regarding the wait-process module in a year. > and in general the process on GNULIB > has seemed to me to be that no response meant approva

Re: [bug-gnulib] using gnulib on non posix/gnu systems

Juan Manuel Guerrero wrote: > I have used the getopt.[ch] files to port certain posix/gnu stuff > to DJGPP/MSDOS. The compilation of getopt.c fails because in the > design of this file it is assumed that NLS support is available either > through the system libc library or through ported versions of

Re: [bug-gnulib] localtime_r thread-safe?

nulib provides a replacement that has the right prototype but is not thread-safe. The alternative is to use the time() function and convert to local time yourself. Paul, what about the following patch to make our replacement functions MT-safe? 2006-04-27 Bruno Haible <[EMAIL PROTEC

Re: size_max: remove it?

Simon Josefsson wrote: > There is size_max, which does: > > # include This is needed to avoid a "macro redefined" warning e.g. on Solaris 7. > # if HAVE_STDINT_H > # include > # endif This is needed to avoid a "macro redefined" warning e.g. on glibc systems. > that doesn't seem compatible wi

Re: size_max: remove it?

Simon Josefsson wrote: > Sorry, I didn't read size_max.m4 which seem to be doing some > interesting things. This means it's time to put some comments. I also had a hard time remembering why and were used and no others. How about this? > Still, is there a reason the size_max.m4 magic shouldn't b

Re: [bug-gnulib] generic gcd

e module in the modules/* files should be a one-liner. Further doc belongs in the doc/ directory. Bruno 2006-04-29 Bruno Haible <[EMAIL PROTECTED]> * gcd.texi: New file. * gnulib.texi: Include it. 2006-04-29 Bruno Haible <[EMAIL PROTECTED]> * gcd.c:

Re: [bug-gnulib] wait-process module

Derek R. Price wrote: > Well, I'm using the macros already defined in the wait-process module. > If WIFSIGNALED and WTERMSIG are returning the wrong values under > Windows, then the module is already broken because wait_subprocess() is > defined to exit or return 127 if the child died because of a

fix for gnulib-tool --update

Hi, "gnulib-tool --update" always gave an error message. I committed this fix. 2006-04-29 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool: Make --update option actually work. *** gnulib-20060430/gnulib-tool 2006-04-25 14:01:00.0 +0200 --- gnulib-20060430-modi

USE_UNLOCKED_IO

Hi Jim, I'm trying to write documentation for the unlocked-io module. The trigger for the unlocked-io module was already discussed long ago; the current recommendation is, as far as I can see, - that USE_UNLOCKED_IO is defined to 1 by default in m4/unlocked-io.m4, - that multithread programs

doc for the 'verify' module

Hi, I propose to add the attached doc to the 'verify' module. It captures the interesting details of the verify macro. Objections? Bruno = doc/verify.texi == @node Compile-time Assertions @section Compile-time Assertions @cindex assert

comments in getline.h

Hi Simon, May I add comments to getline.h? And also in getline.c, add the specification header before the others, to verify it's self-contained. Bruno *** gnulib-20060430/lib/getline.h 2005-08-02 11:33:30.0 +0200 --- gnulib-20060430-modified/lib/getline.h 2006-05-01 17:07:58.

comments in getdelim.h

Hi Simon, May I add comments to getdelim.h? Bruno *** gnulib-20060430/lib/getdelim.h 2005-08-02 11:33:30.0 +0200 --- gnulib-20060430-modified/lib/getdelim.h 2006-05-01 17:07:54.0 +0200 *** *** 1,5 /* getdelim.h --- Prototype for replacement getdelim

making gl_FULL_HEADER_PATH more reusable

macros that testify the third party. (Grepping the header file for the copyright notice, or similar.) Here is a patch to make it usable for these situations. Opinions, objections? 2006-05-01 Bruno Haible <[EMAIL PROTECTED]> * full-header-path.m4 (gl_FULL_HEADER_PATH): Mo

va_copy, new module 'stdarg'

a va_copy detection macro that I wrote for gettext. (I heard that you don't like #ifdefs inside functions?) Bruno 2006-05-01 Bruno Haible <[EMAIL PROTECTED]> * modules/stdarg: New file. * m4/stdarg.m4: New file. * modules/version-etc: Depend on stdarg.

shorter SUSV3 URLs

Hi, Jim requested that a shorter form of URLs to POSIX:2001 be used, and now that www.opengroup.org implements these shortcuts, why not use them. Derek, any objections? 2006-05-01 Bruno Haible <[EMAIL PROTECTED]> * stdint_.h: Shorter URL. * inttypes.h: Likewise. ***

update use of gnulib-tool

Hi, The way of invoking gnulib-tool has changed in the last few months: Parameters are now cached in a separate file gnulib-cache.m4 that is meant to be stored in CVS, and no longer provided in configure.ac. The steps to update to a new gnulib-tool are: 1) Run once the command $ gnulib-tool --i

Re: [bug-gnulib] wait-process module

Derek R. Price wrote: > Doesn't the fact that Cygwin provided an implementation imply that > there is a way to accomplish it? Cygwin provides not only a implementation, but also fork(), exec(), exit() implementations - that deal specially with the case of a Cygwin program invoking another Cygwin

Re: [bug-gnulib] Re: doc for the 'verify' module

Ralf Wildenhues wrote: > In the second and third item, please don't use plain double quotes ".." Thanks, I keep forgetting about this. > nor GNU-style quotes `..' (in non-verbatim regions). In this case it's verbatim - I cite a message emitted by gcc. Bruno

extend the scope of xasprintf

Hi Oskar et al., In GNU gettext, I've started to use xasprintf nearly everywhere where a string is constructed from other strings. xasprintf (_("creation of file \"%s\" failed"), filename); xasprintf ("%s (%s)", aliasname, fullname); xasprintf ("%s%s%s", prefix, msgid, suffix);

Re: doc for the 'verify' module

Paul Eggert wrote: > Most of that documentation talks about internals to the 'verify' > module. Wouldn't it be better to put the internals elsewhere, and > have the documentation talk only about behavior that users of 'verify' > care about? Good; fine with me too. Bruno

Re: extend the scope of xasprintf

Paul Eggert wrote: > There's a portability issue here, as va_copy is not in C89 > (it's a C99-ism). The stdarg.m4 that I sent yesterday http://lists.gnu.org/archive/html/bug-gnulib/2006-05/msg2.html should take care of it. Bruno

Re: [bug-gnulib] localtime_r thread-safe?

Paul Eggert wrote: > I don't know of any hosts that have multithreading and localtime but > lack a working localtime_r. HP-UX 11.00 with HP/PA. HP-UX 11.23 with IA64. In both cases: checking whether localtime_r is compatible with its POSIX signature... no > The problems that I know of in this

Re: va_copy, new module 'stdarg'

Eric Blake wrote: > My recollection from using the proprietary Green Hills Software compiler > for PowerPC at work was that they implemented va_list as a one-element > array of a struct. They provided va_copy with their latest 4.x version > compiler, but in the 3.x version, my workaround for imple

Re: va_copy, new module 'stdarg'

OK, since there's apparently demand for this module, I added it. If it doesn't work well everywhere, gettext users will likely be the first to report it. Jim, I didn't touch the version-etc module; it's in your responsibility. Bruno

warnings in 'des' module

Hi Simon, When compiling all of gnulib with SunPRO C 5.9 on Linux/x86, there is only one file with warnings. c89 -Xa -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DLIBDIR=\"/packages/inst-sunpro/lib\" -I. -I. -I.. -I../intl -xO5 -c des.c "des.c", line 450: warning: assignment type mismatch:

AC_HEADER_STDBOOL rejects valid C99 implementation

gest to remove these tests, because 1) the value of (bool) -0.5 or (_Bool) -0.0 cannot be tested in an AC_TRY_COMPILE and therefore cannot be cross-compiled. 2) gnulib's stdbool.h substitute cannot achieve (bool) -0.5 == true. Patch for gnulib: 2006-05-07 Bruno Haible <[EMAIL

Re: [bug-gnulib] Re: update use of gnulib-tool

Eric Blake wrote: > Okay to apply? > > 2006-05-06 Eric Blake <[EMAIL PROTECTED]> > > * gnulib-tool (func_version): Base copyright year on CVS date. > (func_emit_header): New function. > (func_emit_lib_Makefile_am): Use it. > (func_emit_tests_Makefile_am): Likewise. >

support for Sun C 5.9

Hi, I added this support for Sun C 5.9 in config.rpath, and updated srclist.txt. 2006-05-05 Bruno Haible <[EMAIL PROTECTED]> * build-aux/config.rpath: Add support for Sun C 5.9 on Linux. *** config.rpath.bak2005-12-28 14:59:19.0 +0100 --- config.rpath2006

Re: [bug-gnulib] Re: extend the scope of xasprintf

Eric Blake wrote: > > + p = result; > > + va_copy (ap, args); > > Why are you using va_copy a second time? vsprintf is allowed to consume > its va_list argument (aka use va_arg on it), so long as it leaves the > va_close for the caller. Right. This is an optim I had neglected. Thanks. > > +

Re: [bug-gnulib] Re: extend the scope of xasprintf

Paul Eggert wrote: > totalsize is of type size_t, so SIZE_MAX is the problem case here, not > INT_MAX. Good point. Also a possible overflow in the xsum() calls before is needed. I'm committing this changed code. Bruno static inline char * xstrcat (size_t argcount, va_list args) { char *resu

Re: [bug-gnulib] Re: extend the scope of xasprintf

Mark D. Baushke wrote: > > static inline char * > > xstrcat (size_t argcount, va_list args) > > { > > char *result; > > ...elided... > > > /* Allocate and fill the result string. */ > > result = (char *) xmalloc (totalsize + 1); > > Why is the cast needed? I was under the impression that GNU

Re: AC_HEADER_STDBOOL rejects valid C99 implementation

Paul Eggert wrote: > > So, _Bool and bool are _not_ integer types. > > No, because ISO C99 section 6.2.5 paragraph 6 says: > > The type _Bool and the unsigned integer types that correspond to the > standard signed integer types are the _standard unsigned integer types_. You're right. I overloo

Re: [bug-gnulib] Re: extend the scope of xasprintf

Paul Eggert wrote: > I guess it partly depends on whether one prefers code to be easy to > read, or easy to write. I usually prefer the former. I also prefer code to be easy to read. But while reading code, casts don't attract my attention particularly... Bruno

Re: [bug-gnulib] xvasprintf

Simon Josefsson wrote: > m4/xvasprintf.m4 contains: > > AC_DEFUN([gl_XASPRINTF], > ^ > > Shouldn't a V be inserted there? Sure, yes. I committed your fix now. Bruno

fix for stdint.h on Cygwin

Hi, When I borrowed the stdint.h from GNU clisp, I forgot to adjust the macro that recognizes Cygwin. Here's the fix. 2006-05-17 Bruno Haible <[EMAIL PROTECTED]> * stdint_.h: Fix recognition of Cygwin. *** stdint_.h 3 May 2006 12:39:46 - 1.13 --- stdint_.h

Cygwin && WIN32

ming that to WIN32_NATIVE. Bruno 2006-05-17 Bruno Haible <[EMAIL PROTECTED]> Cygwin portability. * classpath.c (PATH_SEPARATOR) [CYGWIN]: Define as ':'. *** classpath.c 14 May 2005 06:03:57 - 1.3 --- classpath.c 17 May 2006 13:14:14 -

Re: fix for stdint.h on Cygwin

Eric Blake wrote: > why is it needed? Cygwin's > stdint.h has had all the necessary types for several releases > now, and people compiling against older versions are > encouraged to upgrade their cygwin installation, rather > than propagating workarounds in other packages. You can say the same th

getloadavg module broken

Hi Jim, The module description of module 'getloadavg' appears to be missing the lib/getloadavg.c source file. To reproduce: $ ./gnulib-tool --dir=/smb/orlando/gnuprog/testdir --create-testdir `./gnulib-tool --list` ... checking for working getline function... yes configure: error: ././getloadavg

Re: [bug-gnulib] nanosleep module and mingw32

Hello, > I get the following error when using the nanosleep module and > crosscompiling to W32 with the Debian mingw32 package and > ./configure --host=i586-mingw32msvc : > > ../gnulib/libgnu.a(nanosleep.o):nanosleep.c:(.text+0x64): undefined > reference to `_select' > > The attached patch fixes t

Re: [bug-gnulib] Re: nanosleep module and mingw32

Simon Josefsson wrote: > Wouldn't this be a good situation to have nanosleep depend on the > unistd module, and make the replacement unistd.h include winsock2.h on > mingw32 platforms? After all, nanosleep.c include unistd.h, and > unistd.h define select on some platforms. But is not supposed to

comment in getugroups.c

This fixes an outdated comment in getugroups.c. getgrent et al. are part of POSIX/XSI since the Base Specifications Version 5. *** gnulib-20060430/lib/getugroups.c2005-09-23 06:15:13.0 +0200 --- gnulib-20060430-modified/lib/getugroups.c 2006-05-19 00:46:28.0 +0200 **

Re: [bug-gnulib] getgrouplist

treated (gid_t)(-1) specially. - The getgrent() loop in getugroups.c is O(n^2). I reduced this to O(n log n). You could also make it O(n) by use of a hash table. Proofreading welcome, as always! This is new, untested code. 2006-05-18 Bruno Haible <[EMAIL PROTECTED]> * m4/getgrou

Re: Cygwin && WIN32

Paul Eggert wrote: > > In other places I used to define WIN32 as an abbreviation of > > defined _WIN32 || defined __WIN32__ > > Now I'm renaming that to WIN32_NATIVE. > > Would WOE32_NATIVE be a better name? I don't know. I use the term "Woe32" when I talk about the platform which is not a wi

Re: getloadavg module broken

Jim Meyering wrote: > That is because it's looking in the wrong place. > This patch fixes the immediate problem Indeed, thanks. But the bug is really in the AC_FUNC_GETLOADAVG macro in autoconf. The macros AC_FUNC_ERROR_AT_LINE, AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK, AC_FUNC_MALLOC, AC_FU

a press article about gnulib

gnulib is getting exposed to a larger audience: http://www.linux.com/article.pl?sid=05/12/16/2051201 Nicely written article, IMO. Bruno

Re: [bug-gnulib] Re: standards.texi language cleanup (was: Cygwin && WIN32)

Karl Berry wrote: > * doc/standards.texi (System Portability): Spell out `free BSD > variants', instead of using the term `*BSD'. > > Before I bother rms with this, can you please explain to me the > objection to "*BSD"? I'd never heard that before. NetBSD and OpenBSD > do

function portability documentation

Hi, Inspired by Paul Eggert's new chapter about "Portable C and C++ Programming", I went out and collected portability notes and pitfall reminders for over 200 among the 1116 POSIX functions. (Attached.) You will also notice that a section named "Function Portability" and with the same purpose ex

Re: function portability documentation

Ralf Wildenhues wrote: > so here we go, quickly: Thanks, Ralf, for proofreading. I've integrated many of your remarks. > - Should the entries be indexed? I would prefer so. Yes, certainly. Probably this is also a good occasion to split the "program index" and the "function / header index". IMO

Re: [bug-gnulib] Re: function portability documentation

Ben Pfaff wrote: > I did some proofreading and found some minor things to point out. Thanks. I'm fixing most of these. > Should "b" be @samp{b}? @code{"b"} is better here: the 'b' must be part of C string. > > + On Windows, this function doesn't support the @code{'} flag and the > > @code{hh},

Re: [bug-gnulib] [EMAIL PROTECTED]: GNU Coding Standards, internatialisation and plurals]

ing is useful is when the %d is a text field or number spinner where the user can enter 0, 1, or any integer, and the label surrounding the text field is static (isn't updated each time the user changes the value). Karl, Find here a patch. 2006-05-22 Bruno Haible <[EMAIL PROTECTED]>

Re: [bug-gnulib] Re: gettimeofday() for Win32

Hi, Thanks for improving the gettimeofday replacement. > +# if HAVE__FTIME > + > + struct _timeb timebuf; > + > + _ftime (&timebuf); > + tv->tv_sec = timebuf.time; > + tv->tv_usec = timebuf.millitm * 1000; > + > + return 0; > + Similar things should be done for systems that have no gettim

Re: [bug-gnulib] Re: [bug-gnulib] Re: gettimeofday() for Win32

Paul Eggert wrote: > Some old SVR4 systems put a one-argument > gettimeofday prototype into their . Also, Solaris 2.4 has > a one-argument prototype for C++ only. The Solaris 2.4 has: #ifdef __cplusplus int gettimeofday(struct timeval *, void *); int settimeofday(struct timeval *, void *); #end

Re: [bug-gnulib] Handling null pointers to printf

For this case, it does not make sense to let the user change, recompile, relink and rerun his program, when all he wants is debugging output. I'm applying the appended patch. Bruno 2006-05-24 Bruno Haible <[EMAIL PROTECTED]> * printf-args.c (printf_fetchargs): Turn NUL

Re: [bug-gnulib] Handling null pointers to printf

Bruce Korb wrote: > sometimes, I do want the seg fault. So, how about selectable behavior? If you want to always get a SEGV when the user passes a NULL argument, you will have to arrange that through your code. POSIX doesn't guarantee you a SEGV here. 90% of your users, at least, will be on glib

Re: [bug-gnulib] Re: AIX tests failures

nc_strndup = no && > + if test $gl_cv_func_strndup = no; then Was this intended redundancy or a typo? Bruno 2006-05-30 Ralf Wildenhues <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> * strndup.m4 (gl_FUNC_STRNDUP): Replace the AC_REPLACE_FUN

Re: [bug-gnulib] strfile: new module

Simon Josefsson wrote: > This is used in GnuTLS, and I need it in Shishi now, so I thought that > it should be a module. What do you think? I agree it's common enough that we can use it in gnulib. > Possibly, there should be a xstrfile too, that uses xrealloc... Yes. > Index: modules/strfile

Re: [bug-gnulib] AIX tests failures

Ralf Wildenhues wrote: > Tested on AIX 4.3.3, 5.1, 5.2 (first has strnlen and strndup broken, > second has strnlen fixed, last has both fixed) Hmm? My results for AIX 5.1 differ: On AIX 5.1.0.0 I get checking whether strndup is declared... yes checking for working strndup... no checking whether s

Re: [bug-gnulib] AIX tests failures

Ralf Wildenhues wrote: > > Hmm? My results for AIX 5.1 differ: On AIX 5.1.0.0 I get > > > > checking whether strndup is declared... yes > > checking for working strndup... no > > checking whether strnlen is declared... yes > > checking for working strnlen... no > > (lslpp -L). The one I tested on

Re: strfile: new module

Simon Josefsson wrote: > Here's the module. Only lighted tested, mostly to get feedback on the > approach, but if you agree with it, detailed review would be useful. Looks already quite good. Only minor nits: > +/* Read a STREAM and return a newly allocated string with the content, > + and set

Re: [bug-gnulib] SSIZE_MAX

Paul Eggert wrote: > I think size_max.h is there only because SIZE_MAX is in different > headers on different systems. Rather, size_max.h is there only because the standard says it's defined in but gnulib so far didn't provide a complete replacement. This will change, thanks to Derek's full-head

Re: [bug-gnulib] csharpcomp: cscc writes to srcdir?

Simon Josefsson wrote: > I'm not sure why I've been starting to see this now, it has worked > fine since the module was added, perhaps the C# compiler changed > during some upgrade. Anyway, with 'make distcheck' I get: > > checking for preferred C# implementation... any > ... > checking for C# co

Fix size_max macro

Hi, The size_max macro has a bug: it assumes that 'expr' can deal with numbers as large as SIZE_MAX/10. Which is not true when cross-compiling from a 32-bit platform to a 64-bit platform. Here is a fix, that takes care that SIZE_MAX is valid in preprocessor expressions (i.e. contains no casts).

Re: Fix size_max macro

Paul Eggert wrote: > The basic idea seems fine, but isn't that off by a factor of 2? It defines > size_t_bits_minus_2 = sizeof (size_t) * CHAR_BIT - 2 > and then defines SIZE_MAX to (((1U << $size_t_bits_minus_2) - 1) * 2 + 1). > Unless I'm missing something, on a 32-bit host, that will set SIZE_M

Re: stdint module rewrite

Simon Josefsson wrote: > Is there anything in this that would enable me to install a "stdint.h" > file in $prefix We could just need to change all #if HAVE_... into #if @HAVE_...@ and use more substitutions in the creation of the stdint.h file. But there are two problems: - It's compiler depe

Re: stdint module rewrite

Paul Eggert wrote: > The approach assumes a conventional architecture in which there are > underyling signed and unsigned types of width 8, 16, 32, and 64, and > the only argument is which int*_t type is which. Yes, and it does so using the approach "use what the system provides, and define a subs

Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.)

Ralf Wildenhues wrote: > You should be able to rewrite this to use shell loops for the most part; > similar to how I started in this thread: > http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00161.html > but never finished the last bits. Actually, that's how I started doing it: fo

Re: stdint module rewrite

Paul Eggert wrote: > the same compiler, with > different options) might disagree about the standard types. So it's > not an issue of solving the problem in general; it's an issue of how > likely it would occur in practice, with the approach I proposed. We are not the only people providing a subs

Re: [bug-gnulib] Re: regex.c not 64-bit clean (?)

Eric Blake asked: > Bruno, is it okay to apply this? > > 2006-06-14 Eric Blake <[EMAIL PROTECTED]> > > * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. The change is OK. I'm copying it to GNU gettext, where the file comes from. (Although I think that using CPPFLAGS=-Werror is ca

Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.)

Ralf Wildenhues wrote: > > But this way, autoheader didn't recognise the AC_DEFINE_UNQUOTED > > invocations, i.e. in the end, HAVE_INT8_T etc. were not present in > > config.h.in. > > Yes, but that's basically the only part that breaks this way. And only > one part of the AC_DEFINE_UNQUOTED, name

Re: stdint module rewrite

Simon Josefsson wrote: > >> The essential difference is that the installed "idn-int.h" should work > >> without assuming any config.h symbols, but instead rely on a > >> combination of install-time "guesses" and CPP symbol checks to define > >> the proper uint32_t types for the host and the compile

Re: Fix size_max macro

Here's the fix that I now committed: 2006-06-15 Bruno Haible <[EMAIL PROTECTED]> * size_max.m4 (gl_SIZE_MAX): Make it work also when cross-compiling. *** size_max.m4 11 Jul 2005 11:29:40 - 1.4 --- size_max.m4 16 Jun 2006 13:12:33 -

Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.)

Hi Mark, > I see the following: > > #if 0 > # ifndef UINT_FAST16_MAX > # if < 32 > # define UINT_FAST16_MAX (((1 << ( - 1)) - 1) * 2 + 1) > # else > # define UINT_FAST16_MAX (((1UL << ( - 1)) - 1) * 2 + 1) > # endif > # endif > #else > > I am not at all certain that all compilers will

Re: [bug-gnulib] arpa_inet_h: new module, replaces inet_ntop

Simon Josefsson wrote: > It would replace the > inet_ntop module, and lib/inet_ntop.h would be removed. > > With this, files only need to #include for inet_ntop or > inet_pton, just like it should be. How would this work on platforms which have an already but don't have and don't declare the in

Re: [bug-gnulib] gettext: -lintl if necessary

Simon Josefsson wrote: > (Sorry if this is a dupe, didn't see it delivered.) > > The gettext module brings in the proper -I's to make gettext calls > work, but doesn't bring in the library. This is normal. We specify the needed libraries for each program and for each shared library separately. So

Re: [bug-gnulib] read-file (was: strfile)

Simon Josefsson wrote: > Is this ready to be installed? Yes, it looks good. Bruno

Re: [bug-gnulib] assume errno

Eric Blake wrote: > OK to apply? Looks ok. I applied your changes to unsetenv.c, strtol.c (shared with GNU gettext) and unicodeio.c (for which I'm responsible), and this extra patch: 2006-06-17 Bruno Haible <[EMAIL PROTECTED]> * setenv.m4 (gl_PREREQ_SETENV, gl_PREREQ_UNS

<    1   2   3   4   5   6   7   8   9   10   >