Hi Paul and others,
The gnulib macro 'allocsa' allocates memory on the stack or on the heap,
depending whether the requested memory size is smaller than a threshold
or not. 'freesa' frees such allocated memory.
The newest Microsoft runtime libraries contain functions with identical
semantics unde
On Thu, 7 Jun 2007, Jan-Benedict Glaw wrote:
There's a difference in
void send_float (float foo, int fd) {
write (fd, &foo, sizeof (float));
}
and
void send_float (float foo, int fd) {
char buf[100];
snprintf (buf, sizeof
On Fri, 2007-06-08 00:14:34 +0100, Nix <[EMAIL PROTECTED]> wrote:
> On 7 Jun 2007, Tor Myklebust outgrape:
> > And the second variant can segfault if you replace 'float' by 'long
> > double' (changing the format string appropriately) and you feed it
> > something bad. Why is this a good thing?
>
On 7 Jun 2007, Tor Myklebust outgrape:
> And the second variant can segfault if you replace 'float' by 'long
> double' (changing the format string appropriately) and you feed it
> something bad. Why is this a good thing?
It's somewhat unusual for applications to accept double-format data over
the
On Thu, 2007-06-07 13:55:41 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > On Thu, 2007-06-07 13:27:49 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > read what i said again ... the clients are doing write()/read() on the
> > > doubl
On Thu, 2007-06-07 13:57:17 -0400, Tor Myklebust <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Jun 2007, Jan-Benedict Glaw wrote:
> >There's a difference in
> >
> > void send_float (float foo, int fd) {
> > write (fd, &foo, sizeof (float));
> > }
> >
> >and
> >
> > void send_float
Pádraig Brady <[EMAIL PROTECTED]> wrote:
...
> Another thing I just noticed. I would expect the precision
> of all output in the following command to be to 2 decimal places not 1:
>
> $ seq 0.00 0.01 0.90 | grep "\.[0-9]$"
> 0.1
> 0.2
> 0.3
> 0.4
> 0.5
> 0.6
> 0.7
> 0.8
> 0.9
Well, at least with t
Hi,
On MacOS X and Windows systems, users are expected to set their locale
preferences in some GUI. This is foreseen by POSIX, which says:
"All implementations shall define a locale as the default locale,
to be invoked when no environment variables are set, or set to the
empty st
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> On Thu, 2007-06-07 13:27:49 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
>> read what i said again ... the clients are doing write()/read() on the
>> double
>> directly, but one side has debugging enabled so it additionally does
>> printf()
>
On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> On Thu, 2007-06-07 13:27:49 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > read what i said again ... the clients are doing write()/read() on the
> > double directly, but one side has debugging enabled so it additionally
> > does printf() o
On Thu, 2007-06-07 13:27:49 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > > > On Wed, 2007-06-06 22:4
On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]>
> > > wrote:
> > > > If I read a stre
On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> > > If I read a stream of data (from a file, a network socket, etc.) which
> > > is su
On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> > If I read a stream of data (from a file, a network socket, etc.) which
> > is supposed to contain valid floating-point data, it is reasonable for
> > a program to pr
It may well be that the current glibc behavior is not prohibited by
any standard, but I think that "quality of implementation" concerns
(not to mention a desire for robustness and security) would dictate a
more manageable result.
Your right, it would seem that if its possible to make a fix t
Bruno Haible <[EMAIL PROTECTED]> writes:
>> +#if HAVE_WCHAR_H
>> /* Include the original . */
>> /* The include_next requires a split double-inclusion guard. */
>> #if @HAVE_INCLUDE_NEXT@
>> @@ -42,6 +43,7 @@
>> #else
>> # include @ABSOLUTE_WCHAR_H@
>> #endif
>> +#endif
>>
>> #ifndef _G
Simon Josefsson wrote:
> On uClinux I got:
>
> /bin/sh ../libtool --tag=CC --mode=compile ucfront-gcc m68k-elf-gcc -m5200
> -DCONFIG_COLDFIRE -DHAVE_CONFIG_H -I. -I.. -I../../../lib/gl -I../intl
> -I/data/fast/uclinux/uClinux-dist/lib/libgcrypt/inst/include
> -I/data/fast/uclinux/uClinux-dis
On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> If I read a stream of data (from a file, a network socket, etc.) which
> is supposed to contain valid floating-point data, it is reasonable for
> a program to print it. Especially so if the printing I am doing is a
Dat
On Thu, Jun 07, 2007 at 12:10:26PM +0200, Jan-Benedict Glaw wrote:
> On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> > If I read a stream of data (from a file, a network socket, etc.) which
> > is supposed to contain valid floating-point data, it is reasonable for
> >
On uClinux I got:
/bin/sh ../libtool --tag=CC --mode=compile ucfront-gcc m68k-elf-gcc -m5200
-DCONFIG_COLDFIRE -DHAVE_CONFIG_H -I. -I.. -I../../../lib/gl -I../intl
-I/data/fast/uclinux/uClinux-dist/lib/libgcrypt/inst/include
-I/data/fast/uclinux/uClinux-dist/lib/libgpg-error/inst/include -g
On 6/7/07, Ulrich Drepper <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
> The crash also occurs on i386 platforms, e.g. CPUs built by AMD.
Bullshit. Those CPU never produce such numbers.
Nevertheless they can occur, as explained earlier in the t
21 matches
Mail list logo
