Christos Zoulas wrote:
> In article <20070111180941.GA22758@cyclonus>,
> Christian Biere  <christianbiere@gmx.de> wrote:
> >Christos Zoulas wrote:
> >> In article <20070111085655.GA16866@cyclonus>,
> >> Christian Biere  <christianbiere@gmx.de> wrote:
> >> >Christos Zoulas wrote:
> >> >> Index: vfprintf.c
> >> >> ===================================================================
> >> >> RCS file: /cvsroot/src/lib/libc/stdio/vfprintf.c,v
> >> >> retrieving revision 1.54
> >> >> diff -u -u -r1.54 vfprintf.c
> >> >> --- vfprintf.c	30 Oct 2006 05:10:40 -0000	1.54
> >> >> +++ vfprintf.c	11 Jan 2007 02:56:58 -0000
> >> >> @@ -353,6 +353,8 @@
> >> >>  		if ((m = fmt - cp) != 0) {
> >> >>  			PRINT(cp, m);
> >> >>  			ret += m;
> >> >> +			if (ret < 0)
> >> >> +				goto ovfl;
> >> >>  		}
> >> >
> >> >For what it's worth, this has undefined behaviour even though it
> >probably just
> >> >works with the current GCC.
> > 
> >> Can you please explain which part is undefined behavior?
> >
> >ret has type "int". Your fix assumes that an overflow causes a negative result.
> >C says an integer overflow has undefined behaviour. I guess it works in practice
> >but hardware with saturation arithmetic exists (MMX, SSE) and it might be the
> >default operation in future architectures.
> 
> I seriously doubt it that we'll see saturation arithmetic in the C integral
> types, but your point is valid.

Even if not, a compiler could potentially just compile the check away due to
optimization. I think there have been similar changes to GCC recently with
respect to pointer arithmetic [1] i.e., checks relying on wrap around just
disappear. There's also a related discussion regarding integer overflows on
the GCC mailing list:

http://gcc.gnu.org/ml/gcc/2007-01/msg00057.html

Dunno where the thread actually starts.


[1] http://www.securityfocus.com/archive/1/431184/30/0/threaded

-- 
Christian