in standard C it is impossible to write a correct program. Why?
io_x
of ints and unsignged ints
Richard Heathfield
> there is no standard way for find overflow
> of ints and unsignged ints
Unsigned integer types /can't/ overflow - guaranteed.
For signed integer types, it /is/ possible to find out whether an
operation would overflow. For example, consider adding x and y:
#include <limits.h>
int addition_would_overflow(int x, int y)
{
return (x > 0 && y > 0 && INT_MAX - x < y) ||
(x < 0 && y < 0 && INT_MIN - x > y);
}
Bugs?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Gordon Burditt
>Re: in standard C it is impossible to write a correct program. Why?
It is possible to write a correct program. Among other possibilities,
don't use ints. The infamous "hello, world" program doesn't.
Also, not all uses of ints can overflow, for example:
int i;
for (i = 0; i < 10; i++) {
use, but don't change i here;
}
>there is no standard way for find overflow
>of ints and unsignged ints
Arithmetic on unsigned ints does not cause undefined behavior.
You can test for going out of range like this:
unsigned int a, b, c;
c = a + b;
if (c < a || c < b) { ... you went out of range ... ; }
Wolfgang Draxinger
> there is no standard way for find overflow
> of ints and unsignged ints
Please read this article on how to catch integer overflow in pure C:
Eric Sosman
The two halves of the test always have the same truth value,
so you can jettison one of them.
Eric Sosman
> In <4a9d623d$0$40007$4faf...@reader3.news.tin.it>, io_x wrote:
>
>> there is no standard way for find overflow
>> of ints and unsignged ints
>
> Unsigned integer types /can't/ overflow - guaranteed.
>
> For signed integer types, it /is/ possible to find out whether an
> operation would overflow. For example, consider adding x and y:
>
> #include <limits.h>
>
> int addition_would_overflow(int x, int y)
> {
> return (x > 0 && y > 0 && INT_MAX - x < y) ||
> (x < 0 && y < 0 && INT_MIN - x > y);
> }
>
> Bugs?
None seen. You could drop the y>0 and y<0 tests, though.
jacob navia
> there is no standard way for find overflow
> of ints and unsignged ints
>
>
You are right, this is a hole in the language.
I proposed adding a standard way of detecting overflow in the discussion
group comp.std.c. After many people said a lot of nonsense nothing
happened. There is no work being done in this direction either as far
as I can see.
In my compiler system lcc-win I added an intrinsic function
int _overflow(void);
that will return 1 if the overflow flag is set, zero otherwise. This
allows you to catch overflow in certain situations.
Or, you can also pass to the lcc-win compiler a -checkoverflow compile
time option that will set the compiler to emit code to catch overflow
at each operation that can overflow. (Signed integers)
You can download the lcc-win compiler from
Nobody
> In my compiler system lcc-win I added an intrinsic function
>
> int _overflow(void);
>
> that will return 1 if the overflow flag is set, zero otherwise. This
> allows you to catch overflow in certain situations.
A function prototype on its own is meaningless. And a function documented
as returning the "current" state of the overflow flag is useless unless
you provide *complete* operational semantics.
Richard Heathfield
> io_x a �crit :
>> there is no standard way for find overflow
>> of ints and unsignged ints
>>
>>
>
> You are right,
No, he's wrong. It is possible to determine whether an operation will
overflow, using standard C alone. See elsethread.
<software advertisement snipped>
Bart
> In <h7jucd$3t...@aioe.org>, jacob navia wrote:
>
> > io_x a écrit :
> >> there is no standard way for find overflow
> >> of ints and unsignged ints
>
> > You are right,
>
> No, he's wrong. It is possible to determine whether an operation will
> overflow, using standard C alone. See elsethread.
It's probably also possible to do integer addition in standard C
without using "+" or "-". However it is nice to have the intrinsic "+"
available, and it's likely to be much quicker and therefore more
practical.
I would say your 14-term expression (plus extra overheads if the x,y
operands are not simple) is not too practical compared with the
suggested feature.
--
Bartc
Richard Heathfield
<3f3ebcf1-ebfd-4bbb...@o13g2000vbl.googlegroups.com>,
Bart wrote:
> On Sep 1, 11:00 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In <h7jucd$3t...@aioe.org>, jacob navia wrote:
>>
>> > io_x a �crit :
>> >> there is no standard way for find overflow
>> >> of ints and unsignged ints
>>
>> > You are right,
>>
>> No, he's wrong. It is possible to determine whether an operation
>> will overflow, using standard C alone. See elsethread.
>
> It's probably also possible to do integer addition in standard C
> without using "+" or "-". However it is nice to have the intrinsic
> "+" available, and it's likely to be much quicker and therefore more
> practical.
>
> I would say your 14-term expression (plus extra overheads if the x,y
> operands are not simple) is not too practical compared with the
> suggested feature.
The claim was that there is no standard way to do this. I have
demonstrated that this is not so. The suggested feature is fine by
me, just as soon as you can get it implemented in all the compilers
out there.
Alan Curry
Questions with non-obvious answers include:
Is overflow a sticky condition? (Once set, does it remain set until cleared,
or does it only reflect the result of the most recent operation?)
Which operations can set the overflow flag? Integer addition obviously.
Probably multiplication. Division, bit shifts, floating point?
int safe_quadruple(int x)
{
int result = x * 4;
if(_overflow()) abort();
return result;
}
Does the safeness of this function depend on whether the optimizer replaces
x*4 with x<<2? (I looked in an old Intel manual and saw that multi-bit
shifts leave an undefined value in the overflow flag.)
What about pointer arithmetic?
int x=INT_MAX-1, y=INT_MAX-1, i=0, a[100];
a[i] = x + y;
if(_overflow()) abort();
Did I check for the overflow of x+y, or did I check for overflow of the
address calculation a+i that the compiler had to do to decide where to store
the result? If I checked for overflow of the pointer arithmetic, was it smart
enough to know that i>=100 causes an "overflow" of the array, or is it just
looking for whether the pointer value wrapped around 0xFFFFFFFF?
Order of operations in general seems to be a problem. Do these have the same
effect on the overflow flag? If not, which one of the last 2 matches the 1st?
x + y + z
x + (y + z)
(x + y) + z
--
Alan Curry
Eric Sosman
I think I'd call it "impure C," because its techniques
rest on a lot of non-portable assumptions (some stated, some
not). "Practical C" might be a better characterization.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Bart
> In article <pan.2009.09.01.21.57.55.750...@nowhere.com>,
>
> Nobody <nob...@nowhere.com> wrote:
> >On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>
> >> In my compiler system lcc-win I added an intrinsic function
>
> >> int _overflow(void);
>
> >> that will return 1 if the overflow flag is set, zero otherwise. This
> >> allows you to catch overflow in certain situations.
>
> >A function prototype on its own is meaningless. And a function documented
> >as returning the "current" state of the overflow flag is useless unless
> >you provide *complete* operational semantics.
>
> Questions with non-obvious answers include:
> Is overflow a sticky condition? (Once set, does it remain set until cleared,
> or does it only reflect the result of the most recent operation?)
You're being very picky! I'd guess the overflow function just gives
you the current overflow flag state, obviously if you have an
expression with many operations each of which can set the flag, then
it's not going to draw you a diagram of where it overflowed! And it's
not going to do array bound checking! (Which would be too late by then
anyway.)
"...in certain situiations.." was specified, which means you do your
operations one at a time.
One point I might agree with is with x*4 optimised to a shift. I
wouldn't have thought overflow was associated with a shift. For this
to work properly, you might need special 'overflow-checking-aware'
versions of all the relevant operators, which cannot be optimised out.
For generally trapping overflow conditions without manually checking
each operation, I think there was a compiler option offered.
> Probably multiplication. Division, bit shifts, floating point?
I'd say add, subtract, and probably multiply. Don't know about divide
(how could you overflow in that case?).
Bit shifts: unlikely, as we are talking about a collection of bits
which need not represent a number, and usually they shift out into the
Carry flag, which might also be worth making available. Carry I
believe can detect overflow of unsigned numbers (only for those who
believe that such numbers can overflow).
> a[i] = x + y;
> if(_overflow()) abort();
> Did I check for the overflow of x+y, or did I check for overflow of the
> address calculation a+i that the compiler had to do to decide where to store
I think we're talking about signed integer overflow, address ops would
be unsigned, and may not even set normal flags in the CPU.
Bart
[got posted prematurely; perhaps the touchpad playing up]
I think you're asking a bit much here, an address calculation these
days can involve a multiply and a couple of adds at least, do you
really want that much control for something which may not even be
signed arithmetic?
--
Bartc
Keith Thompson
> On Sep 2, 12:27 am, pac...@kosh.dhis.org (Alan Curry) wrote:
>> In article <pan.2009.09.01.21.57.55.750...@nowhere.com>,
>> Nobody <nob...@nowhere.com> wrote:
>> >On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>>
>> >> In my compiler system lcc-win I added an intrinsic function
>>
>> >> int _overflow(void);
>>
>> >> that will return 1 if the overflow flag is set, zero otherwise. This
>> >> allows you to catch overflow in certain situations.
>>
>> >A function prototype on its own is meaningless. And a function documented
>> >as returning the "current" state of the overflow flag is useless unless
>> >you provide *complete* operational semantics.
>>
>> Questions with non-obvious answers include:
>
>> Is overflow a sticky condition? (Once set, does it remain set until cleared,
>> or does it only reflect the result of the most recent operation?)
>
> You're being very picky!
Of course. Such pickiness is vital when we're talking about adding a
feature to the language. It needs to be rigorously defined; if some
aspects are unspecified, it needs to say exactly what those aspects
are, specify the range of allowed behaviors. Otherwise it's nearly
impossible to write software that depends on the feature.
> I'd guess the overflow function just gives
> you the current overflow flag state, obviously if you have an
> expression with many operations each of which can set the flag, then
> it's not going to draw you a diagram of where it overflowed! And it's
> not going to do array bound checking! (Which would be too late by then
> anyway.)
You're assuming that the CPU has an "overflow flag". Not all CPUs do.
> "...in certain situiations.." was specified, which means you do your
> operations one at a time.
>
> One point I might agree with is with x*4 optimised to a shift. I
> wouldn't have thought overflow was associated with a shift. For this
> to work properly, you might need special 'overflow-checking-aware'
> versions of all the relevant operators, which cannot be optimised out.
>
> For generally trapping overflow conditions without manually checking
> each operation, I think there was a compiler option offered.
>
>> Probably multiplication. Division, bit shifts, floating point?
>
> I'd say add, subtract, and probably multiply. Don't know about divide
> (how could you overflow in that case?).
INT_MIN/(-1) overflows on two's-complement systems.
> Bit shifts: unlikely, as we are talking about a collection of bits
> which need not represent a number, and usually they shift out into the
> Carry flag, which might also be worth making available. Carry I
> believe can detect overflow of unsigned numbers (only for those who
> believe that such numbers can overflow).
And you're assuming there's a "carry flag". The definition for a
language feature can't assume an x86-like target.
>> a[i] = x + y;
>> if(_overflow()) abort();
>> Did I check for the overflow of x+y, or did I check for overflow of
>> the address calculation a+i that the compiler had to do to decide
>> where to store
>
> I think we're talking about signed integer overflow, address ops
> would be unsigned, and may not even set normal flags in the CPU.
What if signed and unsigned addition are implemented using the same
instruction, with unsigned addition just ignoring overflow? How does
_overflow() detect whether the previous operation was signed or
unsigned (presumably if it was unsigned it should return false)?
[snip]
I'm not saying it's a bad idea, just that there are a *lot* of details
to be worked out before it can become part of the language standard.
And I personally think that an _overflow() function isn't the best way
to accomplish the goal.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Bart
If a feature called "overflow()" is available, you can assume that an
overflow flag of some sort is maintained.
>
> > "...in certain situiations.." was specified, which means you do your
> > operations one at a time.
>
> > One point I might agree with is with x*4 optimised to a shift. I
> > wouldn't have thought overflow was associated with a shift. For this
> > to work properly, you might need special 'overflow-checking-aware'
> > versions of all the relevant operators, which cannot be optimised out.
>
> > For generally trapping overflow conditions without manually checking
> > each operation, I think there was a compiler option offered.
>
> >> Probably multiplication. Division, bit shifts, floating point?
>
> > I'd say add, subtract, and probably multiply. Don't know about divide
> > (how could you overflow in that case?).
>
> INT_MIN/(-1) overflows on two's-complement systems.
OK, a corner case (wouldn't it be easier to just add 1 to all these
INT_MINs?)
> > Bit shifts: unlikely, as we are talking about a collection of bits
> > which need not represent a number, and usually they shift out into the
> > Carry flag, which might also be worth making available. Carry I
> > believe can detect overflow of unsigned numbers (only for those who
> > believe that such numbers can overflow).
>
> And you're assuming there's a "carry flag". The definition for a
> language feature can't assume an x86-like target.
It would be a very poor CPU without a carry flag. In fact a carry flag
detect is what I'd prefer, rather than an overflow flag.
>
> >> a[i] = x + y;
> >> if(_overflow()) abort();
> >> Did I check for the overflow of x+y, or did I check for overflow of
> >> the address calculation a+i that the compiler had to do to decide
> >> where to store
>
> > I think we're talking about signed integer overflow, address ops
> > would be unsigned, and may not even set normal flags in the CPU.
>
> What if signed and unsigned addition are implemented using the same
> instruction, with unsigned addition just ignoring overflow? How does
> _overflow() detect whether the previous operation was signed or
> unsigned (presumably if it was unsigned it should return false)?
Well, addition usually *is* done with one instruction. The compiler
will know (if the CPU doesn't) whether the operation was signed or
unsigned and look at the appropriate flags. In the case of overflow()
function, the programmer will need to use it after an signed
operation.
> I'm not saying it's a bad idea, just that there are a *lot* of details
> to be worked out before it can become part of the language standard.
> And I personally think that an _overflow() function isn't the best way
> to accomplish the goal.
I don't think it should be part of the language either, but it makes a
useful extension (especially carry() instead of overflow(), which is
not so interesting).
To be part of the language I think may require an alternate set of
arithmetic operators which I may have hinted at (or an alternate set
of int types); that won't make it popular.
--
Bartc
Richard Heathfield
<47ce435a-b764-492a...@l34g2000vba.googlegroups.com>,
Bart wrote:
<snip>
> If a feature called "overflow()" is available, you can assume that
> an overflow flag of some sort is maintained.
In which case, what are ISO supposed to do? Add it compulsorily,
making it impossible for some platforms to have conforming
implementations? Or allow its addition optionally (i.e. pretty much
as now, except that its effect if provided would be standardised),
and have some platforms that lack it? Either way, portability is
affected.
Phil Carmody
It morphs...
In too many killfiles, Jacob?
Loosening my pattern...
Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
io_x
"Gordon Burditt" <gordon...@burditt.org> ha scritto nel messaggio
news:ta6dnXBtUu-36ADX...@posted.internetamerica...
>
>>Re: in standard C it is impossible to write a correct program. Why?
>
>>of ints and unsignged ints
>
> Arithmetic on unsigned ints does not cause undefined behavior.
> You can test for going out of range like this:
> unsigned int a, b, c;
>
> c = a + b;
> if (c < a || c < b) { ... you went out of range ... ; }
so for use one cpu instruction you use 10x instructions?
io_x
"Alan Curry" <pac...@kosh.dhis.org> ha scritto nel messaggio
news:h7kake$glj$1...@aioe.org...
> In article <pan.2009.09.01....@nowhere.com>,
> Nobody <nob...@nowhere.com> wrote:
>>On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>>
>>> In my compiler system lcc-win I added an intrinsic function
>>>
>>> int _overflow(void);
>>>
>>> that will return 1 if the overflow flag is set, zero otherwise. This
>>> allows you to catch overflow in certain situations.
>>
>>A function prototype on its own is meaningless. And a function documented
>>as returning the "current" state of the overflow flag is useless unless
>>you provide *complete* operational semantics.
>>
>
> Questions with non-obvious answers include:
>
> Is overflow a sticky condition? (Once set, does it remain set until cleared,
> or does it only reflect the result of the most recent operation?)
>
> Which operations can set the overflow flag? Integer addition obviously.
> Probably multiplication. Division, bit shifts, floating point?
> int safe_quadruple(int x)
> {
> int result = x * 4;
> if(_overflow()) abort();
> return result;
> }
> Does the safeness of this function depend on whether the optimizer replaces
> x*4 with x<<2? (I looked in an old Intel manual and saw that multi-bit
> shifts leave an undefined value in the overflow flag.)
>
> What about pointer arithmetic?
> int x=INT_MAX-1, y=INT_MAX-1, i=0, a[100];
> a[i] = x + y;
means that there is not overflow in "a+i" and in "x+y"
overflowVar=0;
z=x+y;
if(overflowVar!=0) abort();
a[i]=z;
is ok if x+y not overflow
> if(_overflow()) abort();
> Did I check for the overflow of x+y, or did I check for overflow of the
> address calculation a+i that the compiler had to do to decide where to store
that address can not overflow, if overflow there is something wrost that the
overflow of x+z because it mean that the "a array" has the address 0
and address 0 seems to me a special address for C
at last seems to me that
> the result? If I checked for overflow of the pointer arithmetic, was it smart
> enough to know that i>=100 causes an "overflow" of the array, or is it just
> looking for whether the pointer value wrapped around 0xFFFFFFFF?
>
> Order of operations in general seems to be a problem. Do these have the same
> effect on the overflow flag? If not, which one of the last 2 matches the 1st?
> x + y + z
> x + (y + z)
> (x + y) + z
they set all the overflow flag to 1 (if there is some overflow somewhere)
> --
> Alan Curry
Phil Carmody
On my DEC Alpha there is no overflow flag. There can be no universally
true semantics.
jacob navia
> Nobody <nob...@nowhere.com> writes:
>> On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>>
>>> In my compiler system lcc-win I added an intrinsic function
>>>
>>> int _overflow(void);
>>>
>>> that will return 1 if the overflow flag is set, zero otherwise. This
>>> allows you to catch overflow in certain situations.
>> A function prototype on its own is meaningless. And a function documented
>> as returning the "current" state of the overflow flag is useless unless
>> you provide *complete* operational semantics.
>
> On my DEC Alpha there is no overflow flag. There can be no universally
> true semantics.
>
> Phil
Incredible how many lies this regulars can tell here, as we would be
all stupid.
DEC Alpha assembler manual page 23 (in the pdf file)
"Overflow exceptions occur when arithmetic operations compute signed
values and the destination lacks the precision to store the result"
Page 48 lists the assembler operations and we have:
...
Add longword (with overflow): addlv
Multiply longword (with overflow) mullv
etc.
Of course the regulars lie in such a manner that when somebody notice
their lies, they have a way out.
Mr Carmody will tell now that "he just spoke about the overflow flag"
Obviously the overflow flag is integrated into the instructions that
is the only change. It would be TRIVIAL to setup an exception handler
that sets a software overflow flag and returns the result.
This same kind of lies were in the discussion of comp.std.c. At the end
there wasn't a single example of a processor where the overflow
detection could not be implemented.
Here we start again.
jacob navia
> The claim was that there is no standard way to do this.
And that claim holds. Or you are arguing that YOUR way is the standard
one?
Since practical considerations are not of interest to you, you can spare
us your stupid remarks... Go on, detect overflow like that.
> I have
> demonstrated that this is not so.
No.
> The suggested feature is fine by
> me,
Sure. Then keep it for you.
jacob navia
> jacob navia <j...@nospam.org> writes:
>
> It morphs...
> In too many killfiles, Jacob?
> Loosening my pattern...
>
> Phil
I do not understand Mr.
Are you telling me that you are unable to make a kill file?
Apparently you are since you answer to my threads.
Onbviously even a kill file is too much for you.
jacob navia
This people aren't interested in practical implementations. They
are just spewing nonsense, as they always do.
jacob navia
> On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>
>> In my compiler system lcc-win I added an intrinsic function
>>
>> int _overflow(void);
>>
>> that will return 1 if the overflow flag is set, zero otherwise. This
>> allows you to catch overflow in certain situations.
>
> A function prototype on its own is meaningless.
This will report the status of the overflow flag, i.e. the status of the
last arithmetic operation done. You can read the documentation of
lcc-win, if you like.
jacob navia
>
> You're assuming that the CPU has an "overflow flag". Not all CPUs do.
You are starting the same discussion that we did in comp.std.c. Note
that there wasn't ANY CPU where overflow could not be detected.
Care to name one where overflow detection is not supported?
Because we are speaking of overflow detection, not the implementation
I did in lcc-win.
jacob navia
>
> I don't think it should be part of the language either, but it makes a
> useful extension (especially carry() instead of overflow(), which is
> not so interesting).
>
It is possible to read the status of the floating point unit flags in
standard C.
Why would be impossible to read the status of the overflow flag?
If there is no overflow flag it can be synthetized, or a #pragma
can be added in the places where you want overflow checking done.
jacob navia
> In
> <47ce435a-b764-492a...@l34g2000vba.googlegroups.com>,
> Bart wrote:
>
> <snip>
>
>> If a feature called "overflow()" is available, you can assume that
>> an overflow flag of some sort is maintained.
>
> In which case, what are ISO supposed to do?
Allow the reading of the overflow (and other maybe) flags, as they
already do with the floating point flags!
> Add it compulsorily,
> making it impossible for some platforms to have conforming
> implementations?
There is NO platform where overflow detection is impossible.
> Or allow its addition optionally (i.e. pretty much
> as now, except that its effect if provided would be standardised),
> and have some platforms that lack it? Either way, portability is
> affected.
>
Since there is no platform where overflow is not detectable all the
above is just ignorant talk.
jacob navia
> In <h7jucd$3tb$1...@aioe.org>, jacob navia wrote:
>
>> io_x a �crit :
>>> there is no standard way for find overflow
>>> of ints and unsignged ints
>>>
>>>
>> You are right,
>
> No, he's wrong. It is possible to determine whether an operation will
> overflow, using standard C alone. See elsethread.
>
You can't read moron. He is speaking of a STANDARD way to detect
overflow.
> <software advertisement snipped>
>
Here is it again for the curious:
Gordon Burditt
>overflow flag of some sort is maintained.
At the assembly-language level, an x86-type machine maintains *TWO*
overflow flags of sort signed and unsigned. It doesn't know whether
that last add instruction represented a signed add or unsigned add,
so it's up to the compiler to generate a "branch on unsigned overflow"
or "branch on signed overflow" (even if they are not called that)
as appropriate.
Now, if overflow() checks some kind of CPU flags which might not exist
on a lot of CPUs, *WHICH* result is it checking?
For example:
int a[VEC_SIZE], b[VEC_SIZE], c[VEC_SIZE];
...
c[i] = a[i] + b[j++];
if (overflow()) { ... some kind of error condition is reported ... }
Now, *WHICH* operation is tested for overflow, and why?
- The addition of some element of a to some element of b?
- The incrementing of j?
- Calculation of the address of c[i] calculated as
&c ASM_ADD (i ASM_MULT sizeof(int))
? Since there are two math operations in there, which one is checked?
ASM_MULT might be optimized into ASM_LEFT_SHIFT. Now which value is
checked?
- The assignment of a value to c[i]? (sometimes copying a value sets the
CPU flags)
C doesn't specify much about the order of evaluation. To use overflow(),
you'd have to nail it down in excruciating detail.
>It would be a very poor CPU without a carry flag. In fact a carry flag
>detect is what I'd prefer, rather than an overflow flag.
But a carry flag doesn't detect *signed* overflow! (at least not
an x86-style carry flag).
>I don't think it should be part of the language either, but it makes a
>useful extension (especially carry() instead of overflow(), which is
>not so interesting).
It's not a useful extension unless you can describe what it does,
in excruciating detail. Defining which "operation" is the "last
one" makes a radical change to C.
>To be part of the language I think may require an alternate set of
>arithmetic operators which I may have hinted at (or an alternate set
>of int types); that won't make it popular.
Here's a proposal which probably has a lot of problems with it, but
it doesn't require nailing down the operation order so much it
prevents optimization.
The operator (it can't be an ordinary function, and has to be dealt
with specially by the compiler) overflow() takes two "arguments".
(You can change the name to avoid namespace issues.)
The first is an expression involving *one* operator (unary or
binary). The second is a pointer to a sig_atomic_t variable. The
first "argument" expression is evaluated with overflow checking on
the only operator. If there is overflow, the sig_atomic_t variable
pointed to by the second argument is set to one. If there is no
overflow, the sig_atomic_t variable is left alone, thereby allowing
its use in a whole string of operations to check if there was
overflow anywhere in the calculation. The return value of overflow()
is the value *and type* of its first argument.
I'll re-write this example:
int a[VEC_SIZE], b[VEC_SIZE], c[VEC_SIZE];
...
c[i] = a[i] + b[j++];
if (overflow()) { ... some kind of error condition is reported ... }
to, assuming the addition is the only possibility for overflow:
int a[VEC_SIZE], b[VEC_SIZE], c[VEC_SIZE];
int t1, t2
sig_atomic_t had_overflow = 0;
...
t1 = a[i];
t2 = b[j++];
c[i] = overflow(t1 + t2, &had_overflow)
if (had_overflow) { ... some kind of error condition is reported ... }
You could loosen up the restrictions on the first argument of
overflow(). It checks *all* overflows that occur in evaluating the
expression, and sets the sig_atomic_t variable if an overflow occurs
in any of them. I don't think you could get away with allowing
function calls, though, as you might end up needing 2 copies, the
overflow-checked one and the non-overflow-checked one.
I think it is reasonable that address calculations *CAN* overflow,
although don't mistake this for subscript range-checking. Remember,
though that p[-1], where p is a pointer to something, must not
overflow unless the C standard says it can produce undefined behavior,
which it doesn't in the case where p is a pointer to the middle of
an array of something.
Alan Curry
Bart <b...@freeuk.com> wrote:
>On Sep 2, 12:27�am, pac...@kosh.dhis.org (Alan Curry) wrote:
>> a[i] = x + y;
>> if(_overflow()) abort();
>> Did I check for the overflow of x+y, or did I check for overflow of the
>> address calculation a+i that the compiler had to do to decide where to store
>
>I think we're talking about signed integer overflow, address ops would
>be unsigned, and may not even set normal flags in the CPU.
I'm not aware of a processor that has separate instructions for unsigned
addition. The ones I know just have "add", which works for both signed and
unsigned using the same bits.
If you're interpreting the operands and result as unsigned, the carry flag is
meaningful and the overflow flag isn't. If you're interpeting them as signed,
it's the other way around. Both flags are touched though, since the
instruction doesn't know which interpretation you want.
>> the result? If I checked for overflow of the pointer arithmetic, was it smart
>> enough to know that i>=100 causes an "overflow" of the array, or is it just
>> looking for whether the pointer value wrapped around 0xFFFFFFFF?
Oops, I should have written 0x7FFFFFFF in the above section.
(Or 0x7FFFFFFFFFFFFFFF for 64-bit people)
--
Alan Curry
Alan Curry
Keith Thompson <ks...@mib.org> wrote:
>Bart <b...@freeuk.com> writes:
>> On Sep 2, 12:27 am, pac...@kosh.dhis.org (Alan Curry) wrote:
>>> In article <pan.2009.09.01.21.57.55.750...@nowhere.com>,
>>>
>> I'd guess the overflow function just gives
>> you the current overflow flag state, obviously if you have an
>> expression with many operations each of which can set the flag, then
>> it's not going to draw you a diagram of where it overflowed! And it's
>> not going to do array bound checking! (Which would be too late by then
>> anyway.)
>
>You're assuming that the CPU has an "overflow flag". Not all CPUs do.
So look what's happened... I tried to list some practical problems with the
use of C-level direct access to a processor overflow flag. The intent was to
show that even considering a single CPU architecture, the semantics are hard
to define, since you need to know what instructions the compiler is using and
what order it's doing calculations in.
There was a possibility that the questions I asked may have led to the
_overflow() implementor explaining how those practical problems have been
overcome (or ignored) in an actual implementation.
How'd it turn out? Only 2 followups deep, it's now a "what if there is no
overflow flag?" DS9K feud.
Well at least it still has its original stupid subject line.
--
Alan Curry
Squeamizh
> Phil Carmody a écrit :
>
>
>
> > Nobody <nob...@nowhere.com> writes:
> >> On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>
> >>> In my compiler system lcc-win I added an intrinsic function
>
> >>> int _overflow(void);
>
> >>> that will return 1 if the overflow flag is set, zero otherwise. This
> >>> allows you to catch overflow in certain situations.
> >> A function prototype on its own is meaningless. And a function documented
> >> as returning the "current" state of the overflow flag is useless unless
> >> you provide *complete* operational semantics.
>
> > On my DEC Alpha there is no overflow flag. There can be no universally
> > true semantics.
>
> > Phil
>
> Incredible how many lies this regulars can tell here, as we would be
> all stupid.
>
> DEC Alpha assembler manual page 23 (in the pdf file)
>
> "Overflow exceptions occur when arithmetic operations compute signed
> values and the destination lacks the precision to store the result"
>
> Page 48 lists the assembler operations and we have:
>
> ...
> Add longword (with overflow): addlv
> Multiply longword (with overflow) mullv
>
> etc.
>
> Of course the regulars lie in such a manner that when somebody notice
> their lies, they have a way out.
I am very interested in hearing Phil Carmody's response. I'm not
choosing sides, I don't care which of you is right--I don't even know
what a DEC Alpha is--I just want to see this exchange come to a
conclusion.
jacob navia
>
> So look what's happened... I tried to list some practical problems with the
> use of C-level direct access to a processor overflow flag.
Since C has direct access to the floating point coprocessor flags, I do
not see why it couldn't have direct access to the integer processor
flags.
I proposed TWO mechanisms:
(1) The _overflow() pseudo function that returns the state of
the overflow flag (with all its problems)
(2) A second mechanisms where the compiler generates assembly code that
calls a function if there is an overflow. This was the command line
mechanism and is much better since it will only test for overflow in
the specified operations: add, subtract, multiply and divide.
The second mechanisms eliminates all the problems associated to a
reading of the overflow flag.
> The intent was to
> show that even considering a single CPU architecture, the semantics are hard
> to define, since you need to know what instructions the compiler is using and
> what order it's doing calculations in.
>
Yes, but in many cases it can be used safely.
> There was a possibility that the questions I asked may have led to the
> _overflow() implementor explaining how those practical problems have been
> overcome (or ignored) in an actual implementation.
>
Since I provide TWO mechanisms, you have the choice:
(1) Do it yourself with the _overflow() pseudo function.
(2) Leave it to the compiler with the command line argument.
> How'd it turn out? Only 2 followups deep, it's now a "what if there is no
> overflow flag?" DS9K feud.
>
Just ignore the "regulars". They are here only to make noise.
Keith Thompson
>> You're assuming that the CPU has an "overflow flag". Not all CPUs do.
>
> If a feature called "overflow()" is available, you can assume that an
> overflow flag of some sort is maintained.
Sure, the fact that lcc-win32 has an _overflow() function makes it
likely that the x86 that it targets has an overflow flag. The point
is that if it's being proposed as an addition to the C standard, it
has to work on systems that use some other mechanism to indicate
arithmetic overflow.
[...]
>> INT_MIN/(-1) overflows on two's-complement systems.
>
> OK, a corner case (wouldn't it be easier to just add 1 to all these
> INT_MINs?)
No, I don't believe it would.
[...]
>> What if signed and unsigned addition are implemented using the same
>> instruction, with unsigned addition just ignoring overflow? How does
>> _overflow() detect whether the previous operation was signed or
>> unsigned (presumably if it was unsigned it should return false)?
>
> Well, addition usually *is* done with one instruction. The compiler
> will know (if the CPU doesn't) whether the operation was signed or
> unsigned and look at the appropriate flags. In the case of overflow()
> function, the programmer will need to use it after an signed
> operation.
if (rand() % 2 == 0) {
unsigned int x = y + z;
}
else {
int a = b + c;
}
if (_overflow()) {
...
}
Sure, it's a corner case, but this is exactly the kind of thing that
can't be ignored in a language feature.
>> I'm not saying it's a bad idea, just that there are a *lot* of details
>> to be worked out before it can become part of the language standard.
>> And I personally think that an _overflow() function isn't the best way
>> to accomplish the goal.
>
> I don't think it should be part of the language either, but it makes a
> useful extension (especially carry() instead of overflow(), which is
> not so interesting).
As a system-specific extension, I have no particular objection to it;
it's probably easy enough to implement that the bang/buck ratio is
reasonably good. But the behavior is likely to depend on the vagaries
of code generation unless you restrict its use to straightforward
cases.
> To be part of the language I think may require an alternate set of
> arithmetic operators which I may have hinted at (or an alternate set
> of int types); that won't make it popular.
Here's a thought:
bool overflowed = false;
int x = _CHECKED(overflowed, y + z);
if (overflowed) {
...
}
The idea is that _CHECKED is a macro that takes two arguments,
an lvalue that refers to a bool object, and a subexpression to be
evaluated with overflow checking. If an overflow occurs anywhere
within the expression, the bool is set to true and the resulting
value is unspecified (but not a trap representation). Otherwise,
the bool is either set to false or left alone, and the macro
invocation yields the result of the subexpression. The definition
of the macro presumably requires compiler magic.
Keith Thompson
> Phil Carmody a écrit :
No, he's saying that since you've changed the e-mail address
under which you post, he now has to update his killfile to reflect
your new address; he had previously filtered on your old address.
He's not saying a killfile is too much for him, merely that he's
inconvenienced by having to maintain it.
He's implying that you changed your e-mail address deliberately to
evade killfiles. I don't necessarily believe that.
I would suggest, however, that you choose a phony domain name
other than "nospam.org", since that's a real domain and you might
be causing its owners to receive more spam. It's common to
use a ".invalid" domain for this purpose.
Beej Jorgensen
>"Overflow exceptions occur when arithmetic operations compute signed
>values and the destination lacks the precision to store the result"
Not that I have an Alpha, but some of the stuff on this page makes it
sound like a bigger deal than with other architectures, FWIW:
http://www.cs.cmu.edu/~scandal/info/Dec.Alpha
Alpha is also unconventional in the approach to arithmetic traps. In
contrast to conventional RISC architectures, Alpha arithmetic traps
(overflow, underflow, etc.) are imprecise -- they can be delivered an
arbitrary number of instructions after the instruction that triggered
the trap, and traps from many different instructions can be reported
at once. This makes implementations that use pipelining and multiple
issue substantially easier to build.
If precise arithmetic exceptions are desired, trap barrier
instructions can be explicitly inserted in the program to force traps
to be delivered at specific points.
http://en.wikipedia.org/wiki/DEC_Alpha
The Alpha does not have condition codes for integer instructions to
remove a potential bottleneck at the condition status register.
Instructions resulting in an overflow, such as adding two numbers
whose result does not fit in 64 bits, write the 32 or 64 least
significant bits to the destination register. The carry is generated
by performing a unsigned compare on the result with either operand to
see if the result is smaller than either the operand. If the test was
true, the value one is written to the least significant bit of the
destination register to indicate the condition.
The Wikipedia entry doesn't make sense to me, but it suggests a fair
amount of work when you set the overflow-test flag in the add
instruction.
I can't locate a copy of the Alpha assembler manual online. Is there
a performance hit for using addlv?
>Obviously the overflow flag is integrated into the instructions that
>is the only change. It would be TRIVIAL to setup an exception handler
>that sets a software overflow flag and returns the result.
I defer to the Alpha guys.
-Beej
Keith Thompson
>>> On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>>>
>>>> In my compiler system lcc-win I added an intrinsic function
>>>>
>>>> int _overflow(void);
>>>>
>>>> that will return 1 if the overflow flag is set, zero otherwise. This
>>>> allows you to catch overflow in certain situations.
>>> A function prototype on its own is meaningless. And a function documented
>>> as returning the "current" state of the overflow flag is useless unless
>>> you provide *complete* operational semantics.
>>
>> On my DEC Alpha there is no overflow flag. There can be no universally
>> true semantics.
>
> all stupid.
>
> DEC Alpha assembler manual page 23 (in the pdf file)
Great, you've quoted portions of the DEC Alpha assembler manual that
confirm that the DEC Alpha has no overflow flag.
> Of course the regulars lie in such a manner that when somebody notice
> their lies, they have a way out.
That way out is called "telling the truth".
> Mr Carmody will tell now that "he just spoke about the overflow flag"
No doubt.
> Obviously the overflow flag is integrated into the instructions that
> is the only change. It would be TRIVIAL to setup an exception handler
> that sets a software overflow flag and returns the result.
Would it? You may be right, but it's not immediately obvious. If you
can define the semantics of your _overflow() function in a way that
would be suitable for inclusion in the C standard, and that would be
straightforwardly implementable on the DEC Alpha, that would help your
case.
> This same kind of lies were in the discussion of comp.std.c. At the end
> there wasn't a single example of a processor where the overflow
> detection could not be implemented.
>
> Here we start again.
*sigh*
jacob navia
> jacob navia <j...@nospam.org> wrote:
>> "Overflow exceptions occur when arithmetic operations compute signed
>> values and the destination lacks the precision to store the result"
>
> Not that I have an Alpha, but some of the stuff on this page makes it
> sound like a bigger deal than with other architectures, FWIW:
>
> http://www.cs.cmu.edu/~scandal/info/Dec.Alpha
>
> Alpha is also unconventional in the approach to arithmetic traps. In
> contrast to conventional RISC architectures, Alpha arithmetic traps
> (overflow, underflow, etc.) are imprecise -- they can be delivered an
> arbitrary number of instructions after the instruction that triggered
> the trap, and traps from many different instructions can be reported
> at once. This makes implementations that use pipelining and multiple
> issue substantially easier to build.
>
> If precise arithmetic exceptions are desired, trap barrier
> instructions can be explicitly inserted in the program to force traps
> to be delivered at specific points.
>
The solution is there. You set up an exception handler, and after each
add, subtract, etc operation you set a memory barrier.
This could be expensive. A finer control of overflow *could* be
provided if there is a #pragma that allows to set it on or off
in certain parts of the code only.
Note that if there is a performance hit, there is no way to
avoid it, since you have to decide what you want:
You want faster a wrong result?
You want slower a correct result?
It depends on your application.
For a game, nobody cares.
For a program controlling an airplane you want it
at all costs...
Richard Heathfield
> Richard Heathfield a �crit :
>> The claim was that there is no standard way to do this.
>
> And that claim holds.
No, I showed it to be false, using ISO C code.
> Or you are arguing that YOUR way is the standard one?
No, I'm saying it's /a/ standard way. Human ingenuity being what it
is, I'd be surprised if there weren't a dozen or more other ways.
>
> Since practical considerations are not of interest to you, you can
> spare us your stupid remarks... Go on, detect overflow like that.
It is precisely because of practical considerations that I seek to
avoid locking myself into one vendor's solution if that solution is
not portable to other platforms that I need to support.
>> I have
>> demonstrated that this is not so.
>
> No.
Please explain what is non-standard, or incorrect, about that
demonstration.
>
>> The suggested feature is fine by me,
>
> Sure. Then keep it for you.
Well, you suggested that we keep the suggested feature (your
_overflow()) function for *everybody*. The only problem with that is
that not all implementations support it. If you are now saying that
your _overflow() routine should not be used by anyone except me,
well, I don't have a problem with that (and no, I won't use it
either, which reduces your proposed user base to zero).
> just as soon as you can get it implemented in all the compilers
>> out there.
That was the important bit, which you appear to have missed.
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>I would suggest, however, that you choose a phony domain name
>other than "nospam.org", since that's a real domain and you might
>be causing its owners to receive more spam.
Are we supposed to imagine that someone registered the domain
"nospam.org" unaware of the fact that it was likely to be used
by thousands of people as a fake address?
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield
> Richard Heathfield a �crit :
>> In <h7jucd$3tb$1...@aioe.org>, jacob navia wrote:
>>
>>> io_x a �crit :
>>>> there is no standard way for find overflow
>>>> of ints and unsignged ints
>>>>
>>>>
>>> You are right,
>>
>> No, he's wrong. It is possible to determine whether an operation
>> will overflow, using standard C alone. See elsethread.
>>
>
> You can't read moron. He is speaking of a STANDARD way to detect
> overflow.
On this occasion I read it just fine, and I showed a STANDARD (your
caps) way to detect whether overflow would occur. If you interpreted
the statement as detecting whether overflow /has/ occurred, then
okay, fine, that's perhaps another legitimate interpretation. But
just because you read it one way, that doesn't mean other ways of
reading it are moronic.
There is a problem with your interpretation, however, insofar as any
non-standard way of detecting whether overflow /has/ occurred is not
guaranteed by the Standard to work correctly, for the simple reason
that, if overflow has indeed occurred, the program has invoked
undefined behaviour and therefore the result of any post facto check
is undefined by ISO.
>
>> <software advertisement snipped>
>>
>
> Here is it again for the curious
<software advertisement snipped again>
Beej Jorgensen
>The solution is there. You set up an exception handler, and after each
>add, subtract, etc operation you set a memory barrier.
Yeah... so I'm guessing this is about the point where the burly DEC*
Enforcers with ax handles pay ISO a visit and very politely ask them to
reconsider.
It sounds like they decided to make it faster by not maintaining a
standard overflow flag with the assumption that checking it was a
relatively rare occurrence.
>This could be expensive. A finer control of overflow *could* be
>provided if there is a #pragma that allows to set it on or off in
>certain parts of the code only.
It seems like if you were going to make this happen, you would have to
make this pragma concession. I don't know what the performance hit even
is, but that's going to be a hard sell no matter how small. DEC would
probably prefer people just roll some assembly in there when they need
to check the overflow.
That being said, I agree that the one way to go would be a #pragma STDC
directive.
-Beej
* Hewlett-Compaqard
Richard Heathfield
At present, you are the one who is spewing nonsense. The above
discussion is about unsigned integer types, which - by definition -
cannot overflow. See 3.1.2.5 of C89 or 6.2.5(9) of C99: "A
computation involving unsigned operands can never overflow". They can
*wrap*, but they cannot overflow. If your proprietary, non-standard,
non-portable overflow detector detects overflow in the case of adding
values with unsigned integer types, then it is detecting something
that cannot occur. And if it doesn't, how is it a replacement for the
above code?
Richard Heathfield
> Richard Heathfield a �crit :
>> In
>>
<47ce435a-b764-492a...@l34g2000vba.googlegroups.com>,
>> Bart wrote:
>>
>> <snip>
>>
>>> If a feature called "overflow()" is available, you can assume that
>>> an overflow flag of some sort is maintained.
>>
>> In which case, what are ISO supposed to do?
>
> Allow the reading of the overflow (and other maybe) flags, as they
> already do with the floating point flags!
The problem with that is that not all systems /have/ overflow flags.
>> Add it compulsorily,
>> making it impossible for some platforms to have conforming
>> implementations?
>
> There is NO platform where overflow detection is impossible.
Since overflow detection can be done /before/ the event, using
standard portable C, it is obviously true that there is no platform
where overflow detection is impossible.
<nonsense snipped>
Richard Heathfield
<snip>
> I would suggest, however, that you choose a phony domain name
> other than "nospam.org", since that's a real domain
Strictly speaking, it's merely a valid domain /name/. As far as I can
discover, it doesn't appear to be registered.
<snip>
Ike Naar
Richard Heathfield <r...@see.sig.invalid> wrote:
>In <lnmy5dn...@nuthaus.mib.org>, Keith Thompson wrote:
>> I would suggest, however, that you choose a phony domain name
>> other than "nospam.org", since that's a real domain
>
>Strictly speaking, it's merely a valid domain /name/. As far as I can
>discover, it doesn't appear to be registered.
$ ping nospam.org
PING nospam.org (66.116.109.97): 56 data bytes
64 bytes from 66.116.109.97: icmp_seq=0 ttl=240 time=186.189 ms
64 bytes from 66.116.109.97: icmp_seq=1 ttl=240 time=190.126 ms
64 bytes from 66.116.109.97: icmp_seq=2 ttl=240 time=190.227 ms
--- nospam.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 186.189/188.847/190.227/1.913 ms
$
Richard Heathfield
> In article <i4qdneNqZrz-qgPX...@bt.com>,
> Richard Heathfield <r...@see.sig.invalid> wrote:
>>In <lnmy5dn...@nuthaus.mib.org>, Keith Thompson wrote:
>>> I would suggest, however, that you choose a phony domain name
>>> other than "nospam.org", since that's a real domain
>>
>>Strictly speaking, it's merely a valid domain /name/. As far as I
>>can discover, it doesn't appear to be registered.
>
> $ ping nospam.org
> PING nospam.org (66.116.109.97):
Ha! I tried a browser, and I tried whois, but I didn't think of ping.
Thanks.
Ike Naar
Richard Heathfield <r...@see.sig.invalid> wrote:
>In <h7lf4e$hq3$1...@news.eternal-september.org>, Ike Naar wrote:
>
>> In article <i4qdneNqZrz-qgPX...@bt.com>,
>> Richard Heathfield <r...@see.sig.invalid> wrote:
>>>In <lnmy5dn...@nuthaus.mib.org>, Keith Thompson wrote:
>>>> I would suggest, however, that you choose a phony domain name
>>>> other than "nospam.org", since that's a real domain
>>>
>>>Strictly speaking, it's merely a valid domain /name/. As far as I
>>>can discover, it doesn't appear to be registered.
>>
>> $ ping nospam.org
>> PING nospam.org (66.116.109.97):
>
>Ha! I tried a browser, and I tried whois, but I didn't think of ping.
Your whois is broken.
$ whois nospam.org | head
Domain ID:D2765091-LROR
Domain Name:NOSPAM.ORG
Created On:18-Sep-1998 04:00:00 UTC
Last Updated On:18-Sep-2008 01:21:51 UTC
Expiration Date:17-Sep-2009 04:00:00 UTC
Sponsoring Registrar:Moniker Online Services Inc. (R145-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:MONIKER23658
Richard Heathfield
> In article <9rCdna-1MKjB3wPX...@bt.com>,
> Richard Heathfield <r...@see.sig.invalid> wrote:
>>In <h7lf4e$hq3$1...@news.eternal-september.org>, Ike Naar wrote:
>>
<snip>
>>>
>>> $ ping nospam.org
>>> PING nospam.org (66.116.109.97):
>>
>>Ha! I tried a browser, and I tried whois, but I didn't think of
>>ping.
>
> Your whois is broken.
Yup, seems that way:
me@here> whois nospam.org
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to
http://www.internic.net
for detailed information.
No match for "NOSPAM.ORG".
[...]
Bart
wrote:
> Nobody <nob...@nowhere.com> writes:
> > On Tue, 01 Sep 2009 21:58:16 +0200, jacob navia wrote:
>
> >> In my compiler system lcc-win I added an intrinsic function
>
> >> int _overflow(void);
>
> >> that will return 1 if the overflow flag is set, zero otherwise. This
> >> allows you to catch overflow in certain situations.
>
> > A function prototype on its own is meaningless. And a function documented
> > as returning the "current" state of the overflow flag is useless unless
> > you provide *complete* operational semantics.
>
> On my DEC Alpha there is no overflow flag. There can be no universally
> true semantics.
That's interesting. So if someone brought out a processor that did not
have integer addition (or some other fundamental feature), would we
have to take integer addition out of standard C?
The overflow() idea is too flawed to be part of the language (because
it's too loosely linked to any specific arithmetic op), but still I'd
imagine it can be made to work, at some cost, on the DEC Alpha.
--
Bartc
Bart
> Bart <b...@freeuk.com> writes:
> > On Sep 2, 2:53 am, Keith Thompson <ks...@mib.org> wrote:
> >> INT_MIN/(-1) overflows on two's-complement systems.
>
> > OK, a corner case (wouldn't it be easier to just add 1 to all these
> > INT_MINs?)
>
> No, I don't believe it would.
Not even in this particular case?
>
> [...]
>
> >> What if signed and unsigned addition are implemented using the same
> >> instruction, with unsigned addition just ignoring overflow? How does
> >> _overflow() detect whether the previous operation was signed or
> >> unsigned (presumably if it was unsigned it should return false)?
>
> > Well, addition usually *is* done with one instruction. The compiler
> > will know (if the CPU doesn't) whether the operation was signed or
> > unsigned and look at the appropriate flags. In the case of overflow()
> > function, the programmer will need to use it after an signed
> > operation.
>
> if (rand() % 2 == 0) {
> unsigned int x = y + z;
> }
> else {
> int a = b + c;
> }
> if (_overflow()) {
> ...
> }
>
> Sure, it's a corner case, but this is exactly the kind of thing that
> can't be ignored in a language feature.
You've put the overflow check in the wrong place; it should be
immediately after each operation. Otherwise you might as well put it
at the end of main().
> > To be part of the language I think may require an alternate set of
> > arithmetic operators which I may have hinted at (or an alternate set
> > of int types); that won't make it popular.
>
> Here's a thought:
>
> bool overflowed = false;
> int x = _CHECKED(overflowed, y + z);
> if (overflowed) {
> ...
> }
>
> The idea is that _CHECKED is a macro that takes two arguments,
> an lvalue that refers to a bool object, and a subexpression to be
> evaluated with overflow checking. If an overflow occurs anywhere
> within the expression, the bool is set to true and the resulting
> value is unspecified (but not a trap representation). Otherwise,
> the bool is either set to false or left alone, and the macro
> invocation yields the result of the subexpression. The definition
> of the macro presumably requires compiler magic.
OK, so effectively special versions of the operators. But without
exception processing, user code is going to get untidy. How about
(going outside the realms of what is practical now):
overflow();
a = b (+) c (*) d;
if (overflow())...
So overflow() indicates *any* overflow since the last overflow()
check. With (+) meant to indicate overflow-checked operations, and in
this case needs to update a software flag. And to work across
functions the flag needs to be local to each function...
--
Bartc
Eric Sosman
> Bart a �crit :
>>
>> I don't think it should be part of the language either, but it makes a
>> useful extension (especially carry() instead of overflow(), which is
>> not so interesting).
>>
>
> standard C.
The meanings of the flags are implementation-defined;
even the number of flags provided is implementation-defined.
Is there an FE_OVERFLOW flag, for instance? Maybe, maybe
not. You can use #ifdef FE_OVERFLOW to find out, but if it
says "No," then how can you read the famous floating-point
flags and detect an overflow?
> Why would be impossible to read the status of the overflow flag?
Maybe there isn't one. I recall attending a talk years
ago given by the architects of the DEC Alpha chip, and they
said they'd done away with "flags" in the architecture to
get better low-level parallelism. (Apparently, when you've
got a couple of multiple-issue pipelines cranking along at the
same time, access to "flags" and other such global shared state
causes stalls and synchronization delays.) Anyhow, the Alpha
didn't do "Compare X to Y and set the flags; now test the flags
and branch accordingly." Rather, it had "Text X>Y and put the
outcome in R6," followed by "Branch if R6 is zero."
I do not know for a fact whether Alpha had an "overflow
flag," but it certainly did without a lot of the other flags
people have grown accustomed to.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Willem
<snip>
) Anyhow, the Alpha
) didn't do "Compare X to Y and set the flags; now test the flags
) and branch accordingly." Rather, it had "Text X>Y and put the
) outcome in R6," followed by "Branch if R6 is zero."
Wouldn't it be easier to say "subtract Y from X and put the outcome in R6"
followed by "Branch if R6 is below zero" ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Noob
> Since overflow detection can be done /before/ the event, using
> standard portable C, it is obviously true that there is no platform
> where overflow detection is impossible.
Consider
int a = 12345;
int b = a * 17;
How does one test whether a * 17 will overflow?
Does one have to compute INT_MAX / 17?
Regards.
Richard Heathfield
> Richard Heathfield wrote:
>
>> Since overflow detection can be done /before/ the event, using
>> standard portable C, it is obviously true that there is no platform
>> where overflow detection is impossible.
>
> Consider
>
> int a = 12345;
> int b = a * 17;
>
> How does one test whether a * 17 will overflow?
You can start off by dividing INT_MAX by 17.
> Does one have to compute INT_MAX / 17?
It's a start.
Eric Sosman
> Eric Sosman wrote:
> <snip>
> ) Anyhow, the Alpha
> ) didn't do "Compare X to Y and set the flags; now test the flags
> ) and branch accordingly." Rather, it had "Text X>Y and put the
> ) outcome in R6," followed by "Branch if R6 is zero."
>
> Wouldn't it be easier to say "subtract Y from X and put the outcome in R6"
> followed by "Branch if R6 is below zero" ?
1) No, because the subtraction could ... wait for it ...
overflow. That's why most machines have COMPARE instructions
in addition to SUBTRACT instructions.
2) I think the Alpha had several instructions of the branch-
on-content-of-register type: Branch if zero, branch if non-zero,
branch if sign set, branch if sign clear, and probably a few
more. But they all had that same flavor: A comparison or other
test didn't deliver its result to global "flags," but to a
register specified in the instruction, and then the branch
tested what was in the register.
--
Eric Sosman
eso...@ieee-dot-org.invalid
James Kuyper
>> On my DEC Alpha there is no overflow flag. There can be no universally
>> true semantics.
>
> That's interesting. So if someone brought out a processor that did not
> have integer addition (or some other fundamental feature), would we
> have to take integer addition out of standard C?
If they had a good reason to do so, that reason should be taken into
consideration. One of the primary design goals for C was to be as widely
implementable as possible; that must be balanced against other goals. If
a decent low-level general purpose programming language could be
efficiently implemented on a processor which lacked support for integer
addition (though I can't imagine how that could be possible), C should
be such a language.
C has existed for more than 30 years without any direct access to the
overflow flag; I think we can safely presume that it's not essential to
provide such access. It's possible to created a decent general purpose
language on the DEC Alpha, despite it's lack of an overflow flag - this
strongly argues against your implication that an overflow flag is as
fundamental a feature as integer addition.
Note that I am not asserting that C should only provide support for
absolutely essential compiler features. I'm only arguing against your
assertion that it's unnecessary to take into consideration the existence
of platforms where there is none.
Eric Sosman
> [...]
> The overflow() idea is too flawed to be part of the language (because
> it's too loosely linked to any specific arithmetic op), but still I'd
> imagine it can be made to work, at some cost, on the DEC Alpha.
If overflow() is just "read the value of some flag or
other, possibly simulated," then I think we all agree it's
useless. You've got to know what sets the flag, and you've
got to know what clears it -- if you don't know, then you
can't make sense of what overflow() tells you.
One of the earliest machines I worked on had no overflow
flag at all. It had two modes of dealing with overflow: Either
it ignored the overflow and wrapped silently in two's complement,
or it trapped and you got the equivalent of a signal.
Unfortunately, the mode was governed by a bit in the "Program
Status Word," which was sort of clumsy to be changing all the
time as one wandered between signed and unsigned semantics. So
people usually just left it in the "ignore" mode and took their
chances. If the mode had been more easily selectable -- by using
ADD and ADDUNSIGNED opcodes, say, for add-with-trap and add-with-
ignore -- I wonder whether similar schemes might have shown up
on other machines and become "mainstream," leading (perhaps) to
safer programming practice.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Dik T. Winter
...
> In my compiler system lcc-win I added an intrinsic function
>
> int _overflow(void);
>
> that will return 1 if the overflow flag is set, zero otherwise. This
> allows you to catch overflow in certain situations.
And what if the processor does not have an overflow flag?
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
jacob navia
>
> C has existed for more than 30 years without any direct access to the
> overflow flag; I think we can safely presume that it's not essential to
> provide such access.
The problem of the future is that it has to be compatible with the bugs
of the past;
C existed for 10 years without prototypes but it was a great improvement
when they appeared.
Program correctness is more important now than speed at all costs,
even at the cost of getting WRONG RESULTS!
In the implementation of lcc-win, the speed penaltiy paid by a program
that checks overflow at each operation is less than 4%.
And I haven't optimized my implementation since instead of a jump with
no overflow to the continuation of the program, I could generate a
jump if overflow, what would eliminate the costs almost entirely.
The code generation is more complicated since for each operation you
have to construct a special label and special code, but it is not very
difficult to do.
Note that the difficulty stems from the fact that lcc-win reports the
source line number and the file name where the overflow happened.
Contrary to "gnu" gcc that just aborts without any warning, not even
telling you there was an overflow.
> It's possible to created a decent general purpose
> language on the DEC Alpha, despite it's lack of an overflow flag - this
> strongly argues against your implication that an overflow flag is as
> fundamental a feature as integer addition.
>
You are showing us only your ignorance. The DEC alpha has no
flags but instructions that trap if overflow happens, what is the same
and allows you to catch all overflows!
> Note that I am not asserting that C should only provide support for
> absolutely essential compiler features. I'm only arguing against your
> assertion that it's unnecessary to take into consideration the existence
> of platforms where there is none.
THERE IS NO COMPUTER WHERE OVERFLOW DETECTION IS IMPOSSIBLE.
Did you understand that? I do not know how many times should I repeat
it.
jacob navia
> In article <h7jucd$3tb$1...@aioe.org> jacob navia <j...@nospam.org> writes:
> ...
> > In my compiler system lcc-win I added an intrinsic function
> >
> > int _overflow(void);
> >
> > that will return 1 if the overflow flag is set, zero otherwise. This
> > allows you to catch overflow in certain situations.
>
> And what if the processor does not have an overflow flag?
Overflow detection can be simulated using corresponding operations
that trap if the overflow was detected.
For instance the DEC alpha has special instructions that trap if an addition
overflows, subtraction, multiplication, etc.
Dik T. Winter
...
> You're being very picky! I'd guess the overflow function just gives
> you the current overflow flag state,
Obviously this is only possible if the processor *does* have an overflow
flag for integer operations. I have worked with too many processors to
know that that is not at all certain.
> I'd say add, subtract, and probably multiply. Don't know about divide
> (how could you overflow in that case?).
MIN_INT/(-1) can overflow if the range is asymmetric.
jacob navia
> In <h7lpon$tl9$1...@aioe.org>, Noob wrote:
>
>> Richard Heathfield wrote:
>>
>>> Since overflow detection can be done /before/ the event, using
>>> standard portable C, it is obviously true that there is no platform
>>> where overflow detection is impossible.
>> Consider
>>
>> int a = 12345;
>> int b = a * 17;
>>
>> How does one test whether a * 17 will overflow?
>
> You can start off by dividing INT_MAX by 17.
>
>> Does one have to compute INT_MAX / 17?
>
> It's a start.
>
Of course performance considerations are not a problem for you.
The fact that each multiplication now implies a division doesn't
bother you at all.
jacob navia
> ...
> > You're being very picky! I'd guess the overflow function just gives
> > you the current overflow flag state,
>
> Obviously this is only possible if the processor *does* have an overflow
> flag for integer operations. I have worked with too many processors to
> know that that is not at all certain.
>
There is NO PROCESSOR TODAY where overflow detection is not possible.
Ben Bacarisse
> Willem wrote:
>> Eric Sosman wrote:
>> <snip>
>> ) Anyhow, the Alpha
>> ) didn't do "Compare X to Y and set the flags; now test the flags
>> ) and branch accordingly." Rather, it had "Text X>Y and put the
>> ) outcome in R6," followed by "Branch if R6 is zero."
>>
>> Wouldn't it be easier to say "subtract Y from X and put the outcome in R6"
>> followed by "Branch if R6 is below zero" ?
>
> 1) No, because the subtraction could ... wait for it ...
> overflow. That's why most machines have COMPARE instructions
> in addition to SUBTRACT instructions.
Historical note: If I remember correctly, the Data General Nova did
not have compare instructions (i.e. is lies outside your "most").
It had subtract (and so on) with a "no load" flag in the order that
prevented the result from being stored. The "skip control" part of
the order than branched (by skipping one instruction) depending of the
value of various condition flags such as "result less that zero".
<snip>
--
Ben.
Dik T. Winter
> Keith Thompson a écrit :
> >
> > You're assuming that the CPU has an "overflow flag". Not all CPUs do.
>
> You are starting the same discussion that we did in comp.std.c. Note
> that there wasn't ANY CPU where overflow could not be detected.
No, you were writing about an overflow flag.
Dik T. Winter
> Phil Carmody a �crit :
...
> > On my DEC Alpha there is no overflow flag. There can be no universally
> > true semantics.
> Incredible how many lies this regulars can tell here, as we would be
> all stupid.
Alas, it is *not* a lie.
> DEC Alpha assembler manual page 23 (in the pdf file)
>
> "Overflow exceptions occur when arithmetic operations compute signed
> values and the destination lacks the precision to store the result"
>
> Page 48 lists the assembler operations and we have:
>
> ...
> Add longword (with overflow): addlv
> Multiply longword (with overflow) mullv
Yes, where is the overflow flag?
> Of course the regulars lie in such a manner that when somebody notice
> their lies, they have a way out.
What is the lie? That there is not an overflow flag? Is that a lie? Where
in that case in the assembler manual is the overflow flag documented?
> Mr Carmody will tell now that "he just spoke about the overflow flag"
Obviously, because that is a fact.
> Obviously the overflow flag is integrated into the instructions that
> is the only change.
No, there is *no* overflow flag. On the DEC you can indeed simulate it,
but it is not present in hardware.
> This same kind of lies were in the discussion of comp.std.c. At the end
> there wasn't a single example of a processor where the overflow
> detection could not be implemented.
Overflow detection can be implemented on every processor, see the code
by Richard Heathfield that detects it before the fact. So a compiler
could reasonably use that sequence of instructions for every signed
addition and set the overflow flag accordingly.
jacob navia
> > Keith Thompson a écrit :
> > >
> > > You're assuming that the CPU has an "overflow flag". Not all CPUs do.
> >
> > You are starting the same discussion that we did in comp.std.c. Note
> > that there wasn't ANY CPU where overflow could not be detected.
>
> No, you were writing about an overflow flag.
You did not read my article. You read what this Mr Thompson understood
from my article.
Please read my article and then you will see that I proposed TWO solutions:
(1) Quick and dirty: Access the overflow flag using the pseudo function
_overflow()
(2) Using a compile time flag tell the compiler to checkfor overflow.
The compiler will call a function (that you can write) telling you
that an overflow occurre at some line in some file.c.
Since Thompson can't read well, he did not read all my message and you
are assuming that what he says is true... a bad idea.
Eric Sosman
>> On my DEC Alpha there is no overflow flag. There can be no universally
>> true semantics.
>
> That's interesting. So if someone brought out a processor that did not
> have integer addition (or some other fundamental feature), would we
> have to take integer addition out of standard C?
As it happens, the very first "real" computer I wrote code for
was very nearly as you describe: It couldn't do addition unaided.
There was a ten-by-ten addition table (this was a decimal machine)
hard-wired at a fixed location in core (actual core), and the CPU's
circuitry consulted it whenever it needed to add a pair of digits.
IBM 1620, nicknamed CADET for "Can't Add, Doesn't Even Try."
When I visited the Computer History Museum a few years ago, they
were engaged in trying to restore one to working condition. A big
stumbling block was that the memory had rotted away and IBM said
"We have forgotten how to make this stuff." So they were going to
simulate the core memory with modern parts and see if they could get
the rest of it going.
But back to the thread: You're asking the wrong question. It's not
"Should features be removed from C because they're not implementable on
the Etch A Sketch?" but "What features could be added to C that would
make it more useful without unduly limiting its portability?" It's my
belief that C would indeed be a better language if it had reliable
semantics on overflow and a detection mechanism that operated on a
useful level -- but "Just read the CPU's flag" is a non-starter, for
at least three different reasons already mentioned in this thread.
Richard Heathfield
<snip>
> Of course performance considerations are not a problem for you.
It depends. Sometimes performance is more important than portability,
and sometimes it isn't.
> The fact that each multiplication now implies a division doesn't
> bother you at all.
What makes you think so? The subject of discussion is not "can
overflow be detected quickly in C, if we allow extensions?" but "is
overflow detection in standard C possible?". There are two important
distinctions between the two questions.
Keith Thompson
> In article <lnzl9em...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
[...]
>>You're assuming that the CPU has an "overflow flag". Not all CPUs do.
>
> use of C-level direct access to a processor overflow flag. The intent was to
> show that even considering a single CPU architecture, the semantics are hard
> to define, since you need to know what instructions the compiler is using and
> what order it's doing calculations in.
>
> There was a possibility that the questions I asked may have led to the
> _overflow() implementor explaining how those practical problems have been
> overcome (or ignored) in an actual implementation.
>
> How'd it turn out? Only 2 followups deep, it's now a "what if there is no
> overflow flag?" DS9K feud.
>
> Well at least it still has its original stupid subject line.
Are you comparing the Alpha processor to the DS9K?
Yes, there may be ways to implement _overflow() on the Alpha, but it's
not as simple as "_overflow() returns the value of the overflow flag".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
> pac...@kosh.dhis.org (Alan Curry) writes:
>> In article <lnzl9em...@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
> [...]
>>> You're assuming that the CPU has an "overflow flag". Not all CPUs do.
>> So look what's happened... I tried to list some practical problems with the
>> use of C-level direct access to a processor overflow flag. The intent was to
>> show that even considering a single CPU architecture, the semantics are hard
>> to define, since you need to know what instructions the compiler is using and
>> what order it's doing calculations in.
>>
>> There was a possibility that the questions I asked may have led to the
>> _overflow() implementor explaining how those practical problems have been
>> overcome (or ignored) in an actual implementation.
>>
>> How'd it turn out? Only 2 followups deep, it's now a "what if there is no
>> overflow flag?" DS9K feud.
>>
>> Well at least it still has its original stupid subject line.
>
> Are you comparing the Alpha processor to the DS9K?
>
> Yes, there may be ways to implement _overflow() on the Alpha, but it's
> not as simple as "_overflow() returns the value of the overflow flag".
>
And who is proposing that?
Not me iun any case. Can you say who proposed such a thing?
Ahh nobody!
OK
Tom St Denis
> Richard Heathfield a écrit :
As someone who wrote a performance math library I just made the
assumption of twos complement logic and did this
if (expr < input) overflow_occurred();
E.g.
if (a*b < a || a*b < b) ...
No division, it's not 100% portable, but practically speaking it's
bound to work everywhere today.
Tom
jacob navia
> But back to the thread: You're asking the wrong question. It's not
> "Should features be removed from C because they're not implementable on
> the Etch A Sketch?" but "What features could be added to C that would
> make it more useful without unduly limiting its portability?" It's my
> belief that C would indeed be a better language if it had reliable
> semantics on overflow and a detection mechanism that operated on a
> useful level -- but "Just read the CPU's flag" is a non-starter, for
> at least three different reasons already mentioned in this thread.
>
I proposed TWO solutions. SInce regulars can't read well apparently
here is the second solution again for people like you:
The compiler (using a compile time flag) generates code in a
not specified way that calls a function that receives the line
number and the file name where the overflow occurred.
This second solution has been ignored by people that can't read.
But I believe the human race can be improved, and (even regulars of
c.l.c) can learn to read correctly.
Keith Thompson
> Alan Curry a écrit :
>> So look what's happened... I tried to list some practical problems with the
>> use of C-level direct access to a processor overflow flag.
>
> not see why it couldn't have direct access to the integer processor
> flags.
C's access to the floating point "coprocessor"(?) flags is optional.
An implementation can indicate that it doesn't support such access
simply by not defining the FE_* macros in <fenv.h>. See C99 7.6p5.
IEC 60559 (also known as the IEEE floating-point standard) imposes
certain features, including floating-point status flags, on
implementations that support it. Since so many implementations do
support IEC 60559, it's reasonable for the C standard to include
specific support for it, while not requiring it for all
implementations so non-IEEE systems can still conform to the C
standard.
There is a widely (but not universally) supported standard for
floating-point status flags. There is no such standard for integer
status flags.
> I proposed TWO mechanisms:
>
> (1) The _overflow() pseudo function that returns the state of
> the overflow flag (with all its problems)
And I suggest that those problems are serious enough that it's not
appropriate for inclusion in the C standard, though I have no problem
with it as an implementation-specific extension.
> (2) A second mechanisms where the compiler generates assembly code that
> calls a function if there is an overflow. This was the command line
> mechanism and is much better since it will only test for overflow in
> the specified operations: add, subtract, multiply and divide.
>
> The second mechanisms eliminates all the problems associated to a
> reading of the overflow flag.
Does it allow checking for some operations within a program and not
for others? (You may already have answered this, but I don't
remember.)
[...]
jacob navia
jameskuyper
> James Kuyper a écrit :
> >
> > C has existed for more than 30 years without any direct access to the
> > overflow flag; I think we can safely presume that it's not essential to
> > provide such access.
>
> The problem of the future is that it has to be compatible with the bugs
> of the past;
>
> C existed for 10 years without prototypes but it was a great improvement
> when they appeared.
I was not arguing against the idea of providing some way of checking
for overflow. I was arguing against the idea that platforms which lack
overflow flags are so deeply flawed that it is acceptable to define
the behavior for such a feature in a way that would make it difficult,
or even impossible, to implement on such platforms. A specification
that refers directly to "the overflow flag" is impossible to implement
on such platforms, because there is no such thing. A specification for
the feature that mandates emulation of overflow flags would be less
problematic, though I suspect it would impose a serious performance
penalty on such platforms - the stated reason for dropping overflow
flags from the design of one such platform was improved performance.
> Program correctness is more important now than speed at all costs,
> even at the cost of getting WRONG RESULTS!
>
> In the implementation of lcc-win, the speed penaltiy paid by a program
> that checks overflow at each operation is less than 4%.
Have you ported lcc-win to a platform which has no overflow flags? If
so, have you tested to see what the performance penalty is on that
platform?
> > It's possible to created a decent general purpose
> > language on the DEC Alpha, despite it's lack of an overflow flag - this
> > strongly argues against your implication that an overflow flag is as
> > fundamental a feature as integer addition.
> >
>
> You are showing us only your ignorance. The DEC alpha has no
> flags but instructions that trap if overflow happens, what is the same
> and allows you to catch all overflows!
No a trap is not a flag. Learn the difference, and make sure to word
any proposed specification for this feature so that it will make sense
on platforms where there is a trap, rather than a flag.
> > Note that I am not asserting that C should only provide support for
> > absolutely essential compiler features. I'm only arguing against your
> > assertion that it's unnecessary to take into consideration the existence
> > of platforms where there is none.
>
>
> THERE IS NO COMPUTER WHERE OVERFLOW DETECTION IS IMPOSSIBLE.
>
> Did you understand that? I do not know how many times should I repeat
> it.
No one has argued against that. It is feasible to write C code which
fails to be strictly conforming only insofar as it depends upon the
implementation-specifc values of the macros defined in <limits.h>,
which anticipates when overflow would happen, and prevents it from
happening. Any conforming compiler must be able to compile such code
and execute it correctly. Therefore, at an absolute minimum, on any
platform where a convforming implementation of C is possible, an
implementation that emulates overflow flags must also be possible,
even on machines for which overflow itself is fatal.
The problem is that you insist on conflating "OVERFLOW DETECTION" (you
really should calm down) with overflow flags. They are not the same
thing, and using "overflow flags" as if it were a synonym for
"overflow detection" is guaranteed to cause communication failures
when speaking with people who use the terms correctly.
Keith Thompson
> On Sep 2, 9:24 am, Keith Thompson <ks...@mib.org> wrote:
>> Bart <b...@freeuk.com> writes:
>> > On Sep 2, 2:53 am, Keith Thompson <ks...@mib.org> wrote:
>
>> >> INT_MIN/(-1) overflows on two's-complement systems.
>>
>> > OK, a corner case (wouldn't it be easier to just add 1 to all these
>> > INT_MINs?)
>>
>> No, I don't believe it would.
>
> Not even in this particular case?
What particular case? You're proposing changing the value of INT_MIN
(and *_MIN for all signed integer types) for practically all
implementations so we can avoid overflow on division. This would
break the definitions of the int_NN_t types, which are required to
have a 2's-complement representation with no padding bits or trap
representations. It would also break a great deal of existing
(probably non-portable but still valid) code.
Surely it would make more sense just to handle overflow on division
the same way that overflow on multiplication is handled.
Or did you mean modifying the code so it computes (INT_MIN-1)/(-1)
rather than INT_MIN/(-1)? The point is that the standard still has to
define what INT_MIN/(-1) does, or state that its behavior is
undefined, unspecified, or implementation-defined.
[...]
>> if (rand() % 2 == 0) {
>> unsigned int x = y + z;
>> }
>> else {
>> int a = b + c;
>> }
>> if (_overflow()) {
>> ...
>> }
>>
>> Sure, it's a corner case, but this is exactly the kind of thing that
>> can't be ignored in a language feature.
>
> You've put the overflow check in the wrong place; it should be
> immediately after each operation. Otherwise you might as well put it
> at the end of main().
You're telling me I should change the code, and you may be right. I'm
saying the behavior of the code as written still has to be defined.
[...]
>> Here's a thought:
>>
>> bool overflowed = false;
>> int x = _CHECKED(overflowed, y + z);
>> if (overflowed) {
>> ...
>> }
>>
>> The idea is that _CHECKED is a macro that takes two arguments,
>> an lvalue that refers to a bool object, and a subexpression to be
>> evaluated with overflow checking. If an overflow occurs anywhere
>> within the expression, the bool is set to true and the resulting
>> value is unspecified (but not a trap representation). Otherwise,
>> the bool is either set to false or left alone, and the macro
>> invocation yields the result of the subexpression. The definition
>> of the macro presumably requires compiler magic.
An alternative, similar to something jacob proposed, is for the first
argument to be a pointer to a function that's called if there's an
overflow. One problem with that is that, since functions can't be
nested, the handler has no access to local variables.
> OK, so effectively special versions of the operators. But without
> exception processing, user code is going to get untidy. How about
> (going outside the realms of what is practical now):
>
> overflow();
> a = b (+) c (*) d;
> if (overflow())...
>
> So overflow() indicates *any* overflow since the last overflow()
> check. With (+) meant to indicate overflow-checked operations, and in
> this case needs to update a software flag. And to work across
> functions the flag needs to be local to each function...
Keith Thompson
> In article <lnmy5dn...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>>I would suggest, however, that you choose a phony domain name
>>other than "nospam.org", since that's a real domain and you might
>>be causing its owners to receive more spam.
>
> Are we supposed to imagine that someone registered the domain
> "nospam.org" unaware of the fact that it was likely to be used
> by thousands of people as a fake address?
I'm merely suggesting that using a fake address guaranteed not to be
valid is just as easy as using a fake address that might be valid.
jameskuyper
> Bart wrote:
> > On Sep 2, 7:56 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > wrote:
> >> [...]
> >> On my DEC Alpha there is no overflow flag. There can be no universally
> >> true semantics.
> >
> > That's interesting. So if someone brought out a processor that did not
> > have integer addition (or some other fundamental feature), would we
> > have to take integer addition out of standard C?
>
> As it happens, the very first "real" computer I wrote code for
> was very nearly as you describe: It couldn't do addition unaided.
> There was a ten-by-ten addition table (this was a decimal machine)
> hard-wired at a fixed location in core (actual core), and the CPU's
> circuitry consulted it whenever it needed to add a pair of digits.
> IBM 1620, nicknamed CADET for "Can't Add, Doesn't Even Try."
Hey, that's the same machine I started on! By the time I saw it, it
was long obsolete, but had been donated to my high school by an
alumnus. As a result, our high school offered computer programming
classes about a decade earlier than most of the other high schools in
the area.
However, I don't remember the addition table being hard-wired. I
remember having a bunch of punched cards that had to be loaded into
the machine to initialize the table. However, that was nearly four
decades ago, I could be mistaken.
jacob navia
> jacob navia wrote:
>> James Kuyper a �crit :
>>> C has existed for more than 30 years without any direct access to the
>>> overflow flag; I think we can safely presume that it's not essential to
>>> provide such access.
>> The problem of the future is that it has to be compatible with the bugs
>> of the past;
>>
>> C existed for 10 years without prototypes but it was a great improvement
>> when they appeared.
>
> I was not arguing against the idea of providing some way of checking
> for overflow. I was arguing against the idea that platforms which lack
> overflow flags are so deeply flawed that it is acceptable to define
> the behavior for such a feature in a way that would make it difficult,
> or even impossible, to implement on such platforms. A specification
> that refers directly to "the overflow flag" is impossible to implement
> on such platforms, because there is no such thing.
I do not know who proposed that, but it wasn't me.
Since you (as the other regulars can't read, here is my second
proposition AGAIN:
The compiler receives a compile time flag that will make it
generate code that when an overflow happens, a function will be
called that will report the line number and the file name
of the overflow position in the source code.
How the compiler does that is NOT specified at all.
> A specification for
> the feature that mandates emulation of overflow flags would be less
> problematic, though I suspect it would impose a serious performance
> penalty on such platforms - the stated reason for dropping overflow
> flags from the design of one such platform was improved performance.
>
Sure sure, and so what? Nobody wanted to port _overflow() to machines
that have no overflow flag!
>> Program correctness is more important now than speed at all costs,
>> even at the cost of getting WRONG RESULTS!
>>
>> In the implementation of lcc-win, the speed penaltiy paid by a program
>> that checks overflow at each operation is less than 4%.
>
> Have you ported lcc-win to a platform which has no overflow flags? If
> so, have you tested to see what the performance penalty is on that
> platform?
>
I do not care at all. If I write a compiler for that machine I would
try to have the less performance penalty as possible but is more
important that we get CORRECT RESULTS in many applications.
Now, I already mentioned that a #pragma would make the control of
code generation finer and more specific.
Obviously you did not read that.
>
>>> It's possible to created a decent general purpose
>>> language on the DEC Alpha, despite it's lack of an overflow flag - this
>>> strongly argues against your implication that an overflow flag is as
>>> fundamental a feature as integer addition.
>>>
>> You are showing us only your ignorance. The DEC alpha has no
>> flags but instructions that trap if overflow happens, what is the same
>> and allows you to catch all overflows!
>
> No a trap is not a flag. Learn the difference, and make sure to word
> any proposed specification for this feature so that it will make sense
> on platforms where there is a trap, rather than a flag.
>
>>> Note that I am not asserting that C should only provide support for
>>> absolutely essential compiler features. I'm only arguing against your
>>> assertion that it's unnecessary to take into consideration the existence
>>> of platforms where there is none.
>>
>> THERE IS NO COMPUTER WHERE OVERFLOW DETECTION IS IMPOSSIBLE.
>>
>> Did you understand that? I do not know how many times should I repeat
>> it.
>
> No one has argued against that.
Fine. At least we do agree on something.
> It is feasible to write C code which
> fails to be strictly conforming only insofar as it depends upon the
> implementation-specifc values of the macros defined in <limits.h>,
> which anticipates when overflow would happen, and prevents it from
> happening. Any conforming compiler must be able to compile such code
> and execute it correctly. Therefore, at an absolute minimum, on any
> platform where a convforming implementation of C is possible, an
> implementation that emulates overflow flags must also be possible,
> even on machines for which overflow itself is fatal.
>
> The problem is that you insist on conflating "OVERFLOW DETECTION" (you
> really should calm down) with overflow flags. They are not the same
> thing, and using "overflow flags" as if it were a synonym for
> "overflow detection" is guaranteed to cause communication failures
> when speaking with people who use the terms correctly.
I can't communicate with you if I propose TWO (yes TWO) solutions and
the first one is discussed and the second one is ignored damm!
Then, YOU (that did NOT read my article) says to ME that I should not
confuse overflow detection and overfflow flag???
Keith Thompson
[...]
> At present, you are the one who is spewing nonsense. The above
> discussion is about unsigned integer types, which - by definition -
> cannot overflow. See 3.1.2.5 of C89 or 6.2.5(9) of C99: "A
> computation involving unsigned operands can never overflow". They can
> *wrap*, but they cannot overflow. If your proprietary, non-standard,
> non-portable overflow detector detects overflow in the case of adding
> values with unsigned integer types, then it is detecting something
> that cannot occur. And if it doesn't, how is it a replacement for the
> above code?
On the other hand, a mechanism (exception handling, flag testing,
whatever) for detecting either signed or unsigned operations that
would, in integer mathematics, yield results not representable in
the relevant type might be useful.
For such operations, C imposes one rule for signed types (undefined
behavior) and another rule for unsigned types (wraparound).
There are very good reasons for both these rules, but they aren't
necessarily what a programmer might require in a particular case.
I might want defined behavior for signed overflow, or easy detection
for unsigned "overflow". It Would Be Nice if C could provide more
flexibility in this area.
Of course, such flexibility would come with a substantial cost,
but it's at least worth considering *if* we're seriously talking
about adding a new overflow detection mechanism to the language.
Richard, as you've pointed out, it is possible to write code in
portable standard C that detects overflows (by checking the operands
before performing the operation). But it requires writing much more
code, it's easy to get wrong, hardly anybody ever bothers to do it,
and it's something that most systems can do much more easily using
low-level mechanisms that the C language doesn't support (ironic
for such a relatively low-level language). I find the current
situation frustrating, and I'd welcome a better mechanism.
Keith Thompson
> Richard Heathfield a écrit :
>> In <h7lpon$tl9$1...@aioe.org>, Noob wrote:
>>> Richard Heathfield wrote:
>>>> Since overflow detection can be done /before/ the event, using
>>>> standard portable C, it is obviously true that there is no platform
>>>> where overflow detection is impossible.
>>> Consider
>>>
>>> int a = 12345;
>>> int b = a * 17;
>>>
>>> How does one test whether a * 17 will overflow?
>>
>> You can start off by dividing INT_MAX by 17.
>>
>>> Does one have to compute INT_MAX / 17?
>>
>> It's a start.
>
> Of course performance considerations are not a problem for you.
I'm sure Richard is perfectly well aware that the performance of such
code is a real problem. He was demonstrating that such detection is
possible, nothing more.
> The fact that each multiplication now implies a division doesn't
> bother you at all.
How did you arrive at that conclusion?
Keith Thompson
> James Kuyper a écrit :
[...]
>> Note that I am not asserting that C should only provide support for
>> absolutely essential compiler features. I'm only arguing against
>> your assertion that it's unnecessary to take into consideration the
>> existence of platforms where there is none.
>
> THERE IS NO COMPUTER WHERE OVERFLOW DETECTION IS IMPOSSIBLE.
>
> Did you understand that? I do not know how many times should I repeat
> it.
You don't have to repeat it at all, since nobody has stated otherwise.
It is a fact that the DEC Alpha has no overflow flag. It is
certainly possible to detect overflow on the DEC Alpha; you just
need to use a different mechanism.
I don't know how difficult it would be to implement your _overflow()
mechanism on the DEC Alpha. Do you?
My own opinion is merely that _overflow() is not the best mechanism
for overflow detection. The lack of an explicit overflow flag on the
DEC Alpha is one reason for this, but not the only one.
Keith Thompson
> Dik T. Winter a écrit :
Quite correct.
This in no way contradicts what Dik wrote.
jameskuyper
> jameskuyper a �crit :
...
> > A specification for
> > the feature that mandates emulation of overflow flags would be less
> > problematic, though I suspect it would impose a serious performance
> > penalty on such platforms - the stated reason for dropping overflow
> > flags from the design of one such platform was improved performance.
> >
>
> Sure sure, and so what? Nobody wanted to port _overflow() to machines
> that have no overflow flag!
Mandating it as part of the standard would required such porting, in
order for an implementation on that platform to be conforming.
> Now, I already mentioned that a #pragma would make the control of
> code generation finer and more specific.
>
> Obviously you did not read that.
True, I've learned to read as little as possible of what you write;
it's better for my blood pressure. However, when I'm using Google
Groups the message filters I have set upon on my home machine are
unavailable, and the fact that you addressed a response to one of my
messages caught my attention.
...
> I can't communicate with you ...
I like that idea.
Keith Thompson
>> > > > > You're assuming that the CPU has an "overflow flag". Not
>> all CPUs do.
>> > > You are starting the same discussion that we did in
>> comp.std.c. Note > that there wasn't ANY CPU where overflow could
>> not be detected.
>>
>> No, you were writing about an overflow flag.
>
> You did not read my article. You read what this Mr Thompson understood
> from my article.
>
> Please read my article and then you will see that I proposed TWO solutions:
>
> (1) Quick and dirty: Access the overflow flag using the pseudo function
> _overflow()
> (2) Using a compile time flag tell the compiler to checkfor overflow.
> The compiler will call a function (that you can write) telling you
> that an overflow occurre at some line in some file.c.
>
> Since Thompson can't read well, he did not read all my message and you
> are assuming that what he says is true... a bad idea.
Are you referring to your article in comp.std.c? I don't remember
it clearly; can you post a message-id and/or URL? But for now I'll
accept your summary.
(1) In my opinion, the _overflow() pseudo-function is not a good
solution, and I would oppose adding it to the language standard.
No, the lack of an overflow flag on the DEC Alpha (and possibly
other processors) is not the only reason for this. My objection is
that its design is fairly obviously tied to a low-level feature of
*some* CPUs, a feature that can work differently, or even not exist,
on some systems, though it could probably be emulated. But even if
every CPU in existence had an overflow flag, in my opinion overflow
detection can be, and should be, a higher-level concept.
(2) I'm not sure what you mean by "compile time flag". If you're
referring to a compiler command-line option, I wouldn't want the
standard to require that, both because the standard currently
doesn't mention any such options and because it means that vitally
important information about a program doesn't exist in the program's
source code. If you're referring to something like a #pragma,
this objection doesn't apply.
One problem with calling a user-defined function on overflow is
that that function doesn't have access to local variables in the
function that triggered the overflow.
I'd much rather see a mechanism that allows overflows to be handed
locally. A full-blown exception mechanism, in the style of C++
or Ada, would neatly solve the problem, but I suspect that wouldn't
be accepted. I've posted some (admittedly vague) ideas elsewhere
in this thread.
Since I've disagreed with some, but not all, of what you've written,
please feel free to take it personally, accuse me of not caring
about real-world programming, assume that I'm conspiring behind
the scenes with the other "regs", and call me a liar.
Gordon Burditt
>assumption of twos complement logic and did this
>
>if (expr < input) overflow_occurred();
This works OK on unsigned add operations.
>E.g.
>
>if (a*b < a || a*b < b) ...
This doesn't detect overflow properly.
For example, let a = 20000, b = 8, and assume that ints are 16 bits
and two's complement.
a*b = 160000 (in mathematics), but in 16 bits this is 160000 - 2*65536 = 28928.
a*b (28928) is not less than a (20000).
a*b (28928) is not less than b (8).
But you had overflow.
>No division, it's not 100% portable, but practically speaking it's
>bound to work everywhere today.
No, it's not: it doesn't detect overflow in some cases when it
happens. I can construct such examples for 32-bit ints also, the
math is simpler for 16 bits.
Keith Thompson
[...]
> As it happens, the very first "real" computer I wrote code for
> was very nearly as you describe: It couldn't do addition unaided.
> There was a ten-by-ten addition table (this was a decimal machine)
> hard-wired at a fixed location in core (actual core), and the CPU's
> circuitry consulted it whenever it needed to add a pair of digits.
> IBM 1620, nicknamed CADET for "Can't Add, Doesn't Even Try."
I think CADET was actually IBM's name for the machine. Users later
decided that it should stand for "Can't Add, Doesn't Even Try".
Bart
> In article <d4f585b6-d30f-479b-be04-06dda6a38...@w6g2000yqw.googlegroups.com>,
>
> Bart <b...@freeuk.com> wrote:
> >On Sep 2, 12:27 am, pac...@kosh.dhis.org (Alan Curry) wrote:
> >> a[i] = x + y;
> >> if(_overflow()) abort();
> >> Did I check for the overflow of x+y, or did I check for overflow of the
> >> address calculation a+i that the compiler had to do to decide where to store
>
> >I think we're talking about signed integer overflow, address ops would
> >be unsigned, and may not even set normal flags in the CPU.
>
> I'm not aware of a processor that has separate instructions for unsigned
> addition. The ones I know just have "add", which works for both signed and
> unsigned using the same bits.
...
My point is that addition for address arithmetic might not set any
flags:
add R1,(R2+disp)
Only one overflow can be set, even though this instructions has two
additions. Clearly it will be for the main operation.
--
Bart
> Bart wrote:
> > On Sep 2, 7:56 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > wrote:
> ...
> >> On my DEC Alpha there is no overflow flag. There can be no universally
> >> true semantics.
>
> > That's interesting. So if someone brought out a processor that did not
> > have integer addition (or some other fundamental feature), would we
> > have to take integer addition out of standard C?
>
> consideration. One of the primary design goals for C was to be as widely
> implementable as possible; that must be balanced against other goals. If
> a decent low-level general purpose programming language could be
> efficiently implemented on a processor which lacked support for integer
> addition (though I can't imagine how that could be possible), C should
> be such a language.
>
> C has existed for more than 30 years without any direct access to the
> overflow flag; I think we can safely presume that it's not essential to
> provide such access.
I must admit that in 30 years also, I've never used the overflow flag,
other than in it's aliases to compare two signed values. I'm more
familiar with the carry flag, where C also doesn't provide access, and
this usually works because the sort of things you'd need it for are
already in the language, which uses it internally.
But try any arithmetic on bigger integers than the compiler supports,
and you need some clunky code to get round the lack of carry.
In a similar way, someone desperate to efficiently test for overflow,
would need fiddly code to achieve this.
> It's possible to created a decent general purpose
> language on the DEC Alpha, despite it's lack of an overflow flag - this
> strongly argues against your implication that an overflow flag is as
> fundamental a feature as integer addition.
The designers of this (risc?) cpu presumably decided to gamble
performance against the need for a possibly rare overflow check. So
overflow checking is slower but is made up for by extra speed in other
areas. If you need overflow check on every integer op, then you're out
of luck with this cpu.
(But, doesn't the Dec Alpha also lack a divide op or some such thing?
If that's true, how does a C compiler get around that?)
--
Bart
Ben Pfaff
> (But, doesn't the Dec Alpha also lack a divide op or some such thing?
> If that's true, how does a C compiler get around that?)
Many processors lack division operations. On these processors
the C compiler must implement division itself, often by calling
into a subroutine.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Eric Sosman
>
> As someone who wrote a performance math library I just made the
> assumption of twos complement logic and did this
>
> if (expr < input) overflow_occurred();
>
> E.g.
>
> if (a*b < a || a*b < b) ...
>
> No division, it's not 100% portable, but practically speaking it's
> bound to work everywhere today.
You've lost me: I don't see how it could work at all, much less
"everywhere." It's clearly wrong if negatives or zeroes are involved,
but even with strictly positive numbers it's not always right. For
example, try a = 4, b = 1610612735, and a 32-bit `int'. The true
product a*b is 6442450940, which after being chopped to 32 bits
becomes 2147483644. This value is greater than both a and b, so your
test shows nothing, yet overflow has most definitely occurred.
jacob navia
> jacob navia wrote:
>> Obviously you did not read that.
>
> True, I've learned to read as little as possible of what you write;
Obviously answering my messages is "as little as possible"
???
WHY DO YOU ANSWER AT ALL MORON?
If you do not want to communicate with me do not answer my messages
it is as simple as that!
> it's better for my blood pressure.
> ...
>> I can't communicate with you ...
>
> I like that idea.
Me too. Obviously a killfile is something beyond your mental
abilities then just IGNORE my messages
Nobody
> And you're assuming there's a "carry flag". The definition for a
> language feature can't assume an x86-like target.
Even among "normal" CPUs, it varies as to whether the sense of the carry
flag is inverted for subtraction (i.e. borrow => carry clear, no borrow =>
carry set).
Nobody
>>> In my compiler system lcc-win I added an intrinsic function
>>>
>>> int _overflow(void);
>>>
>>> that will return 1 if the overflow flag is set, zero otherwise. This
>>> allows you to catch overflow in certain situations.
>>
>> A function prototype on its own is meaningless. And a function documented
>> as returning the "current" state of the overflow flag is useless unless
>> you provide *complete* operational semantics.
>
> On my DEC Alpha there is no overflow flag. There can be no universally
> true semantics.
I don't think that lcc-win supports the Alpha.
But this misses my point: even if you're dealing with a specific CPU,
getting the current state of the overflow flag is meaningless in a
language such as C which doesn't dictate how expressions are translated to
machine instructions.
Nobody
>>> In my compiler system lcc-win I added an intrinsic function
>>>
>>> int _overflow(void);
>>>
>>> that will return 1 if the overflow flag is set, zero otherwise. This
>>> allows you to catch overflow in certain situations.
>>
>> A function prototype on its own is meaningless.
>
> This will report the status of the overflow flag, i.e. the status of the
> last arithmetic operation done. You can read the documentation of
> lcc-win, if you like.
Does the lcc-win documentation provide sufficient information to determine
the last arithmetic operation performed when evaluating a particular
expression?
Unless the compiler performs almost no optimisation whatsoever, this seems
unlikely.
And without that information, the status of the overflow flag at a
particular point in a C program is meaningless.