Eric Blake wrote:
> Bruno, you may be interested in this thread:
> http://gcc.gnu.org/ml/gcc/2007-06/msg00122.html.
>
> It looks like for *printf-posix on mingw and other WOE32 environments, you
> will
> need to add a call to _set_printf_count_output to ensure that %n will work on
> mingw execu
-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.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version:
Ulrich Drepper wrote:
> Intel's IA-64 people (and I smell HP in there) are the idiots who caused this.
The crash also occurs on i386 platforms, e.g. CPUs built by AMD.
> Here it's the implementation of the processor which is at fault.
But printf %Le does not do any hardware floating-point instru
Andreas Schwab wrote:
> > Just printing an arbitrary
> > "long double" should not make a server vulnerable to a DoS attack.
>
> In which way is this different from passing NULL to strlen?
Common knowledge: Programmers know that NULL is an invalid value for
many operations. They usually don't know
Andreas Schwab asked:
> In which way is this different from printf("%s", (char*)1)?
The elementary operations on strings (strlen etc.) crash on (char*)1 too,
therefore one cannot blame 'printf' in particular in the string case.
The elementary operations on long doubles (==, +, isnanl, etc.) produ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stop this nonsense discussion. Intel's IA-64 people (and I smell HP in
there) are the idiots who caused this. Talk to them. If the work
around wouldn't be as simple as Jakub suggested I'd leave it as is.
Garbage in, whatever out, including crashes.
Andreas Schwab writes:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
> > I'm interested, because I don't want my applications to segfault on such
> > inputs. Sure it may look a little far-fetched, but I think it's not.
> > Imagine such a bit pattern being injected into a network data stream
> > t
Paul Mackerras <[EMAIL PROTECTED]> writes:
> In general with scalars there is no value whose meaning or effect is
> undefined, unlike pointers.
This is not true.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
On 6/6/07, Andreas Schwab <[EMAIL PROTECTED]> wrote:
Jim Meyering <[EMAIL PROTECTED]> writes:
> I'm interested, because I don't want my applications to segfault on such
> inputs. Sure it may look a little far-fetched, but I think it's not.
> Imagine such a bit pattern being injected into a netw
[EMAIL PROTECTED] (Steven M. Schweda) writes:
>Only in the sense that I'm working on (Digital/Compaq/HP) Tru64 UNIX,
> not (HP) HP-UX. Different heritage, different future (none v, some).
Ah, OK, sorry about the confusion. I installed this fix into gnulib,
and it should appear in the next
Jakub Jelinek <[EMAIL PROTECTED]> wrote:
...
> We already special case e.g. 0x.8000. (pseudo denormal
> with implicit bit set), so I guess we can also special case this other
> misdesigned FP type.
Great!
...
> That said, programs that pass arbitrary bit patterns read from an inse
On Wed, Jun 06, 2007 at 02:32:20PM +0200, Jim Meyering wrote:
> Did you mean to close this bug as "resolved/invalid"?
>
> printf crashes on some 'long double' values
> http://sourceware.org/bugzilla/show_bug.cgi?id=4586
> [BTW, it segfaults on i686 rawhide, even with no compiler option
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>>
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I'm interes
> > I'm surprised to hear you arguing that it is desirable for glibc's printf
> > implementation to segfault for a long-double with an unusual bit
> pattern.
>
> In which way is this different from printf("%s", (char*)1)?
I see a huge difference between passing an invalid pointer (your
printf("%
Jim Meyering <[EMAIL PROTECTED]> writes:
> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>
>>> Andreas Schwab <[EMAIL PROTECTED]> wrote:
Jim Meyering <[EMAIL PROTECTED]> writes:
> I'm interested, because I don't want my applications to segfaul
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>>
I'm interested, because I don't want my applications to segfault on such
inputs. Sure it may look a little
Jim Meyering <[EMAIL PROTECTED]> writes:
> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>
>>> I'm interested, because I don't want my applications to segfault on such
>>> inputs. Sure it may look a little far-fetched, but I think it's not.
>>> Imagine suc
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I'm interested, because I don't want my applications to segfault on such
>> inputs. Sure it may look a little far-fetched, but I think it's not.
>> Imagine such a bit pattern being injected into a network dat
Bruno, you may be interested in this thread:
http://gcc.gnu.org/ml/gcc/2007-06/msg00122.html.
It looks like for *printf-posix on mingw and other WOE32 environments, you will
need to add a call to _set_printf_count_output to ensure that %n will work on
mingw executables when run on Vista. (Thank
Jim Meyering <[EMAIL PROTECTED]> writes:
> I'm interested, because I don't want my applications to segfault on such
> inputs. Sure it may look a little far-fetched, but I think it's not.
> Imagine such a bit pattern being injected into a network data stream
> that is then printed as a long double
Hi Andreas,
Did you mean to close this bug as "resolved/invalid"?
printf crashes on some 'long double' values
http://sourceware.org/bugzilla/show_bug.cgi?id=4586
[BTW, it segfaults on i686 rawhide, even with no compiler options]
I'm interested, because I don't want my applications to
Jim Meyering wrote:
> perhaps some glibc-post-2.6 release would be a more reasonable target.
Since the mentioned printf crash is not recognized as a bug by the glibc
maintainers, I don't have much hope that it will be fixed, ever.
Bruno
James Youngman wrote:
> It might be more helpful to use meaningful variable names for your
> constants here, because that way the error message you get when the
> assert fails tells you which test has gone wrong.
But in order to understand the test, you have to look at the test's source
code anywa
Bruno Haible <[EMAIL PROTECTED]> wrote:
> On i386, x86_64, ia64, the 'long double' format has an explicitly represented
> most significant mantissa bit. This has the consequence that some bit patterns
> in a 'long double' are not covered by IEEE 754. *printf better prints these
> numbers as NaN (ra
On 6/6/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
+ { /* Unnormalized number. */
+ static memory_long_double x =
+ { LDBL80_WORDS (0x4000, 0x6333, 0x) };
+ ASSERT (isnanl (x.value));
+ }
+ { /* Pseudo-Denormal. */
+ static memory_long_double x =
+ { LD
25 matches
Mail list logo
