#include <stdio.h>
int main(void) {
int i ;
for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}
Assume that a compiler is clever enough to realise that the
above will eventually overflow i. Can it refuse to produce an
executable on that basis ?
23  1425 
Assume that a compiler is clever enough to realise that the
above will eventually overflow i. Can it refuse to produce an
executable on that basis ?
It won't. Eventually i will become -ve after reaching it +ve maximum
and then it will become 0. So it will terminate.
Hurray!
In article <11**********************@19g2000hsx.googlegroups. com>,
Ravi <ra*********@gmail.comwrote:
>It won't. Eventually i will become -ve after reaching it +ve maximum
and then it will become 0. So it will terminate.
On most machines, but it's not guaranteed.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
#include <stdio.h>
int main(void) {
int i ;
for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}
Assume that a compiler is clever enough to realise that the above will
eventually overflow i. Can it refuse to produce an executable on that
basis ?
Yes, but only because it can be proven that the loop will always execute.
If the function were named differently, and the compiler could no longer
prove it would be called unconditionally, then the compiler would have to
accept the code.
"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
fc**********@news1.zwoll1.ov.home.nl...
On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
>#include <stdio.h>
int main(void) {
int i ;
for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}
Assume that a compiler is clever enough to realise that the above will
eventually overflow i. Can it refuse to produce an executable on that
basis ?
Yes, but only because it can be proven that the loop will always execute.
If the function were named differently, and the compiler could no longer
prove it would be called unconditionally, then the compiler would have to
accept the code.
if i was defined as an unsigned variable, the behaviour is well defined and
I see no reason for the compiler to complain. If it is smart enough, it
will optimize to loop away.
With i as an int, it depends on the implementation whether the behaviour is
undefined or not. The compiler could detect the inevitable integer overflow
and complain about it, or even refuse to produce an executable, but on most
architectures the behaviour is defined and the loop can be optimized away.
--
Chqrlie.
Ravi wrote:
>
>Assume that a compiler is clever enough to realise that the
above will eventually overflow i. Can it refuse to produce an
executable on that basis ?
It won't. Eventually i will become -ve after reaching it +ve
maximum and then it will become 0. So it will terminate.
The above *erroneous* statement needs rapid stomping. In C, any
integer overflow results in undefined behaviour. Some systems may
resolve that to resolving to a negative value, but even then which
value is variable (think 1's and 2's complement arithmetic). If
you want to handle overflow consistently, used unsigned integers,
which do modulo arithmetic.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote, On 14/09/07 20:19:
Ravi wrote:
>>Assume that a compiler is clever enough to realise that the
above will eventually overflow i. Can it refuse to produce an
executable on that basis ?
It won't. Eventually i will become -ve after reaching it +ve
maximum and then it will become 0. So it will terminate.
The above *erroneous* statement needs rapid stomping. In C, any
integer overflow results in undefined behaviour. Some systems may
resolve that to resolving to a negative value, but even then which
value is variable (think 1's and 2's complement arithmetic). If
you want to handle overflow consistently, used unsigned integers,
which do modulo arithmetic.
Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve. So a loop of the form
for (i=1 ; i != 0 ; i++) ;
Would actually loop forever if the processor was put in that mode.
--
Flash Gordon
Charlie Gordon wrote:
>
.... snip ...
>
Come on, what gcc target does not do simple wrap around on signed
integer overflow ?
At least any that implement overflow traps. I can set up the 8088
to do just that.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
"CBFalconer" <cb********@yahoo.coma écrit dans le message de news: 46***************@yahoo.com...
Charlie Gordon wrote:
>>
... snip ...
>>
Come on, what gcc target does not do simple wrap around on signed
integer overflow ?
At least any that implement overflow traps. I can set up the 8088
to do just that.
Yes, but do you have an OS or even a program that runs in this mode ?
--
Chqrlie.
On Fri, 14 Sep 2007 19:31:09 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote in comp.lang.c:
"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
fc**********@news1.zwoll1.ov.home.nl...
On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
#include <stdio.h>
int main(void) {
int i ;
for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}
Assume that a compiler is clever enough to realise that the above will
eventually overflow i. Can it refuse to produce an executable on that
basis ?
Yes, but only because it can be proven that the loop will always execute.
If the function were named differently, and the compiler could no longer
prove it would be called unconditionally, then the compiler would have to
accept the code.
if i was defined as an unsigned variable, the behaviour is well defined and
I see no reason for the compiler to complain. If it is smart enough, it
will optimize to loop away.
With i as an int, it depends on the implementation whether the behaviour is
undefined or not. The compiler could detect the inevitable integer overflow
Signed integer overflow or underflow is always undefined.
and complain about it, or even refuse to produce an executable, but on most
architectures the behaviour is defined and the loop can be optimized away.
No, in C it is always undefined behavior. The result may be
predictable and repeatable on a particular platform, but that doesn't
make it defined.
Predictable and repeatable results are one possible consequence of
undefined behavior.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
On 15 Sep, 00:47, Flash Gordon <s...@flash-gordon.me.ukwrote:
Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve.
What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.
outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}
Charlie Gordon wrote:
"CBFalconer" <cb********@yahoo.coma écrit:
>Charlie Gordon wrote:
>>>
... snip ...
>>>
Come on, what gcc target does not do simple wrap around on signed
integer overflow ?
At least any that implement overflow traps. I can set up the 8088
to do just that.
Yes, but do you have an OS or even a program that runs in this mode ?
Yes.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
"CBFalconer" <cb********@yahoo.coma écrit dans le message de news: 46***************@yahoo.com...
Charlie Gordon wrote:
>"CBFalconer" <cb********@yahoo.coma écrit:
>>Charlie Gordon wrote:
... snip ...
Come on, what gcc target does not do simple wrap around on signed
integer overflow ?
At least any that implement overflow traps. I can set up the 8088
to do just that.
Yes, but do you have an OS or even a program that runs in this mode ?
Yes.
I'm impressed !
We should call that a DS8088
--
Chqrlie.
Spiros Bousbouras wrote, On 15/09/07 14:23:
On 15 Sep, 00:47, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve.
What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.
+ve is a fairly well known abbreviation for positive in England and I
suspect a number of other countries. I'll let you work out what -ve is.
outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}
With a 16 bit int
i = 0x7FFF;
i++; /* i is *still* 0x7FFF */
--
Flash Gordon
Spiros Bousbouras <sp****@gmail.comwrites:
On 15 Sep, 00:47, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve.
What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.
"+ve" means "positive", "-ve" means "negative".
outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}
I think it refers to saturation, meaning that a computation that
overflows yields an extreme value of the type. For example, INT_MAX +
1 would yield INT_MAX; INT_MIN * 3 would yield INT_MIN.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Spiros Bousbouras wrote:
On 15 Sep, 00:47, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Note that some processors (the ones I know are DSPs have the ability
to limit at maximum +ve/-ve.
What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.
+ve is shorthand for 'positive'. -ve is shorthand for 'negative'.
The sign in front of the ve is significant here.
>
outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}
It is also known a saturating arithmetic.
With saturating arithmetic, the following holds:
int foo = INT_MAX;
foo++;
assert(foo == INT_MAX);
(and similar for decrement of lowest value).
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Keith Thompson <ks***@mib.orgwrote:
Thad Smith <Th*******@acm.orgwrites:
Flash Gordon wrote:
Spiros Bousbouras wrote, On 15/09/07 14:23:
On 15 Sep, 00:47, Flash Gordon <s...@flash-gordon.me.ukwrote:
Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve.
What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.
+ve is a fairly well known abbreviation for positive in England and
I suspect a number of other countries. I'll let you work out what
-ve is.
I'm guessing that you mean positive voltage, instead of a positive
number. This assumes that the value represents a voltage.
Why would you assume that it refers to a voltage? The "ve" comes from
the last two letters of the words "negative" and "positive".
Because outside electrics, there's really not much need to abbreviate
positive and negative to plussive and minussive.
Richard
Flash Gordon wrote:
Keith Thompson wrote:
.... snip ...
>
>Flash Gordon can explain what he meant, but it seemed clear enough
to me (though terse): expressions whose results would exceed
INT_MAX yield INT_MAX, and expressions whose results would be less
than INT_MIN yield INT_MIN. I don't see why it doesn't work for
the negative case.
This is indeed what I meant and it is behaviour some DSPs can be
set to because it is very useful behaviour in signal processing.
While it may be useful for SOME input schemes, in general it loses
the ability to detect and correct overflows (note the correct). In
addition, it effectively converts the extreme values into overflow
signals, with no correction available.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote, On 17/09/07 10:54:
Flash Gordon wrote:
>Keith Thompson wrote:
... snip ...
>>Flash Gordon can explain what he meant, but it seemed clear enough
to me (though terse): expressions whose results would exceed
INT_MAX yield INT_MAX, and expressions whose results would be less
than INT_MIN yield INT_MIN. I don't see why it doesn't work for
the negative case.
This is indeed what I meant and it is behaviour some DSPs can be
set to because it is very useful behaviour in signal processing.
While it may be useful for SOME input schemes, in general it loses
the ability to detect and correct overflows (note the correct). In
addition, it effectively converts the extreme values into overflow
signals, with no correction available.
I did not say it solves every problem only that it is very useful. I did
not even say how often it is very useful, but I will correct that, there
are a lot of situations in which it is very useful. This is why the chip
manufacturers provide this. One typical instance where it is useful is
if you are producing a signal which will be sent to a speaker, limiting
will distort the sound where wrapping is likely to wreck the speaker.
The same applies to any other control system where you will be producing
magnetic fields to deflect something (even an electron beam in a TV),
limiting will give you distorted output where wrapping will wreck
things. Do you want your dolby surround sound processor to wreck your
expensive speakers (and maybe the power amp as well) but come up with a
nice little message, or do you want it to prevent any damage?
The processor *may* also set an overflow flag and so avoid loosing the
information. I can't remember if the processors I used did this or not,
but it could certainly be done.
--
Flash Gordon
On Mon, 17 Sep 2007 06:36:03 GMT, in comp.lang.c , rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>Keith Thompson <ks***@mib.orgwrote:
>Why would you assume that it refers to a voltage? The "ve" comes from
the last two letters of the words "negative" and "positive".
Because outside electrics, there's really not much need to abbreviate
positive and negative to plussive and minussive.
Huh? I do it all the time.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Flash Gordon wrote:
CBFalconer wrote, On 17/09/07 10:54:
>Flash Gordon wrote:
>>Keith Thompson wrote:
... snip ...
>>>Flash Gordon can explain what he meant, but it seemed clear
enough to me (though terse): expressions whose results would
exceed INT_MAX yield INT_MAX, and expressions whose results
would be less than INT_MIN yield INT_MIN. I don't see why
it doesn't work for the negative case.
This is indeed what I meant and it is behaviour some DSPs can be
set to because it is very useful behaviour in signal processing.
While it may be useful for SOME input schemes, in general it
loses the ability to detect and correct overflows (note the
correct). In addition, it effectively converts the extreme
values into overflow signals, with no correction available.
.... snip ...
>
The processor *may* also set an overflow flag and so avoid
loosing the information. I can't remember if the processors I
used did this or not, but it could certainly be done.
The point is that the information to perform the recovery has been
lost once the value overflows to a MAX or a MIN value. Recovery
requires the original operands, which are no longer available. For
addition, overflow with a separate signal and a modulo result
allows addition (or subtraction) of a constant to regain the
correct answer. None of this prevents the whole business being C
std compatible.
None of this is negating anything you said, it is just a factor for
users to keep in mind.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
On Sep 18, 8:52 am, "Charlie Gordon" <n...@chqrlie.orgwrote:
"CBFalconer" <cbfalco...@yahoo.coma écrit dans le message de news:
For an example, take the following code, which returns a correct
value at all times for +ve inputs, but does the relatively rapid
int addition rather than long addition (most of the time). The
code ASSUMES modulo overload action and that LONG_MAX INT_MAX. I
am NOT recommending using this code.
long add(int a, int b) { /* not portable */
int c
c = a + b;
if ((c < a) || (c < b)) /* overflow detected */
return (long)a + (long)b;
else return c;
} /* NOT RECOMMENDED CODE */
No, I'm afraid this does not account for all supported architectures.
If signed integer addition is performed with saturation, the "overflow" will
go undetected by your code, and the incorrect, saturated value will be
returned.
CBFalconer said that his code is only intended for when int
arithmetic is performed with wraparound.
More generally, you invoke undefined behaviour on signed integer overflow
ass soon as you do c = a + b with inappropriate values of a and b.
A more effective solution is this:
#include <stdint.h>
long add(int a, int b) {
if (a >= 0)
return (b <= INT_MAX - a) ? a + b : (long)a + b;
else
return (b >= INT_MIN - a) ? a + b : (long)a + b;
}
It is only slightly less efficient than yours, but should work on all
platforms for all input.
If you are adopting CBFalconer's assumption that LONG_MAX >
INT_MAX then your code will work ; if you assume just what
the standard says and nothing more then your code can also
produce undefined behaviour.
"Spiros Bousbouras" <sp****@gmail.coma écrit dans le message de news: 11**********************@k79g2000hse.googlegroups. com...
On Sep 18, 8:52 am, "Charlie Gordon" <n...@chqrlie.orgwrote:
>"CBFalconer" <cbfalco...@yahoo.coma écrit dans le message de news:
>>For an example, take the following code, which returns a correct
value at all times for +ve inputs, but does the relatively rapid
int addition rather than long addition (most of the time). The
code ASSUMES modulo overload action and that LONG_MAX INT_MAX. I
am NOT recommending using this code.
>> long add(int a, int b) { /* not portable */
int c
>> c = a + b;
if ((c < a) || (c < b)) /* overflow detected */
return (long)a + (long)b;
else return c;
} /* NOT RECOMMENDED CODE */
No, I'm afraid this does not account for all supported architectures.
If signed integer addition is performed with saturation, the "overflow"
will
go undetected by your code, and the incorrect, saturated value will be
returned.
CBFalconer said that his code is only intended for when int
arithmetic is performed with wraparound.
Sorry about that, I read too fast.
>More generally, you invoke undefined behaviour on signed integer overflow
ass soon as you do c = a + b with inappropriate values of a and b.
A more effective solution is this:
#include <stdint.h>
long add(int a, int b) {
if (a >= 0)
return (b <= INT_MAX - a) ? a + b : (long)a + b;
else
return (b >= INT_MIN - a) ? a + b : (long)a + b;
}
It is only slightly less efficient than yours, but should work on all
platforms for all input.
If you are adopting CBFalconer's assumption that LONG_MAX >
INT_MAX then your code will work ; if you assume just what
the standard says and nothing more then your code can also
produce undefined behaviour.
Of course that assumption is also mine. If LONG_MAX == INT_MAX, then we
have to specify what we want this function to return. Saturation is trivial
to implement, modulo wrap around is more tricky.
--
Chqrlie. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Simon Bailey |
last post by:
In the following code at the end of the program z = 20 & y = 99.
void doit(const int* x)
{
int* nonconst;
nonconst = const_cast<int*>(x);
*nonconst = 99;
}
int main(int argc, char* argv)
|
by: Scott J. McCaughrin |
last post by:
The following program compiles fine but elicits this message from the
linker: "undefined reference to VarArray::funct" and thus fails.
It seems to behave as if the static data-member:...
|
by: Joona I Palaste |
last post by:
We all know that this:
void *p;
if (p=malloc(1)) {
free(p);
p;
}
causes undefined behaviour if malloc() succeeds. But what about this?
|
by: Nitin Bhardwaj |
last post by:
Well, i'm a relatively new into C( strictly speaking : well i'm a
student and have been doing & studying C programming for the last 4
years).....and also a regular reader of "comp.lang.c"
I...
|
by: Ken Turkowski |
last post by:
The construct
(void*)(((long)ptr + 3) & ~3)
worked well until now to enforce alignment of the pointer to long
boundaries. However, now VC++ warns about it, undoubtedly to help things
work on 64...
|
by: RoSsIaCrIiLoIA |
last post by:
On Mon, 07 Feb 2005 21:28:30 GMT, Keith Thompson <kst-u@mib.org>
wrote:
>"Romeo Colacitti" <wwromeo@gmail.com> writes:
>> Chris Torek wrote:
>>> In article <4205BD5C.6DC8@mindspring.com>
>>>...
|
by: Frederick Gotham |
last post by:
I have a general idea of the different kinds of behaviour described by the
C Standard, such as:
(1) Well-defined behaviour:
int a = 2, b = 3;
int c = a + b;
(Jist: The code will work...
|
by: Franz Hose |
last post by:
the following program, when compiled with gcc and '-std=c99', gcc says
test.c:6: error: jump into scope of identifier with
variably modified type
that is, it does not even compile.
...
|
by: subramanian100in |
last post by:
Consider the following code:
#include <iostream>
#include <cstdlib>
using namespace std;
int main()
{
const double& ref = 100;
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
