From: | "John D(dot) Burger" <john(at)mitre(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Buffer overflow in psql |
Date: | 2006-11-22 20:57:26 |
Message-ID: | 8CB0E733-D4C0-431F-AD37-EBE6FD2CC8FE@mitre.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Ah so, that explains how come it noticed. BTW, I see that somebody
> already changed the array size to 16 bytes in HEAD --- so it's just
> the back branches that need fixing.
Um, is that really considered a fix??? We all know that there's no
guarantee at all, even in ANSI C, that unsigned int isn't bigger than
32 bits, right? There are still some weird architectures out there.
Whenever I need to print some integer x, I use code like this:
char buf[1 + sizeof(x) * CHAR_BIT / 3]
I let the compiler figure out the length needed to print in octal,
and use that as a (slight) over-estimate of the length for decimal.
As a bonus, the type of x can be changed without having to track down
this kind of crap.
Alternatively, the code in question could just cast to one of the
newer fixed-length int types, like int32_t, although that has its own
problems.
Sorry for the pedantry ...
- John D. Burger
MITRE
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-22 21:03:06 | Re: Trapping PL/Perl spi_query_exec errors |
Previous Message | Jorge Godoy | 2006-11-22 20:53:07 | Re: Multiple currencies in a application |