gets problem

On Sun, 2006-12-11 at 21:54 -0800, Zulander wrote:

Hi,
have a problem with comparing text in my function for some reason my
code get hang at fgets.
i am uploading this code in an IC, but i have isolated the problem to
fgets(SettingInfo);
could anyone help me
thank you

[snipped "code"]

You need to learn C, especially the fgets() function.

Here is your code, with formatting, variable names, comments, and
operator abuse corrected:

void myfunc(void)
{
const char snd[] = "REQ"; /* SeND system information */
const char set[] = "SET"; /* SET system information */
char inp[30];

fgets(inp);
printf("Got info: %s", inp);

if(strcmp(inp, *snd) == 0)
SendSetting();

if(strcmp(inp, *set) == 0)
{
int i = 0;
while(i <= 1)
{
switch(i)
{
case 0:
gets(inp);
delay = atoi(inp);
break;
default:
i = 3;
break;
}
++i;
}
}
}

I'll reply with critique, so that the code and my comments are clearly
differentiated by the ""'s.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

Nov 13 '06 #2

sam_cit

6 char SettingInfo[30];
7
8 fgets(SettingInfo);
9 printf("got info %s",SettingInfo);

Hi,
Are you trying to fill in the array with input from Keyboard or
from file, i think gets() is used for inputs through keyboard and fgets
from file... Hope it helps.

Nov 13 '06 #3

On Mon, 2006-13-11 at 06:17 +0000, Andrew Poelstra wrote:

On Sun, 2006-12-11 at 21:54 -0800, Zulander wrote:
Hi,
have a problem with comparing text in my function for some reason my
code get hang at fgets.

No it doesn't. The first compile-time error is at fgets.

i am uploading this code in an IC, but i have isolated the problem to
fgets(SettingInfo);

Well, you aren't very good at isolating, then.

could anyone help me
thank you
[snipped "code"]

You need to learn C, especially the fgets() function.

Here is your code, with formatting, variable names, comments, and
operator abuse corrected:

void myfunc(void)
{
const char snd[] = "REQ"; /* SeND system information */
const char set[] = "SET"; /* SET system information */
char inp[30];

fgets(inp);

1. Include <stdio.h>.
2. Use the proper syntax for fgets():
fgets(inp, sizeof inp, stdin);

printf("Got info: %s", inp);

if(strcmp(inp, *snd) == 0)
SendSetting();

Uh... *snd is a char. strcmp wants a pointer to char. If you had
included <string.hyou would know that.

>
if(strcmp(inp, *set) == 0)

Ditto.

{
int i = 0;
while(i <= 1)
{
switch(i)
{
case 0:
gets(inp);
delay = atoi(inp);
break;
default:
i = 3;
break;
}
++i;
}

There are so many things wrong with that snippit that I'll just
rewrite the whole thing:

fgets(inp, sizeof inp, stdin);
delay = atoi(inp);

}
}

(i is also assigned the value 4, but it's lost as the function ends.)

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

Nov 13 '06 #4

On Sun, 2006-12-11 at 22:20 -0800, sa*****@yahoo.co.in wrote:

6 char SettingInfo[30];
7
8 fgets(SettingInfo);
9 printf("got info %s",SettingInfo);

Hi,
Are you trying to fill in the array with input from Keyboard or
from file, i think gets() is used for inputs through keyboard and fgets
from file... Hope it helps.

No, gets() is used for viruses, and fgets() is used to obtain
a line of input. Whether that's from a keyboard, a file, a
tape, or a Geiger counter is irrelevant.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

Nov 13 '06 #5

On Mon, 2006-13-11 at 06:22 +0000, Andrew Poelstra wrote:

fgets(inp, sizeof inp, stdin);
delay = atoi(inp);

Silly me, I meant
delay = strtol(inp);

atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

Nov 13 '06 #6

Ian Collins

sa*****@yahoo.co.in wrote:

>>6 char SettingInfo[30];
7
8 fgets(SettingInfo);
9 printf("got info %s",SettingInfo);

Hi,
Are you trying to fill in the array with input from Keyboard or
from file, i think gets() is used for inputs through keyboard and fgets
from file... Hope it helps.

gets() should never be used for anything other than demonstrating why
gets() should never be used.

But you are correct that the last two parameters, the size and the
FILE*, for fgets() are missing.

--
Ian Collins.

Nov 13 '06 #7

sa*****@yahoo.co.in said:

>
>6 char SettingInfo[30];
7
8 fgets(SettingInfo);
9 printf("got info %s",SettingInfo);

Hi,
Are you trying to fill in the array with input from Keyboard or
from file, i think gets() is used for inputs through keyboard

No, gets() is never used, ever, by anyone with any understanding of C, for
the simple reason that it cannot be used safely.

Is your lack of understanding of C typical among your colleagues? If not,
why haven't they identified and educated you yet?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #8

Ian Collins

Richard Heathfield wrote:

>
Is your lack of understanding of C typical among your colleagues? If not,
why haven't they identified and educated you yet?

Did you get out of the wrong side of the bed this morning?

--
Ian Collins.

Nov 13 '06 #9

Andrew Poelstra said:

On Mon, 2006-13-11 at 06:22 +0000, Andrew Poelstra wrote:
>fgets(inp, sizeof inp, stdin);
delay = atoi(inp);

Silly me, I meant
delay = strtol(inp);

No, you didn't. This won't even compile.

>
atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #10

Ian Collins said:

Did you get out of the wrong side of the bed this morning?

There's a right side?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #11

Bill Pursell

Ian Collins wrote:

gets() should never be used for anything other than demonstrating why
gets() should never be used.

This sentiment is expressed a lot, and I agree with it. However,
it occurred to me that it may be acceptable to use gets() if
you have control of the input. For example, if you <OT>
fork and write into a pipe whose read end is the stdin of
the child.</OT I'll agree that this is pretty pointless,
stylistically a bad idea, and needlessly restricting the
re-usability of the child's functionality, but ...

Never mind. Even trying to play devil's advocate, I can't
come up with a reason to use gets(). It saves you a couple
of keystrokes over fgets(), but in return brings you hours and
hours of debugging headaches. It may be a good idea :^)
to edit your system headers and insert:

#define gets(x) do { \
fputs("This program is deprecated.\n", stderr);\
exit(EXIT_FAILURE); \
} while (0)
:^) Using a smiley as a footnote marker...This is NOT
a good idea, but it mightn't hurt to put something like
that in a commonly used header.

--
Bill Pursell

Nov 13 '06 #12

Ian Collins

Richard Heathfield wrote:

Ian Collins said:

>>Did you get out of the wrong side of the bed this morning?

There's a right side?

I prefer the one not against a wall.

--
Ian Collins.

Nov 13 '06 #13

Ian Collins said:

Richard Heathfield wrote:
>Ian Collins said:

>>>Did you get out of the wrong side of the bed this morning?

There's a right side?

I prefer the one not against a wall.

Ah! Thank you - I *knew* I was doing something wrong...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #14

Richard Heathfield <in*****@invalid.invalidwrites:

Andrew Poelstra said:

[...]

>atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

No, atoi() simply returns 0 on error. atoi(s) is equivalent to
strtol(s, NULL, 10).

--
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.

Nov 13 '06 #15

Keith Thompson said:

Richard Heathfield <in*****@invalid.invalidwrites:
>Andrew Poelstra said:
[...]

>>atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on
whether undefined behaviour can be dangerous. Now think "aeroplane", and
suddenly it becomes, potentially, very dangerous indeed.

No, atoi() simply returns 0 on error. atoi(s) is equivalent to
strtol(s, NULL, 10).

Sorry, Keith, I was using "on error" rather loosely, and I was too lazy to
look up the relevant part of the Standard, which is:

4.10.1 String conversion functions

The functions atof , atoi , and atol need not affect the value of
the integer expression errno on an error. If the value of the result
cannot be represented, the behavior is undefined.

Similar wording appears in n1124.pdf, in section 7.20.1.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #16

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>Andrew Poelstra said:
[...]
>>>atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on
whether undefined behaviour can be dangerous. Now think "aeroplane", and
suddenly it becomes, potentially, very dangerous indeed.

No, atoi() simply returns 0 on error. atoi(s) is equivalent to
strtol(s, NULL, 10).

Sorry, Keith, I was using "on error" rather loosely, and I was too lazy to
look up the relevant part of the Standard, which is:

4.10.1 String conversion functions

The functions atof , atoi , and atol need not affect the value of
the integer expression errno on an error. If the value of the result
cannot be represented, the behavior is undefined.

Similar wording appears in n1124.pdf, in section 7.20.1.

Oops, you're right.

Silly me, I expected the behavior of atoi() to be defined in the
section that describes atoi(). Of course, I should also have noticed
the phrase "Except for the behavior on error" in 7.20.1.2.

--
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.

Nov 13 '06 #17

Keith Thompson said:

<snip>

Silly me, I expected the behavior of atoi() to be defined in the
section that describes atoi().

Well, DUH! :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 13 '06 #18

On Mon, 2006-13-11 at 20:06 +1300, Ian Collins wrote:

Richard Heathfield wrote:

Is your lack of understanding of C typical among your colleagues? If not,
why haven't they identified and educated you yet?
Did you get out of the wrong side of the bed this morning?

No, the problem is that the ratio of gets()-users to non-gets()-users
in this thread is above unity, which I imagine would irritate almost
anyone who wants to help others learn C.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use [first_name].[last]@gmail.com
"You're only smart on the outside." -anon.

Nov 13 '06 #19

On Mon, 2006-13-11 at 07:18 +0000, Richard Heathfield wrote:

Andrew Poelstra said:

On Mon, 2006-13-11 at 06:22 +0000, Andrew Poelstra wrote:
fgets(inp, sizeof inp, stdin);
delay = atoi(inp);
Silly me, I meant
delay = strtol(inp);

No, you didn't. This won't even compile.

I completely missed that.
delay = strtol(inp, NULL, 0);
Where the NULL might be a better value, and the 0 might be 10.

atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

Ah. I thought that it's /return value/ was undefined, which would mean
that's it's only dangerous if you use it for some reason.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use [first_name].[last]@gmail.com
"You're only smart on the outside." -anon.

Nov 13 '06 #20

Tor Rustad

Keith Thompson skrev:

Richard Heathfield <in*****@invalid.invalidwrites:

Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

No, atoi() simply returns 0 on error. atoi(s) is equivalent to
strtol(s, NULL, 10).

Except for the error case, atoi(s) is equivalent to

(int) strtol(s, (char **)NULL, 10)

where strtol() on error returns

1. 0 if s cannot be converted
2. LONG_MAX on overflow error, errno set to ERANGE
3. LONG_MIN on underflow error, errno set to ERANGE

--
Tor <torust AT online DOT no>

Nov 13 '06 #21

"Tor Rustad" <to********@hotmail.comwrites:

Keith Thompson skrev:
>Richard Heathfield <in*****@invalid.invalidwrites:
>
Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

No, atoi() simply returns 0 on error. atoi(s) is equivalent to
strtol(s, NULL, 10).

Except for the error case, atoi(s) is equivalent to

(int) strtol(s, (char **)NULL, 10)

where strtol() on error returns

1. 0 if s cannot be converted
2. LONG_MAX on overflow error, errno set to ERANGE
3. LONG_MIN on underflow error, errno set to ERANGE

Right, but the phrase "Except for the error case" is the critical
piece of information (and the one that I missed in my previous
followup). C99 7.20.1 explicitly says that atoi() invokes undefined
behavior if the value of the result cannot be represented (i.e., on
overflow).

I *suspect* that this was done to allow for existing implementations
of atoi() from before strtol() was introduced, but it seems to me that
this decision allowed for a trivial level of extra convenience for
implementers at the expense of safety for users. The standard could
have said that atoi() returns an implementation-defined result, or
even an unspecified result, if the value of the result cannot be
represented.

--
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.

Nov 13 '06 #22

Richard

Andrew Poelstra <ap*******@false.sitewrites:

On Mon, 2006-13-11 at 20:06 +1300, Ian Collins wrote:
>Richard Heathfield wrote:
>
Is your lack of understanding of C typical among your colleagues? If not,
why haven't they identified and educated you yet?

Did you get out of the wrong side of the bed this morning?

No, the problem is that the ratio of gets()-users to non-gets()-users
in this thread is above unity, which I imagine would irritate almost
anyone who wants to help others learn C.

But the fact is that he (the OP) doesn't know. Maybe he doesn't live here?
Far more polite to point it out rather than come across as Heathfield
does time & time again. If one gets tired of answering the same
questions here then I'd suggest it's time to move on to more "elite"
company.

Nov 14 '06 #23

Richard

Richard Heathfield <in*****@invalid.invalidwrites:

Andrew Poelstra said:

>On Mon, 2006-13-11 at 06:22 +0000, Andrew Poelstra wrote:
>>fgets(inp, sizeof inp, stdin);
delay = atoi(inp);

Silly me, I meant
delay = strtol(inp);

No, you didn't. This won't even compile.

>>
atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

surely atoi is far from useless in a proven system where it can be formally
proven that all inputs are valid ascii representations of integers.

Nov 14 '06 #24

Richard <rg****@gmail.comwrites:

Richard Heathfield <in*****@invalid.invalidwrites:

[...]

>Since its behaviour on error is undefined, that depends largely on whether
undefined behaviour can be dangerous. Now think "aeroplane", and suddenly
it becomes, potentially, very dangerous indeed.

surely atoi is far from useless in a proven system where it can be formally
proven that all inputs are valid ascii representations of integers.

And where you can be certain that the formal proof is 100% bug-free.

Or you can practice a little defensive programming and use strtol()
instead, and check for errors rather than assuming (or proving) that
they can never happen.

--
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.

Nov 14 '06 #25

Richard said:

Andrew Poelstra <ap*******@false.sitewrites:
>Ian Collins wrote:
>>Richard Heathfield wrote:

Is your lack of understanding of C typical among your colleagues? If
not, why haven't they identified and educated you yet?

Did you get out of the wrong side of the bed this morning?

No, the problem is that the ratio of gets()-users to non-gets()-users
in this thread is above unity, which I imagine would irritate almost
anyone who wants to help others learn C.

But the fact is that he (the OP) doesn't know.

It wasn't the OP who suggested using gets(), and it wasn't the OP I was
replying to. The person I was replying to considered themselves
sufficiently experienced in C that they were able to give help to others,
and yet they were recommending the use of gets(). It's like the difference
between a user and a pusher.

Maybe he doesn't live here?

Maybe he doesn't. Maybe he lives in a place where he has a lot of influence
as an experienced C programmer, and where lots of people hang on his every
word because he is the one amongst them who gives advice in comp.lang.c.
Who knows? How is it relevant? What *is* relevant is that he is
promulgating a very dangerous technique.

Far more polite to point it out rather than come across as Heathfield
does time & time again. If one gets tired of answering the same
questions here then I'd suggest it's time to move on to more "elite"
company.

Thank you for your suggestion, which has been noted, and carefully stored in
the usual place reserved for suggestions as clueful, helpful and
constructive as yours.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 14 '06 #26

Richard said:

Richard Heathfield <in*****@invalid.invalidwrites:

>Andrew Poelstra said:

>>atoi() has no error checking, and is therefore almost useless.
(Although not dangerous, I believe.)

Since its behaviour on error is undefined, that depends largely on
whether undefined behaviour can be dangerous. Now think "aeroplane", and
suddenly it becomes, potentially, very dangerous indeed.

surely atoi is far from useless in a proven system where it can be
formally proven that all inputs are valid ascii representations of
integers.

Why assume ASCII? That's rather limiting. Now, let's consider your question.
We have two choices. One of the alternatives is known to exhibit undefined
behaviour when presented with well-formed but erroneous strings, whereas
the other's behaviour is deterministic for any given well-formed input. To
me, it's no contest. But maybe not to you. So tell me - what advantage does
atoi have (other than being slightly quicker to type, which is surely too
trivial to mention) over strtol that can possibly begin to make up for its
undefined behaviour for some well-formed inputs?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

Nov 14 '06 #27

Bill Pursell

Richard Heathfield wrote:

>
It wasn't the OP who suggested using gets(), and it wasn't the OP I was
replying to. The person I was replying to considered themselves
sufficiently experienced in C that they were able to give help to others,
and yet they were recommending the use of gets(). It's like the difference
between a user and a pusher.

It is commonly accepted that the best way to learn anything is to
teach it. Also, to make mistakes. I've often observed that the
best way to ensure responses from the more experienced programmers
in this group is to post answers to questions. If the answers
I give are incorrect, then the resulting corrections are
useful to me and (hopefully) to the OP. One doesn't need
to be an expert to offer advice, and I think this forum
would suffer if people were afraid to offer advice simply
because they aren't experts. I've learned a great deal
about C in the past year or so, and much of that has
been because people have asked questions on this
forum that I attempted to answer.

When someone gives an answer that is incorrect, the
answer must be corrected. However, providing an
incorrect answer does not justify a rude correction
anymore than does asking a simple question. (I'm
not implying that Richard was rude in this case...his
response in this particular case was snipped from
the message before I saw it, and I don't know what
it was.) A less experienced programmer offering
an answer which is wrong is not an evil pusher
leading the blind into destruction--he's just a
less experienced programmer trying to offer
advice. If the advice he gives is wrong, correct
him, but don't lambaste him.

--
Bill Pursell

Nov 14 '06 #28

Tor Rustad

Keith Thompson wrote:

>
I *suspect* that this was done to allow for existing implementations
of atoi() from before strtol() was introduced, but it seems to me that
this decision allowed for a trivial level of extra convenience for
implementers at the expense of safety for users.

The ato{i,f,l}() functions was kept in C90, because they where used
a lot in existing code.

However, in new code the ato{i,f,l}() functions should not be used,
unless the input is known to be in valid range. strtod() and strtol()
are the safe replacements.

The standard could
have said that atoi() returns an implementation-defined result, or
even an unspecified result, if the value of the result cannot be
represented.

Right, they could have, but did not. I know one compiler which
has undefined result, in case of overflow/underflow... another
implementation might have put in an abort handler. So from
a safety point of view, the best solution was perhaps simply to
say stop using these functions.

--
Tor <torust AT online DOT no>

Nov 14 '06 #29

santosh

Richard Heathfield wrote:

sa*****@yahoo.co.in said:

6 char SettingInfo[30];
7
8 fgets(SettingInfo);
9 printf("got info %s",SettingInfo);

Hi,
Are you trying to fill in the array with input from Keyboard or
from file, i think gets() is used for inputs through keyboard

No, gets() is never used, ever, by anyone with any understanding of C, for
the simple reason that it cannot be used safely.

Is your lack of understanding of C typical among your colleagues? If not,
why haven't they identified and educated you yet?

Most of the high school and college textbooks prescribed here still
seem to use gets() and constructs like main() or void main(). Frankly,
far more emphasis is placed on Java than on C, which to me seems a
shame, since C forces more thought into your programming early on.

That's why IMO, this group is invaluable for those whose formal
instruction in C is less than desirable. Despite the intermittent
trolls and occasional flame-war, the advice and insight offered here
are second to none.

Nov 14 '06 #30

Chris Dollin

Richard wrote:

surely atoi is far from useless in a proven system where it can be formally
proven that all inputs are valid ascii representations of integers.

I'd need to be really confident that the proof was sound. Really. Really.
Also I assume you meant "valid ascii representations of integers in the
range atoi can handle". And that the code hadn't changed (possibly
invalidating the proof).

--
Chris "hantwig efferko VOOM!" Dollin
"Who do you serve, and who do you trust?" /Crusade/

Nov 14 '06 #31

"Tor Rustad" <to********@hotmail.comwrites:

Keith Thompson wrote:

[...]

>The standard could
have said that atoi() returns an implementation-defined result, or
even an unspecified result, if the value of the result cannot be
represented.

Right, they could have, but did not. I know one compiler which
has undefined result, in case of overflow/underflow... another
implementation might have put in an abort handler.

I'm not sure what you mean by "I know one compiler which has undefined
result". atoi() exhibits undefined behavior on overflow in *every*
implementation. In some cases, that undefined behavior might be
returning 0, or INT_MAX, or some other consistent result.

Though to be fair, a compiler (more precisely an implementation;
atoi() is likely to be implemented in the runtime library, not the
compiler) could document the behavior.

So from
a safety point of view, the best solution was perhaps simply to
say stop using these functions.

Agreed.

--
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.

Nov 14 '06 #32

Tor Rustad

Keith Thompson wrote:

"Tor Rustad" <to********@hotmail.comwrites:
Keith Thompson wrote:
[...]

The standard could
have said that atoi() returns an implementation-defined result, or
even an unspecified result, if the value of the result cannot be
represented.
Right, they could have, but did not. I know one compiler which
has undefined result, in case of overflow/underflow... another
implementation might have put in an abort handler.

I'm not sure what you mean by "I know one compiler which has
undefined result". atoi() exhibits undefined behavior on overflow in
*every* implementation.

>From the standard point of view, the behavoir is undefined.

However, an implementation is free to provide a definition of UB,
making the behavoir well-defined... for that specific implementation.

--
Tor <torust AT online DOT no>

Nov 14 '06 #33

Kenny McCormack

In article <11**********************@i42g2000cwa.googlegroups .com>,
santosh <sa*********@gmail.comwrote:
....

>instruction in C is less than desirable (*). Despite the intermittent
trolls and occasional flame-war, the advice and insight offered here
are second to none.

Exactly. Worse than nothing.

(*) Yes, certainly the kind you get here is.

Nov 14 '06 #34