Why GCC does warn me when I using gets() function for accessing file

[Keith Thompson]

(e-mail address removed) writes: [...]

So what are you defending?

Just this: Given that gets() is defined by the standard, a conforming
implementation must implement it properly. gets() does not always
invoke undefined behavior. In those cases where it doesn't, it must
behave as specified.

You're a broken record. I have asked and you have not explained the
difference between undefined behavior and sometimes undefined behavior.

[...]

The difference is the word "sometimes".

I'm done here.

 

[Philip Potter]

You're a broken record. I have asked and you have not explained the
difference between undefined behavior and sometimes undefined behavior.

UB is undefined behaviour, and the implementation can do as it likes.

Sometimes UB is sometimes undefined behaviour, depending on a certain
condition, and the implementation can sometimes do as it likes. When the
condition does not hold, it has behaviour which is specifically defined by
the standard. If the implementation does not implement this behaviour, it is
nonconforming.

Philip

 

[Michael Wojcik]

I did not say that "the C language does not contain variables". (If I
did, please cite the article in which I said that.) I said that the C
standard does not define the term "variable".

The relevant quote:

" [...] It is not obvious what the word "variable" should mean in the
context of C. [...]"

Which is entirely as Keith characterized it, and not as you did.
Either you failed (and continue to fail) to comprehend what he
wrote in that post, or you're being deliberately dense.

It *isn't* obvious what "variable" means in C - at least not to
anyone who understands the language. It's not obvious whether the
term should apply to const-qualified objects, for example, because
practitioners use "variable" to mean a number of things, and only
some of them apply to const-qualified objects.

What the hell are you talking about? If you think "the stack" means a
hardware stack, its because of something in your mind.

Keith didn't say *he* thought the phrase "the stack" necessarily
applied to a hardward stack. He said that phrase is sometimes used
with that meaning. I'll go further and note that often when people
post here asking about "the stack", that's what they have in mind
(for questions like "how can I tell if a variable is on the stack?").

(And "its" is a possessive pronoun; the contraction for "it is" is
"it's". And obviously if Keith thinks something means something
else, it's because of something in his mind, by definition. That's
the faculty we employ when we think and produce meaning.)

Really, Paul, your ability to misconstrue what you read is
remarkable. If you must continue these rants, do try to interpret
something correctly and come up with an actual meaningful argument
- it'd be a refreshing change.

 

[Keith Thompson]

Philip Potter wrote:


AFAIK, UB doesn't include breaking on compilation.

Yes, it does.

C99 3.4.3:

undefined behavior

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

 

[goose]

Philip Potter wrote:

well-defined behaviour, even if only in unrealistic situations. If gets()
did have completely undefined behaviour, it would be trivial to remove it
from the standard, since none of the programs which use it had defined
behaviour anyway.

AFAIK, UB doesn't include breaking on compilation.

 

[Michael Wojcik]

AFAIK, UB doesn't include breaking on compilation.

It could, in some cases. If the program's output depends on UB -
which it would, if the program actually invokes UB during execution -
then the program is not strictly conforming and no conforming
implementation has to accept it. (9899-1999 4 #5,#6)

However, I think the following is a strictly-conforming program:

#include <stdio.h>
int main(void)
{
char x;
if (0) gets(x);
return 0;
}

Its output never depends on UB, because the gets() is never
executed. Thus conforming implementations would have to accept
it.

So I think you're correct in the end: even if gets() always
caused UB if it was called, strictly-conforming programs could
include calls to it provided they were never executed, so it
would have to be present at least as an identifier for a
function of the appropriate type.

 

[Keith Thompson]

However, I think the following is a strictly-conforming program:

#include <stdio.h>
int main(void)
{
char x;
if (0) gets(x);
return 0;
}

Not quite, but I think it is if you change the declaration of x to:

char *x;

*or* change the if statement to:

if (0) gets(&x);

(but not both, obviously).

 

[Steve Summit]

If you want to have a non-conforming C implementation that discourages
gets(), just reject any program that calls it. If you want to have a
*conforming* C implementation that discourages gets(), issue a warning
(as gcc does).

In all seriousness, what if someone chose to implement gets along
the (mildly non-conforming) lines of:

char *gets(char *retbuf)
{
return fgets(retbuf, 100, stdin);
}

There would also need to be a bit of code to remove the newline,
of course.

This could be combined with gcc's existing compile-time warning,
so that users whose input was always small would also be alerted
to their problem.

 

[Keith Thompson]

In all seriousness, what if someone chose to implement gets along
the (mildly non-conforming) lines of:

char *gets(char *retbuf)
{
return fgets(retbuf, 100, stdin);
}

There would also need to be a bit of code to remove the newline,
of course.

This could be combined with gcc's existing compile-time warning,
so that users whose input was always small would also be alerted
to their problem.

Doug Gwyn suggested something similar over in comp.std.c, using BUFSIZ
rather than 100.

 

[Michael Wojcik]

Not quite, but I think it is if you change the declaration of x to:

char *x;

*or* change the if statement to:

if (0) gets(&x);

Posting-without-testing strikes again.

Thanks, Keith.