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