Albert Chin wrote:
> 1 2 3 4 5 6 7
> OpenBSD 4.0: . # . . . . .
> HP-UX 10.20: # # . . . . #
Thanks, I added this to printf.m4.
> HP-UX 10.20's libc has snprintf() but there is _no_ function pro
On Sun, Mar 04, 2007 at 03:57:00PM +0100, Bruno Haible wrote:
> Volunteers wanted: If you have access to a system with
> - OpenBSD
> - HP-UX 10
1 2 3 4 5 6 7
OpenBSD 4.0: . # . . . . .
HP-UX 10.20:
On Tue, Mar 06, 2007 at 02:09:01AM +0100, Bruno Haible wrote:
> Using snprintfv seems better for you - there you can redefine each directive's
> execution independently.
Yes - that's exactly my plan :-)
> > Anyway, I'm stalled for a while on snprintfv
>
> Why? Paolo presented a nice plan [1]. It
Daniel Jacobowitz wrote:
> What GDB wants to print in hex floating isn't a host double but a
> target double; if we cast to host double or long double, then in some
> circumstances we lose precision.
For this, in general, you could probably use gnulib's vasnprintf.c source
with a lot of #ifdefs. A
Ralf Wildenhues wrote:
> | 1 2 3 4 5 6 7
> | OpenBSD 3.9 . # . . . . .
> | HP-UX 10.20 # # . . . . #
> | NetBSD 4.99.13 . . . . . . .
Thanks for these results. I've add
Hello Bruno,
* Bruno Haible wrote on Sun, Mar 04, 2007 at 03:57:00PM CET:
[...]
Volunteers wanted: If you have access to a system with
[...]
could you please run the configure script from the attached package and
report the results?
| 1 2 3 4 5 6 7
Bruce Korb <[EMAIL PROTECTED]> writes:
> Bruno Haible wrote:
>> Paul Eggert wrote on 2007-02-16:
>>> It's a bit of a pain that this will reject all cross-compiled snprintfs.
>>> Is there some way you can test for this at compile-time?
>>
>> Cross-compiles can be handled at configure time, by usin
On Sun, Mar 04, 2007 at 01:23:58PM -0800, Brian Dessent wrote:
> Er, but the entire reason for the existance of this module was so that
> gdb can use %a to display floating point variables in hex, without
> having to worry about whether the platform's snprintf natively supports
> it or not.
No, th
Bruce Korb wrote:
> In other words, why worry? Maybe right now
> I don't use the 'a' directive, is it worth the bother to go
> back and fix up configure scripts if the 'a' directive creeps
> into my sources?
You said already in [1] that you don't care about code size. Other people care.
gnulib wi
Brian Dessent wrote:
> Er, but the entire reason for the existance of this module was so that
> gdb can use %a to display floating point variables in hex, without
> having to worry about whether the platform's snprintf
Clearly I wasn't clear enough: just always use gnulib's *printf. :)
Bruce Korb wrote:
> I know this may be seen as flame bait, but is it not just a
> bit easier to simply presume that the gnulib library is always
> going to be at least as standards compliant as the native
> implementation? In other words, why worry? Maybe right now
> I don't use the 'a' directiv
Bruno Haible wrote:
> Paul Eggert wrote on 2007-02-16:
>> It's a bit of a pain that this will reject all cross-compiled snprintfs.
>> Is there some way you can test for this at compile-time?
>
> Cross-compiles can be handled at configure time, by using predetermined
> test results (and assuming th
Bruno Haible wrote:
> Volunteers wanted: If you have access to a system with
> - FreeBSD 5.x
Results for FreeBSD 5.4:
ac_cv_func_snprintf=yes
gl_cv_func_printf_directive_a=yes
gl_cv_func_printf_directive_n=yes
gl_cv_func_printf_positions=yes
gl_cv_func_printf_retval_c99=yes
gl_cv_func_printf_s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 3/4/2007 7:57 AM:
>
> Here's the current matrix:
>
>1 = checking whether printf supports size specifiers as in C99...
>2 = checking whether printf supports the 'a' and 'A' directives...
>3 = checking whether p
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
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
> >> >
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
> > 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
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
>> >
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
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
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 @
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> We could of course test whether the system is Windows, using
>> #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>> or similar. Is that a better idea?
>
> Do you mean to have two Autoconf tests
Ben Pfaff <[EMAIL PROTECTED]> writes:
> We could of course test whether the system is Windows, using
> #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> or similar. Is that a better idea?
Do you mean to have two Autoconf tests, one at compile-time (with the
above code), and o
Paul Eggert <[EMAIL PROTECTED]> writes:
> It's a bit of a pain that this will reject all cross-compiled snprintfs.
> Is there some way you can test for this at compile-time?
>
> Does the nonstandard snprintf have exactly the same signature as the
> C99 snprintf? If not, we should be able to catch
It's a bit of a pain that this will reject all cross-compiled snprintfs.
Is there some way you can test for this at compile-time?
Does the nonstandard snprintf have exactly the same signature as the
C99 snprintf? If not, we should be able to catch this at
compile-time.
Does the nonstandard imple
Pre-C99 versions of snprintf often had an interface different
from the C99 interface: they would return -1 when the buffer was
too small, and the "size" argument was not necessarily
interpreted the same way. However, the current Gnulib snprintf
module doesn't check whether snprintf is C99-complian
27 matches
Mail list logo
