473,320 Members | 2,146 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Line input and implementation-defined behaviour

Both K&R book and Steve Summit's tutorial define a getline() function
correctly testing the return value of getchar() against EOF.

I know that getchar() returns EOF or the character value cast to
unsigned char.

Since char may be signed (and if so, the return value of getchar() would
be outside its range), doesn't the commented line in the following code
produce implementation-defined behaviour?

char s[SIZE];
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
s[i] = c; /* ??? */
i++;
}

s[i] = '\0';

If this is indeed implementation defined, is there any solution?

--
Enrico `Trippo' Porreca

Nov 13 '05 #1
29 2198
"Enrico `Trippo' Porreca" <tr****@lombardiacom.it> wrote:
Since char may be signed (and if so, the return value of getchar()
would be outside its range), doesn't the commented line in the
following code produce implementation-defined behaviour?
Almost. If a character is read whose code is out of the range of
signed char, it produces an implementation-defined result, or an
implementation-defined signal is raised. This is not quite as bad
as implementation-defined behaviour, but almost.
char s[SIZE];
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
s[i] = c; /* ??? */
i++;
}

s[i] = '\0';

If this is indeed implementation defined, is there any solution?


If char is signed, and the value of the character is outside the
range of signed char, then you have an out-of-range conversion to
a signed integer type, so: "either the result is implementation-defined
or an implementation-defined signal is raised." (C99 6.3.1.3#3)

However, because this is such an incredibly common operation in
existing C code, an implementor would be absolutely idiotic to
define this to have any undesired effects.

--
Simon.
Nov 13 '05 #2
Simon Biber wrote:
char s[SIZE];
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
s[i] = c; /* ??? */
i++;
}

s[i] = '\0';

If this is indeed implementation defined, is there any solution?


If char is signed, and the value of the character is outside the
range of signed char, then you have an out-of-range conversion to
a signed integer type, so: "either the result is implementation-defined
or an implementation-defined signal is raised." (C99 6.3.1.3#3)

However, because this is such an incredibly common operation in
existing C code, an implementor would be absolutely idiotic to
define this to have any undesired effects.


I agree, but AFAIK the implementor is allowed to be idiot...
Am I right?

Is the following a plausible solution (i.e. without any trap
representation or type conversion or something-defined behaviour problem)?

char s[SIZE];
unsigned char *t = (unsigned char *) s;
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
t[i] = c; /* ??? */
i++;
}

s[i] = '\0';

--
Enrico `Trippo' Porreca

Nov 13 '05 #3
"Enrico `Trippo' Porreca" <tr****@lombardiacom.it> wrote:
I agree, but AFAIK the implementor is allowed to be idiot...
Am I right?
Yes, but trust me, anyone who fouled up the char<->int conversion
would break a large proportion of existing code that is considered
to be completely portable. Therefore their implementation would
not sell.

Consider the <ctype.h> functions, which require that the input is
an int whose value is within the range of unsigned char. That is
why we suggest that people cast to unsigned char like this:
char *p, s[] = "hello";
for(p = s; *p; p++)
*p = toupper((unsigned char)*p);
Now if the value of *p was negative, now when converted to unsigned
char it is positive and outside the range of signed char. So this
could theoretically be outside the range of int, if int and signed
char have the same range. Therefore you have the same situation in
reverse - unsigned char to int conversion is not guaranteed to be
within range.
Is the following a plausible solution (i.e. without any trap
representation or type conversion or something-defined behaviour
problem)?

char s[SIZE];
unsigned char *t = (unsigned char *) s;
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
t[i] = c; /* ??? */
The assignment itself is safe, but since it places an arbitrary
representation into the elements of the array s, which are char
objects and possibly signed, it might generate a trap
representation. That is if signed char can have trap
representations. I'm not completely sure.
i++;
}

s[i] = '\0';


--
Simon.
Nov 13 '05 #4

"Simon Biber" <ne**@ralminNOSPAM.cc> wrote in message
char s[SIZE];
unsigned char *t = (unsigned char *) s;
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
t[i] = c; /* ??? */

s[i] = 0;
The assignment itself is safe, but since it places an arbitrary
representation into the elements of the array s, which are char
objects and possibly signed, it might generate a trap
representation. That is if signed char can have trap
representations. I'm not completely sure.

signed chars can trap. unsigned chars are guaranteed to be able to hold
arbitrary data so cannot.
You would have to be desperately unlucky for the implementation to allow
non-chars to be read in from stdin, and then for the function to trap. The
most likely place for the trap to trigger would be the assignment s[i] = 0,
since the compiler probably won't realise that pointer t actually points to
a buffer declared as straight char.
Nov 13 '05 #5
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bl**********@news6.svr.pol.co.uk...

"Simon Biber" <ne**@ralminNOSPAM.cc> wrote in message
char s[SIZE];
unsigned char *t = (unsigned char *) s;
int c;
size_t i = 0;

while ((c = getchar()) != EOF && c != '\n' && i < SIZE - 1) {
t[i] = c; /* ??? */

s[i] = 0;

The assignment itself is safe, but since it places an arbitrary
representation into the elements of the array s, which are char
objects and possibly signed, it might generate a trap
representation. That is if signed char can have trap
representations. I'm not completely sure.

signed chars can trap. unsigned chars are guaranteed to be able to hold
arbitrary data so cannot.
You would have to be desperately unlucky for the implementation to allow
non-chars to be read in from stdin, and then for the function to trap. The
most likely place for the trap to trigger would be the assignment s[i] =

0,

0 is a value in the range of signed char, so it is not possible for a
conforming compiler to replace the contents of object s[i] with a trap
representation.

[You can always initialise an unitialised automatic variable for instance,
even if it's uninitialised state is a trap representation.]
since the compiler probably won't realise that pointer t actually points to a buffer declared as straight char.


You seem to be confusing 'trap representations' for 'trap'. The latter term
commonly being used for raised exceptions on many architectures. A trap
representation, in and of itself, need not raise an exception.

Indeed, whilst the standards allow signed char to have trap representations,
sections like 6.2.6.1p5 effectively say that all reads via character lvalues
are privileged. So at worst, it would seem, reading a character trap
representation will only yield an unspecified value. [Non-trapping trap
representations!]

--
Peter
Nov 13 '05 #6

"Peter Nilsson" <ai***@acay.com.au> wrote in message
The most likely place for the trap to trigger would be the assignment
s[i] = 0,
0 is a value in the range of signed char, so it is not possible for a
conforming compiler to replace the contents of object s[i] with a trap
representation.

What I meant was that the assignment may trigger the trap, if illegal
characters are stored into the array s. This is because values from s may be
loaded into registers as chars.
Indeed, whilst the standards allow signed char to have trap
representations, sections like 6.2.6.1p5 effectively say that all reads via character lvalues are privileged. So at worst, it would seem, reading a
character trap representation will only yield an unspecified value. [Non-
trapping trap representations!]

It seems it would be unacceptable for the line

fgets(line, sizeof line, fp);

to cause a program abort if fed an illegal character, with nothing the
programmer can do to stop it. OTOH reads are the most likely way for corrupt
data to get into the data, and the whole point of trap representations is to
close down any program that is malfunctioning.

Nov 13 '05 #7
Simon Biber wrote:
I agree, but AFAIK the implementor is allowed to be idiot...
Am I right?


Yes, but trust me, anyone who fouled up the char<->int conversion
would break a large proportion of existing code that is considered
to be completely portable. Therefore their implementation would
not sell.


Uhm... So I think I should use K&R's getline(), without being too
paranoid about it...

Thanks.

--
Enrico `Trippo' Porreca

Nov 13 '05 #8
Enrico `Trippo' Porreca wrote:
Simon Biber wrote:
I agree, but AFAIK the implementor is allowed to be idiot...
Am I right?


Yes, but trust me, anyone who fouled up the char<->int conversion
would break a large proportion of existing code that is considered
to be completely portable. Therefore their implementation would
not sell.


Uhm... So I think I should use K&R's getline(), without being too
paranoid about it...


Consider ggets, available at:

<http://cbfalconer.home.att.net/download/>

which has the convenience of gets without the insecurities.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #9
In <3f**********************@news.optusnet.com.au> "Simon Biber" <ne**@ralminNOSPAM.cc> writes:
"Enrico `Trippo' Porreca" <tr****@lombardiacom.it> wrote:
Since char may be signed (and if so, the return value of getchar()
would be outside its range), doesn't the commented line in the
following code produce implementation-defined behaviour?


Almost. If a character is read whose code is out of the range of
signed char, it produces an implementation-defined result, or an
implementation-defined signal is raised. This is not quite as bad
as implementation-defined behaviour, but almost.


No implementation-defined signal is raised in C89 and I strongly doubt
that any *real* C99 implementation would do that, breaking existing C89
code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #10
Added comp.std.c - we are discussing the effect of conversion of
an out-of-range value to a signed integer type, as in C99 6.3.1.3#3
"either the result is implementation-defined or an
implementation-defined signal is raised."

"Dan Pop" <Da*****@cern.ch> wrote:
"Simon Biber" <ne**@ralminNOSPAM.cc> writes:
Almost. If a character is read whose code is out of the range of
signed char, it produces an implementation-defined result, or an
implementation-defined signal is raised. This is not quite as bad
as implementation-defined behaviour, but almost.


No implementation-defined signal is raised in C89 and I strongly doubt
that any *real* C99 implementation would do that, breaking existing C89
code.


Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?

--
Simon.
Nov 13 '05 #11
In article <3f***********************@news.optusnet.com.au> , Simon Biber
<ne**@ralminNOSPAM.cc> writes
Added comp.std.c - we are discussing the effect of conversion of
an out-of-range value to a signed integer type, as in C99 6.3.1.3#3
"either the result is implementation-defined or an
implementation-defined signal is raised." [...]Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


No.

However, the point was raised - and many of us considered it a good one
- that the C89 Standard *requires* the silent generation of a nonsense
value with no easy way to detect that fact. In some programming
situations ("mission-critical code"), you'd much rather the compiler
generated code to trap this case and alert you in some way - a panic is
far better than a bad value slipping into a later calculation.

So we decided to offer this option to the compiler writer. There's no
requirement to take it, but it's available.

--
Clive D.W. Feather, writing for himself | Home: <cl***@davros.org>
Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <cl***@demon.net>
Written on my laptop; please observe the Reply-To address
Nov 13 '05 #12
"Clive D. W. Feather" wrote:
Simon Biber <ne**@ralminNOSPAM.cc> writes
Added comp.std.c - we are discussing the effect of conversion of
an out-of-range value to a signed integer type, as in C99 6.3.1.3#3
"either the result is implementation-defined or an
implementation-defined signal is raised."
Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?

However, the point was raised - and many of us considered it a good one
- that the C89 Standard *requires* the silent generation of a nonsense
value with no easy way to detect that fact. In some programming
situations ("mission-critical code"), you'd much rather the compiler
generated code to trap this case and alert you in some way - a panic is
far better than a bad value slipping into a later calculation.


Note that not everybody involved agrees with that reasoning.
In fact this is fundamentally flawed, since such conversions
can occur at translation time (within the #if constant-
expression) but the signal is an execution-time notion.
Nov 13 '05 #13
In <iS**************@romana.davros.org> "Clive D. W. Feather" <cl***@on-the-train.demon.co.uk> writes:
In article <3f***********************@news.optusnet.com.au> , Simon Biber
<ne**@ralminNOSPAM.cc> writes
Added comp.std.c - we are discussing the effect of conversion of
an out-of-range value to a signed integer type, as in C99 6.3.1.3#3
"either the result is implementation-defined or an
implementation-defined signal is raised."[...]
Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


No.

However, the point was raised - and many of us considered it a good one
- that the C89 Standard *requires* the silent generation of a nonsense
value with no easy way to detect that fact.


C89 offers a very easy way of detecting it, where it actually matters:
compare the value before the conversion to the limits of the target type.

It also allows the detection of these limits, when they are not known at
compile time (see below).
In some programming
situations ("mission-critical code"), you'd much rather the compiler
generated code to trap this case and alert you in some way - a panic is
far better than a bad value slipping into a later calculation.
A panic is seldom desirable in mission-critical code and there is no way
to recover after the generation of such a signal without invoking
undefined behaviour. Therefore, mission-critical code has to do it the
C89 way, anyway.
So we decided to offer this option to the compiler writer. There's no
requirement to take it, but it's available.


It breaks portable C89 code that attempts to find the maximum value
that can be represented in an unknown signed integer type, say type_t:

unsigned long max = -1;

while ((type_t)max < 0 || (type_t)max != max) max >>= 1;

So, it is perfectly possible to write C89 code that is immune to
nonsensical values resulting from the conversion. There is NO way
to rewrite this code in *portable* C99.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #14
In comp.std.c Simon Biber <ne**@ralminnospam.cc> wrote:

Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


Because raising an "overflow" signal is an entirely reasonable thing to
do in that situation. In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not, but in C99 it's
perfectly clear that it does not, so the explicit license was added.

-Larry Jones

This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin
Nov 13 '05 #15
At Tue, 30 Sep 2003 14:52:05 GMT, "Douglas A. Gwyn" <DA****@null.net> writes:
In fact this is fundamentally flawed, since such conversions
can occur at translation time (within the #if constant-
expression) but the signal is an execution-time notion.


But doesn't the standard require a diagnostic if compile-time signed
integer overflow occurs, even in a preprocessor expression?

Perhaps the wording of the standard is flawed, but is there anything
wrong with the intent here? The intent seems to be that compile-time
overflow detection is required, and run-time overflow detection is
allowed but not required.
Nov 13 '05 #16
"Clive D. W. Feather" <cl***@on-the-train.demon.co.uk> wrote in message news:<iS**************@romana.davros.org>...
However, the point was raised - and many of us considered it a good one
- that the C89 Standard *requires* the silent generation of a nonsense
value
No, it *requires* the silent generation of an implementation-defined
result. It does not require a nonsensical definition - implementations
can define it no more or less nonsensically than the unsigned case,
for example.
with no easy way to detect that fact. In some programming
situations ("mission-critical code"), you'd much rather the compiler
generated code to trap this case and alert you in some way - a panic is
far better than a bad value slipping into a later calculation.
In some programming situations ("mission-critical code") you'd
much rather be using a language with a coherent concept of range
types. Even if you go to the expense of implementing traps on
smaller-than-word signed types and bitfields, you still only have
a partial solution to the underlying requirement.
So we decided to offer this option to the compiler writer. There's no
requirement to take it, but it's available.


So why not offer that option for conversion-to-unsigned as well?
Or for overflow on unsigned values generally? Just the other day
I was looking at this:

typedef unsigned int Bool;

struct S {
Bool flag:1;
};

#define MYFLAG 0x8000

void f(long n, struct S *sp) {
Bool x = n & MYFLAG; /* oops */
sp->flag = x; /* oops */
}
Nov 13 '05 #17
la************@eds.com wrote in message news:<ht************@jones.homeip.net>...
In comp.std.c Simon Biber <ne**@ralminnospam.cc> wrote:
Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


Because raising an "overflow" signal is an entirely reasonable thing to
do in that situation. In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not


It was entirely clear that it did.

It was also entirely clear that 3.2.1.2 did not use the phrase
"implementation-defined behavior". What it said was "if the
value cannot be represented the result is implementation-defined".
Nov 13 '05 #18
In comp.lang.c la************@eds.com wrote:
In comp.std.c Simon Biber <ne**@ralminnospam.cc> wrote:

Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


Because raising an "overflow" signal is an entirely reasonable thing to
do in that situation. In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not, but in C99 it's
perfectly clear that it does not, so the explicit license was added.


It's a pity it wasn't disabled by default, with the program
having to do something explicit to enable signal on overflow.

- Kevin.

Nov 13 '05 #19
In <ht************@jones.homeip.net> la************@eds.com writes:
In comp.std.c Simon Biber <ne**@ralminnospam.cc> wrote:

Why was the 'implementation-defined signal' for signed integer
conversions added in C99? Was there some implementation that
required it, in order to be conforming?


Because raising an "overflow" signal is an entirely reasonable thing to
do in that situation. In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not, but in C99 it's
perfectly clear that it does not, so the explicit license was added.


The C89 text is perfectly clear:

... if the value cannot be represented the result is
implementation-defined.

So, it is only *the result* that is implementation-defined, not any other
aspect of the program's behaviour.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #20
Dan Pop (Da*****@cern.ch) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?

Vague.
Right,

MartinS
Nov 13 '05 #21
In <bl**********@antares.lu.erisoft.se> ep****@lu.erisoft.se (Martin Stromberg) writes:
Dan Pop (Da*****@cern.ch) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?

Vague.


Not vague at all, if read in context. There is no "return value" at all
involved, BTW.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #22
On Wed, 1 Oct 2003, Martin Stromberg wrote:
Dan Pop (Da*****@cern.ch) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?
It must be a value, yes.
Vague.


Perhaps, but trying to make sense of isolated sentences from the standard
will seldom get you anywhere. 6.2p.1 says

"Several operators convert operand values from one type to another
^^^^^^^ ^^^^^^
automatically. This subclause specifies the result from such an
^^^^^^
implicit conversion, ..."
^^^^^^^^^^

Since a conversion is defined as an operation that yields a *value*, the
*result* of a conversion must be a value.

--
au***@axis.com
Nov 13 '05 #23
On 2003-10-01 14:36, Johan Aurér <au***@axis.com> wrote:
On Wed, 1 Oct 2003, Martin Stromberg wrote:

[...]
So "the result" can't be the programs behaviour but must be the return
value?


It must be a value, yes.
Vague.


Perhaps, but trying to make sense of isolated sentences from the standard
will seldom get you anywhere. 6.2p.1 says

"Several operators convert operand values from one type to another
^^^^^^^ ^^^^^^
automatically. This subclause specifies the result from such an
^^^^^^
implicit conversion, ..."
^^^^^^^^^^

Since a conversion is defined as an operation that yields a *value*, the
*result* of a conversion must be a value.


....or a trap representation?

-- Niklas Matthies
Nov 13 '05 #24
I wrote:

In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not
In comp.std.c Al Grant <al*****@myrealbox.com> wrote:
It was entirely clear that it did.
In comp.std.c Dan Pop <Da*****@cern.ch> wrote:
The C89 text is perfectly clear: [...] So, it is only *the result* that is implementation-defined, not any other
aspect of the program's behaviour.


Thank you for proving my point, gentlemen.

-Larry Jones

Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin
Nov 13 '05 #25
In comp.std.c Kevin Easton <kevin@-nospam-pcug.org.au> wrote:

It's a pity it wasn't disabled by default, with the program
having to do something explicit to enable signal on overflow.


That's up to the implementation. I know of implementations that allow
integer overflow to be detected, but I don't know of any that do so by
default.

-Larry Jones

In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks. -- Calvin
Nov 13 '05 #26
Dan Pop (Da*****@cern.ch) wrote:
: In <bl**********@antares.lu.erisoft.se> ep****@lu.erisoft.se (Martin Stromberg) writes:
: >So "the result" can't be the programs behaviour but must be the return
: >value?
: >
: >Vague.

: Not vague at all, if read in context. There is no "return value" at all
: involved, BTW.

Errhm... For some reason I thought we were talking about strtol() or
similar. Now looking at the whole thread again, I see we wasn't.

Sorry.
Right,

MartinS
Nov 13 '05 #27
la************@eds.com wrote in message news:<aq************@jones.homeip.net>...
I wrote:

In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not


In comp.std.c Al Grant <al*****@myrealbox.com> wrote:

It was entirely clear that it did.


In comp.std.c Dan Pop <Da*****@cern.ch> wrote:

The C89 text is perfectly clear:

[...]
So, it is only *the result* that is implementation-defined, not any other
aspect of the program's behaviour.


Thank you for proving my point, gentlemen.


You have ignored the rest of my post:

It was also entirely clear that 3.2.1.2 did not use the phrase
"implementation-defined behavior". What it said was "if the
value cannot be represented the result is implementation-defined".

As far as I can tell Dan Pop and I have both read the standard
in the same way. You appear not to have read it at all in that
you are asking about the interpretation of a phrase that doesn't
even occur in the part of the standard under discussion.
Nov 13 '05 #28
In <sl*****************************@nmhq.net> Niklas Matthies <ne*************@nmhq.net> writes:
On 2003-10-01 14:36, Johan Aurér <au***@axis.com> wrote:
On Wed, 1 Oct 2003, Martin Stromberg wrote:

[...]
So "the result" can't be the programs behaviour but must be the return
value?


It must be a value, yes.
Vague.


Perhaps, but trying to make sense of isolated sentences from the standard
will seldom get you anywhere. 6.2p.1 says

"Several operators convert operand values from one type to another
^^^^^^^ ^^^^^^
automatically. This subclause specifies the result from such an
^^^^^^
implicit conversion, ..."
^^^^^^^^^^

Since a conversion is defined as an operation that yields a *value*, the
*result* of a conversion must be a value.


...or a trap representation?


No such thing in C89, the standard we're talking about.

And I doubt that even in C99, a trap representation is a valid option when
the standard specifies an implementation-defined value.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #29
In comp.lang.c la************@eds.com wrote:
In comp.std.c Kevin Easton <kevin@-nospam-pcug.org.au> wrote:

It's a pity it wasn't disabled by default, with the program
having to do something explicit to enable signal on overflow.


That's up to the implementation. I know of implementations that allow
integer overflow to be detected, but I don't know of any that do so by
default.


So there wouldn't have been any impediment to making that the mandated
behaviour then... :)

- Kevin.

Nov 13 '05 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: David Morgenthaler | last post by:
How does one overide the iterator implied by the construct "for line in file:"? For example, suppose I have a file containing row,col pairs on each line, and I wish to write a subclass of file...
3
by: mclaugb | last post by:
I am trying to pass the name of several files to a python script as command line arguments. When i type in python ImportFiles_test.py C:\Program Files\National Instruments\LabVIEW...
0
by: Matthew Heironimus | last post by:
According to the XML 1.0 (Third Edition) W3C Recommendation (http://www.w3.org/TR/2004/REC-xml-20040204/#sec-line-ends) all #xD, #xA, and #xD#xA character combinations should be converted to a...
1
by: Matthew Heironimus | last post by:
According to the XML 1.0 (Third Edition) W3C Recommendation (http://www.w3.org/TR/2004/REC-xml-20040204/#sec-line-ends) all #xD, #xA, and #xD#xA character combinations should be converted to a single...
28
by: Colin JN Breame | last post by:
Hi, Fairly new to C. What is the best way to read a line (\n terminated) from a file? Ive looked at fscanf but was not sure which format specifier to use. (%s perhaps). Thanks Colin
6
by: Kobu | last post by:
Do the "larger" input functions like scanf, gets, fgets use fgetc to take input or an operating system call function like read() (I know it could be any "way", but I'm trying to find out how it's...
9
by: kernelxu | last post by:
hi,everybody. I calling function setbuf() to change the characteristic of standsrd input buffer. some fragment of the progrem is: (DEV-C++2.9.9.2) #include <stdio.h> #include <stdlib.h> int...
8
by: Andrew Robert | last post by:
Hi Everyone. I tried the following to get input into optionparser from either a file or command line. The code below detects the passed file argument and prints the file contents but the...
19
by: =?Utf-8?B?QnJpYW4gQ29vaw==?= | last post by:
This is an example of the data; 2007/07/27 11:00:03 ARES_INDICATION 010.050.016.002 404.2.01 (6511) RX 74 bytes 2007/07/27 11:00:03 65 11 26 02 BC 6C AA 20 76 93 51 53 50 76 13 48...
11
by: JWest46088 | last post by:
I'm having difficulty trying to figure out how to print a text file from a hash table one line at a time. I have the text file read into the hash table and can print the text file all at once, but I...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.