[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: apr_off_t is of an ambiguous size.

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-01-17 17:52:43 CET

On Sat, 2004-01-17 at 03:11, Ben Reser wrote:
> On Sat, Jan 17, 2004 at 12:07:19AM -0500, Greg Hudson wrote:
> > If we're going to rely on common signed overflow behavior,
> > "if ((apr_off_t) *offset == *offset)" would appear to be
> > simpler.

> I'd say the comparision test looks brilliant. My only concern is will a
> compiler optimize it out?

No, the standard is pretty clear that the compiler is not allowed to
optimize out operations that could result in an overflow. Otherwise
optimized code would produce different results than unoptimized code
with much greater regularity than it does currently, leading to tons of
debugging headaches.

mbk wrote:
> It would take a very smart compiler. Regardless: this is a single
> compare and branch; it's not the end of the world.

The question is not "will the compiler do this as quickly as we'd like?"
but "will the compiler do this *too* quickly, and produce a false
positive when *offset won't fit in an apr_off_t?"

Russell Yanofsky wrote:
> Well, I did ask whether it was ok to assume 2's complement

Even if you could assume two's complement, you can't assume that the
environment won't raise a signal on signed integer overflow. (Not that
I've ever heard of an environment which does.)

> Which reminds me, Ben, that you didn't answer my question at the
> bottom of that post. The one about whether the *apr_offset value
> can be manipulated.

apr_file_seek does modify the offset value, so yes, we need to stuff it
back into *offset after the call completes.

> I'm curious about something else. Does the standard allows just
> these three representations, or does it allow any representation?
> If it allows just those three, then in theory you could write a
> big ass conditional expression that works everywhere.

Just those three. I'm not sure if you can determine which you have
without risking an overflow, though.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 17 17:53:27 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.