Re: localcharset is conditional on HAVE_SETLOCALE

Paul Eggert wrote: > The localcharset test slows down 'configure' and > does not affect how the code actually behaves. OK to install this? > > 2006-10-17 Paul Eggert <[EMAIL PROTECTED]> > > Simplify localcharset code a bit and speed up configuration > by removing test for setlocale

setlocale (was: Re: hello-2.1.93 internationalization doesn't work)

Bruno Haible <[EMAIL PROTECTED]> writes: > The reason is that HAVE_SETLOCALE is tested, but nowhere defined. Since one > can assume setlocale() already for ca. 5 years, there is no risk in removing > the HAVE_SETLOCALE. Here is a proposed patch. I'm still testing for setlocale in libidn. Why can

Re: setlocale (was: hello-2.1.93 internationalization doesn't work)

Simon Josefsson wrote: > Why can we assume setlocale exists? Because we haven't encountered systems without a setlocale() for 10 years. The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx. > Is it POSIX? Even more: It's specified by ISO C 99. Bruno

Re: setlocale

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Why can we assume setlocale exists? > > Because we haven't encountered systems without a setlocale() for 10 years. > The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx. > >> Is it POSIX? > > Even more: It's spe

read_utmp changes

I have installed the following change to read_utmp: 2006-10-18 Sergey Poznyakoff <[EMAIL PROTECTED]> * lib/readutmp.c (desirable_utmp_entry): Implement new flag: READ_UTMP_USER_PROCESS. * lib/readutmp.h (READ_UTMP_USER_PROCESS): New flag Index: lib/readutmp.c ==

Re: setlocale

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Why can we assume setlocale exists? >> Is it POSIX? > > Even more: It's specified by ISO C 99. Even more than that: it's in C90 also. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org

Reusing vasnprintf

For GDB, we're looking at fixing our printf built in command once and for all. What we really need to do that is two separate interfaces that can talk to each other: one for parsing a format string, and one for converting arguments. Basically, this is printf_parse plus the rest of vasnprintf, but

Re: [bug-gnulib] Reusing vasnprintf

Daniel Jacobowitz wrote: > For GDB, we're looking at fixing our printf built in command once and > for all. What we really need to do that is two separate interfaces > that can talk to each other: one for parsing a format string, and one > for converting arguments. Do you need a standard printf,

Re: [bug-gnulib] Reusing vasnprintf

On Wed, Oct 18, 2006 at 06:08:22PM +0200, Bruno Haible wrote: > Daniel Jacobowitz wrote: > > For GDB, we're looking at fixing our printf built in command once and > > for all. What we really need to do that is two separate interfaces > > that can talk to each other: one for parsing a format string

Re: __long64_t not declared AIX 5.3.0.50, gcc 4.0.2

In Perry Smith <[EMAIL PROTECTED]> writes: > *** lib/inttypes_.h Mon Aug 28 20:42:18 2006 > --- lib/inttypes.hTue Oct 17 04:01:55 2006 Thanks, I got that patch. Unfortunately the diff between lib/stdint_.h and lib/stdi

Re: setlocale

Ben Pfaff <[EMAIL PROTECTED]> writes: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> Simon Josefsson wrote: >>> Why can we assume setlocale exists? >>> Is it POSIX? >> >> Even more: It's specified by ISO C 99. > > Even more than that: it's in C90 also. Yes, that's the key point: it was in ISO C9

Re: read_utmp changes

"Sergey Poznyakoff" <[EMAIL PROTECTED]> wrote: > I have installed the following change to read_utmp: > > 2006-10-18 Sergey Poznyakoff <[EMAIL PROTECTED]> > > * lib/readutmp.c (desirable_utmp_entry): Implement new flag: > READ_UTMP_USER_PROCESS. > * lib/readutmp.h (READ_UTM

Re: [bug-gnulib] Reusing vasnprintf

Daniel Jacobowitz wrote: > A standard printf. We're not trying to print out new things, we're > trying to print out standard things using different sorts of arguments. > > Here's an example. You can open up GDB and say this: > > (gdb) printf "%lld\n", 1 > 1 OK, thanks, I see the intent and the

Re: [bug-gnulib] Reusing vasnprintf

On Wed, Oct 18, 2006 at 09:44:58PM +0200, Bruno Haible wrote: > > > How does what you need compare with the register_printf_function / > > > parse_printf_format facility in glibc's public header file ? > > > > Wow, I knew about register_printf_function, but I'd never noticed > > parse_printf_form

Re: [bug-gnulib] Reusing vasnprintf

On Wed, Oct 18, 2006 at 04:10:46PM -0400, Daniel Jacobowitz wrote: > I'm now worrying that I misunderstood how the gnulib vasnprintf works, > though. This may be less useful than I thought, since it uses both the > result of arg parsing and the format string :-( Never mind, this bit is obviously

hello pretest 2.1.94

I put another hello pretest at ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz). Maybe someday it'll even be ready for a release :). Thanks, Karl

Re: hello pretest 2.1.94

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Karl Berry on 10/18/2006 5:33 PM: > I put another hello pretest at > ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz). > > Maybe someday it'll even be ready for a release :). Is it worth demonstrating how to portably use gcc

strftime.c problem on dietlibc

Hi, When compiling coreutils-5.3 with dietlibc I got the following compiler error: In file included from fprintftime.c:7: strftime.c: In function 'strftime_case_': strftime.c:645: error: invalid use of undefined type 'struct __stdio_file' strftime.c:737: error: invalid use of undefined type 'stru

[patch] gnulib-tool --local-dir

Doesn't seem to work properly without the following (obvious?) patch. -- Chuck 2006-10-18 Charles Wilson * gnulib-tool: trimming $local_gnulib_dir variable shouldn't clobber $sourcebase. Index: gnulib-tool === RC