scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc.

[Jordan Abel]

I thought feof(), not EOF, was the preferred method for ANSI C to check
end-of-file. Am I mistaken?

Both are valid and well-defined in ANSI C. They have different
semantics, and EOF lends itself better to the most common idioms for
looping over input.

 

[Antoine Leca]

En news:[email protected], CBFalconer va escriure:

Took a quick look, and I think it is ignoring real work going on
in the C world.

What do you mean?
- the dTR is ignoring part of the C world:
correct, but neither does it pretend to encompass it as a whole;
- the dTR is never applied anywhere:
this would be wrong;
- some points escaped to the committee:
I guess you are allowed to share your concerns ;-); however you
probably should check the previous comments done so far.

Glaringly obvious are missing references to strlcat and strlcpy
from FreeBSD,

The origin is more OpenBSD than FreeBSD, as far as I know.

You shoud read the rationale (N1147) before commenting in such a way.
Obviously strlcpy() and strlcat() were considered, and discarded (1.1.15,
6.7.1.3, 6.7.2.1).

which make much more sense than the proposals.

Perhaps. But given your first comment above, I am not sure you have a better
understanding of the objectives of the TR than the committee; as such, I am
not at ease to give you full credit at this point about the relative
sensitiveness of both proposals (please note I am not saying the committee
is full correct either.)


Another position could be to discard completely the proposed TR (and stay
with strlcpy()). Be sure you certainly will not be alone in such a position.
I even believe the majority will be in this position.

It is very different from the C Standard in this respect. Trying to
masquerade the TR as a new evolution of the C Standard is going the wrong
way (I think).
Thinking the future of the C language would be constrained to this TR is
even more wrong, and this is should be clear enough.


Antoine

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

int main(void)

Just a small thing: charInput should not be an array, right? getchar
doesn't overwrite anything in the address after charInput (at index[1]
or at charInput[2]) or something, right?

First character can be EOF or '\n', you should compare charInput to those
values and take desired action. Maybe you want to do it this way or maybe
not:

if (charInput==EOF)
break;

if (charInput=='\n')
continue;




You will have to check why the previous while loop exited. That would be
because EOF or newline was encoutered. You should take action not to read
beyond EOF, the same way as above.

I did just as you proposed. Looks fine to me...

When you exit the above while loop, you have to determine why it exited.
Maybe you reached EOF before 'y'/'n' were typed.

Yeah, you're right. I have to check for EOF here too, I guess. I assume
my program is pretty much bulletproof now, right?:

--------
#include <stdio.h>

int main(void)
{
int charInput, tmp;

do
{
printf("\nWrite to result.txt (y/n)? ");
charInput = getchar();


if (charInput==EOF)
break;
if (charInput=='\n')
continue;

do {
tmp = getchar();
} while(EOF != tmp && '\n' != tmp);

}
while (charInput != 'y' && charInput != 'n' && charInput != EOF);

printf("Thank you very much\n");
printf("You typed: %c\n", charInput);

return 0;
}

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Jordan Abel wrote:
-snip-

The most common reason for this is if you fail to check for an
end-of-file condition and break a loop. This is most commonly from using
scanf incorrectly, but the issue exists with many other functions.

Damn. You're right... See this output now:

../a.out

Write to result.txt (y/n)? a

Write to result.txt (y/n)? Thank you very much
You typed: ?

Interesting to me to see that it writes: "You typed: ?" as a response to
ctrl+D...

For example, if you're re-prompting if the character input is not 'y' or
'n' - well, end-of-file is neither. If you're using scanf, it's nothing
at all. [the pointed-at object is not assigned to]

Makes sense... Can you also explain why ctrl+d => "You typed: ?"


Best regards / Med venlig hilsen
Martin Jørgensen

 

[Keith Thompson]

int main(void)

Just a small thing: charInput should not be an array, right? getchar
doesn't overwrite anything in the address after charInput (at index[1]
or at charInput[2]) or something, right?

getchar() doesn't overwrite anything; it just returns a value. If you
assign that value to a variable, there's no way it can overwrite
anything else.

[...]

#include <stdio.h>

int main(void)
{
int charInput, tmp;

do
{
printf("\nWrite to result.txt (y/n)? ");
charInput = getchar();


if (charInput==EOF)
break;
if (charInput=='\n')
continue;

do {
tmp = getchar();
} while(EOF != tmp && '\n' != tmp);

}
while (charInput != 'y' && charInput != 'n' && charInput != EOF);

printf("Thank you very much\n");
printf("You typed: %c\n", charInput);

return 0;
}

I haven't checked your program for correctness, but I have a style
comment. Some C programmers write variable tests as
if (42 == x)
to avoid the error of writing "=" rather than "=="; if you
inadvertently write
if (x = 42)
rather than
if (x == 42)
the compiler won't (necessarily) catch your error, but if you write
if (42 = x)
when you meant
if (42 == x)
the compiler will certainly complain.

Personally, I find the reversed form almost unbearably ugly (and not
particularly useful for "!=") , but I understand the rationale for
using it. In your program, you don't use it consistently; some tests
have the constant on the right, some have the constant on the left.
Consistency is your friend.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Keith Thompson wrote:
-snip-

Personally, I find the reversed form almost unbearably ugly (and not
particularly useful for "!=") , but I understand the rationale for
using it. In your program, you don't use it consistently; some tests
have the constant on the right, some have the constant on the left.
Consistency is your friend.

Oh, thanks for the comment. I also find it a bit ugly and also wondered
why someone here in this group suggested it... But your explanation
answers this "reversed behaviour". I myself am however not very afraid
of missing an = sign in a logical test ( I think I'll quickly find out
anyway ), so I think I'll change the program so the variables always are
on the left-hand-side - That looks nicer IMO...


Best regards / Med venlig hilsen
Martin Jørgensen

 

[stathis gotsis]

#include <stdio.h>

int main(void)
{
int charInput, tmp;

do
{
printf("\nWrite to result.txt (y/n)? ");
charInput = getchar();


if (charInput==EOF)
break;
if (charInput=='\n')
continue;

do {
tmp = getchar();
} while(EOF != tmp && '\n' != tmp);

[1]: Consider breaking the outer loop if tmp==EOF. You should not read the
input stream beyond EOF.

}
while (charInput != 'y' && charInput != 'n' && charInput != EOF);

charInput!=EOF is not a needed condition, as charInput cannot be equal to
EOF at this point. Consider: while (charInput != 'y' && charInput != 'n' &&
tmp!= EOF); which also includes [1].

printf("Thank you very much\n");
printf("You typed: %c\n", charInput);

Check if charInput equals EOF before typing it.

 

[stathis gotsis]

Jordan Abel wrote:
-snip-

The most common reason for this is if you fail to check for an
end-of-file condition and break a loop. This is most commonly from using
scanf incorrectly, but the issue exists with many other functions.

Damn. You're right... See this output now:

./a.out

Write to result.txt (y/n)? a

Write to result.txt (y/n)? Thank you very much
You typed: ?

Interesting to me to see that it writes: "You typed: ?" as a response to
ctrl+D...

For example, if you're re-prompting if the character input is not 'y' or
'n' - well, end-of-file is neither. If you're using scanf, it's nothing
at all. [the pointed-at object is not assigned to]

Makes sense... Can you also explain why ctrl+d => "You typed: ?"

You should not print EOF using the %c format specifier. Try %d instead.

 

[Michael Mair]

You should not print EOF using the %c format specifier. Try %d instead.

.... because EOF is not a character but a condition indicator.

-Michael

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

stathis gotsis wrote:
-snip-

You should not print EOF using the %c format specifier. Try %d instead.

No way...

Write to result.txt (y/n)? o

Write to result.txt (y/n)? u7

Write to result.txt (y/n)? n
Thank you very much
You typed: 110


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

-snip-

[1]: Consider breaking the outer loop if tmp==EOF. You should not read the
input stream beyond EOF.

}
while (charInput != 'y' && charInput != 'n' && charInput != EOF);

charInput!=EOF is not a needed condition, as charInput cannot be equal to
EOF at this point. Consider: while (charInput != 'y' && charInput != 'n' &&
tmp!= EOF); which also includes [1].

printf("Thank you very much\n");
printf("You typed: %c\n", charInput);

Check if charInput equals EOF before typing it.

Thanks. Modified the program.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-15?Q?Martin_J=F8rgensen?=]

Michael Mair wrote:
-snip-

... because EOF is not a character but a condition indicator.

Thanks.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[pete]

stathis gotsis wrote:

No way...

You should not print EOF using the %c format specifier.
There is no EOF character.

 

[Richard G. Riley]

Keith Thompson wrote:
-snip-


Oh, thanks for the comment. I also find it a bit ugly and also wondered
why someone here in this group suggested it... But your explanation
answers this "reversed behaviour". I myself am however not very afraid
of missing an = sign in a logical test ( I think I'll quickly find out
anyway ), so I think I'll change the program so the variables always are
on the left-hand-side - That looks nicer IMO...

It is also far more natural to read. Unless you are from the east I
guess

The "1!=func()" style is an abomination IMO.

As is having 1s and 0s in logic conditions. A staple of knowing,
reading and maintaining C is knowing Null, non null, true, false etc.

 

[pete]

It is also far more natural to read. Unless you are from the east I
guess

The "1!=func()" style is an abomination IMO.

There is no "1!=func()" style.

There's no variable there
to put on either the left or the right hand side
of the inequality operator.

 

[Richard G. Riley]

There is no "1!=func()" style.

There's no variable there
to put on either the left or the right hand side
of the inequality operator.

It was en example : but that aside I don't understand what you
mean. By "style" I was referring to the convention some adopt of (a)
putting the logical value in a condition and (b) putting it on the
left hand side of a comparison.

But, to extend:

if(1==successOrFail(paramater)){
doSomething();
}

For me (and it is purely personal) and many others it is (a)
unnecessary and (b) reads badly when code reviewing.

Hope this is clearer.

 

[pete]

It was en example : but that aside I don't understand what you
mean. By "style" I was referring to the convention some adopt of (a)
putting the logical value in a condition and (b) putting it on the
left hand side of a comparison.

That's not what they're talking about.

They're talking about placing a *variable* on either
the right or left hand side of the inequality operator.

The advantage to writing (5 == a) over writing (a == 5),
is if there is a typographical error and an equal sign is misplaced,
(5 = a) won't compile, whereas
(a = 5) might be an error which is difficult to notice.

 

[Michael Wojcik]

[regarding placing constants on the LHS of ==]

It is also far more natural to read.

Since C source code is not found in nature, and reading is learned
behavior, this seems extremely dubious.

In the (rarely enlightening) debates over this and other points of
style, people frequently advance claims about what is more "natural"
or "intuitive" or "readable". Yet they almost never cite any actual
evidence to support them, perhaps because none exists.

The "1!=func()" style is an abomination IMO.

And this contributes what to the discussion?

Keith's response described the common argument in favor of the style,
and noted only in passing that he did not find it compelling. Telling
us that *you* do or do not like it is nothing more than flamebait.

Disagreements over style are far more likely to be religious wars than
reasonable discussions. Let's not promote them here.

--
Michael Wojcik (e-mail address removed)

[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_

 

[Richard G. Riley]

[regarding placing constants on the LHS of ==]

It is also far more natural to read.

Since C source code is not found in nature, and reading is learned
behavior, this seems extremely dubious.

If you believe this then there really is no point discussing
further. We read from left to right here and in C code and ti has been
the concention from day one in 99% of C code in industry.

In the (rarely enlightening) debates over this and other points of
style, people frequently advance claims about what is more "natural"
or "intuitive" or "readable". Yet they almost never cite any actual
evidence to support them, perhaps because none exists.

Are you trolling?

And this contributes what to the discussion?

The thread had moved to that. What is your contribution here other
than to be purposely obnoxious and trying to put forward some Micky
Mouse intellectual hyperbole about how "natural reading of C" doesnt exist?

Keith's response described the common argument in favor of the style,
and noted only in passing that he did not find it compelling. Telling
us that *you* do or do not like it is nothing more than flamebait.

How flamebait. I was supoporting a point. Whyt exactly are you
offering here other than stirring it up?

Disagreements over style are far more likely to be religious wars than
reasonable discussions. Let's not promote them here.

As you appear to have proven. There were no "religious" arguments :
only perferred methods with reasons to support them. It is a
discussion group. Things get discussed althoutgh I do notice a
tendency from some of you to try and control things to your own
"style" - just as likely to offend and promote this type of response.

 

[Douglas A. Gwyn]

En news:[email protected], CBFalconer va escriure:
I guess you are allowed to share your concerns ;-); however you
probably should check the previous comments done so far.
... You shoud read the rationale (N1147) before commenting in such a way.
... But given your first comment above, I am not sure you have a better
understanding of the objectives of the TR than the committee; ...

Indeed, the same issues Falconer raised were already debated
in much more depth with input from a wide variety of
perspectives. If he wants to make a positive contribution
to the development of the TR at this late stage, the minimum
he needs to do is to review its stated goals and prior
discussion. One important goal was that it be possible to
more-or-less automatically convert existing "risky" code to
use the new facilities. Most if not all of the people doing
the actual work are aware that no approach along these lines
can guarantee safety or security; the goals are more modest.