Subject: Re: lib/35401
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Thorsten Glaser <tg@mirbsd.de>
List: netbsd-bugs
Date: 01/12/2007 10:20:02
The following reply was made to PR lib/35401; it has been noted by GNATS.
From: Thorsten Glaser <tg@mirbsd.de>
To: gnats-bugs@NetBSD.org
Cc: Felix von Leitner <felix-bsd@fefe.de>,
Benny Siegert <bsiegert@mirbsd.de>
Subject: Re: lib/35401
Date: Fri, 12 Jan 2007 10:13:55 +0000 (UTC)
Christian Biere dixit:
> > >For what it's worth, this has undefined behaviour even though it probably =
> > just works with the current GCC.
>
> > Hm, "in theory" true, but "our" integers are 32 bits, and
> > the new value is either larger or equal, or it isn't.
>
> Undefined behaviour doesn't work that way.
Sure, but get real. We're talking real world code here.
If that would be a problem, there's much more trouble
than just this piece of code.
> > @@ -327,7 +335,7 @@ vfprintf(FILE *fp, const char *fmt0, _BS
> > }
> > if ((m = fmt - cp) != 0) {
> > PRINT(cp, m);
> > - ret += m;
> > + ADDTORET(m);
> > }
>
> I thought your int has only 32 bits?
Huh? Did I miss something?
This code (seems to do, at least) does what it's supposed
to, namely preventing this sort of attack in real-world
scenarios, where integer overflows silently (plus setting
some flag in the CPU, which is of course ignored by C)
wrap around to high negative values.
bye,
//mirabile
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
-- Henry Nelson, March 1999