K&R 1.5.1 exercise

It's very difficult to do an exercise with elementary tools. It took me
about fifteen minutes to get exercise 1-7:
#include <stdio.h>

int main(int orange, char **apple)
{
int c;
c=-5;
while(c != EOF )
{
c++;
}
printf("%d\t",c);
printf("%d\t",EOF);
return (0);
}
Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I think
it's right.

Exercise 1-6 is giving me dyspepsia. This compiles and links but does not
behave according to my wishes:
#include <stdio.h>

int main(int orange, char **mango)
{
int c;
c=(getchar() != EOF);
printf("%d\t",c);
return (0);
}

I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am at my
wit's end, as I also seem to be unable to debug. Remember, if you kick a
man when he's down, you better make sure he either stays down or he isn't 2
meters tall, 114 kg. ++Thanks. MPJ

On Mon, 11 Oct 2004 21:20:10 -0500, Merrill & Michele wrote:
[color=blue]
> It's very difficult to do an exercise with elementary tools. It took me
> about fifteen minutes to get exercise 1-7:
> #include <stdio.h>
>
> int main(int orange, char **apple)[/color]

Why the bizarre names for these variables? argc and argv, respectively,
have served nearly all C programmers very well.
[color=blue]
> {
> int c;
> c=-5;
> while(c != EOF )
> {
> c++;
> }[/color]

This is trivial enough. You should allow for the possibility for EOF to be
equal to a value like INT_MIN, in which case this program could run a
very, very long time. (Assuming it can wrap around from INT_MAX to INT_MIN
at all, and do so without crashing.)
[color=blue]
> printf("%d\t",c);
> printf("%d\t",EOF);[/color]

You probably want a newline, not a tab, in at least one of these
statements.
[color=blue]
> return (0);
> }
> Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I think
> it's right.[/color]

It will be right, assuming EOF >= -5 on your machine.
[color=blue]
>
> Exercise 1-6 is giving me dyspepsia. This compiles and links but does not
> behave according to my wishes:
> #include <stdio.h>
>
> int main(int orange, char **mango)
> {
> int c;
> c=(getchar() != EOF);[/color]

This is the problem, I think. You're expecting a coherent result from a
very strange statement.
[color=blue]
> printf("%d\t",c);[/color]

ITYM printf("%d\n",c);
[color=blue]
> return (0);
> }
>
> I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am at my
> wit's end, as I also seem to be unable to debug.[/color]

I don't know that either value is guaranteed by the Standard, or
reasonably expectable on any machines.
[color=blue]
> Remember, if you kick a
> man when he's down, you better make sure he either stays down or he isn't 2
> meters tall, 114 kg. ++Thanks. MPJ[/color]

You'll get no kicks from me.

"Merrill & Michele" <beckjensen@comcast.net> wrote:
[color=blue]
> It's very difficult to do an exercise with elementary tools.[/color]

If you mean the exercises from K&R, I found it no problem at all doing
most of them using tools as elementary as paper and pen. Then again...
[color=blue]
> int main(int orange, char **apple)[/color]

....I wasn't wilfully perverse, so maybe, just maybe, if you start taking
it seriously, you would get a bit farther?

Richard

In <cOSdneWdFaLHovbcRVn-ow@comcast.com> "Merrill & Michele" <beckjensen@comcast.net> writes:
[color=blue]
>It's very difficult to do an exercise with elementary tools. It took me
>about fifteen minutes to get exercise 1-7:
>#include <stdio.h>
>
>int main(int orange, char **apple)
>{
> int c;
> c=-5;
> while(c != EOF )
> {
> c++;
> }
> printf("%d\t",c);
> printf("%d\t",EOF);
>return (0);
>}
>Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I think
>it's right.[/color]

Nope, it isn't. Your while loop will eventually cause integer overflow,
which is undefined behaviour in C. Furthermore, it is entirely irrelevant
to your problem, whose solution is as simple as:

#include <stdio.h>

int main()
{
printf("%d\n", EOF);
return 0;
}
[color=blue]
>Exercise 1-6 is giving me dyspepsia. This compiles and links but does not
>behave according to my wishes:
>#include <stdio.h>
>
>int main(int orange, char **mango)
>{
> int c;
> c=(getchar() != EOF);
> printf("%d\t",c);
> return (0);
>}
>
>I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am at my
>wit's end, as I also seem to be unable to debug.[/color]

Your program is almost correct. Replace \t by \n and it is fully correct.
It would have been even better if you used a loop, with getchar() != EOF
evaluating to 0 as the exit condition, but it works even in your version,
if you understand that stdin, when connected to the terminal, is line
buffered. So, nothing will happen until you press the Return/Enter key.
Your platform may require it even after the eof key. After that, your
getchar() call will return the code of the first character you have typed
or EOF if you have typed the corresponding character for your platform
(CTRL-Z for DOS/Windows, CTRL-D for Unix). So, you can expect a 1 as
output most of the time, unless the first character you have typed was
the one generating an end of file condition.

This program is much easier to work with if you use a loop and redirect
stdin from a file:

fangorn:~/tmp 146> cat input
12345
fangorn:~/tmp 147> cat test.c
#include <stdio.h>

int main()
{
int cond;

while ((cond = getchar() != EOF) == 1) printf("%d ", cond);
printf("%d\n", cond);
return 0;
}
fangorn:~/tmp 148> gcc test.c
fangorn:~/tmp 149> ./a.out <input
1 1 1 1 1 1 0

The input file contains 6 characters: the five visible ones (12345)
and the newline character. For each of them, the expression
getchar() != EOF evaluates to 1 and a 1 is displayed in the program
output. The seventh getchar() call generates and end of file condition
on the stream and it returns EOF. At that point, the expression
getchar() != EOF evaluates to 0 and the while loop is terminated.
The corresponding value of the expression is displayed, followed by
the mandatory newline character.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

In <pan.2004.10.12.07.40.35.460427@gmail.com> Chris Barts <chbarts@gmail.com> writes:
[color=blue]
>On Mon, 11 Oct 2004 21:20:10 -0500, Merrill & Michele wrote:
>[color=green]
>> Exercise 1-6 is giving me dyspepsia. This compiles and links but does not
>> behave according to my wishes:
>> #include <stdio.h>
>>
>> int main(int orange, char **mango)
>> {
>> int c;
>> c=(getchar() != EOF);[/color]
>
>This is the problem, I think. You're expecting a coherent result from a
>very strange statement.[/color]

Did you bother reading Exercise 1-6? There is nothing strange here,
except the misleading name of the variable. It leads the experienced
programmer to believe that the idiomatic (c = getchar()) != EOF was
somehow intended, but this is not the case: it is indeed the value of
getchar() != EOF that is the focus of this exercise.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

In <416bae4c.69849792@news.individual.net> rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
[color=blue]
>"Merrill & Michele" <beckjensen@comcast.net> wrote:
>[color=green]
>> It's very difficult to do an exercise with elementary tools.[/color]
>
>If you mean the exercises from K&R, I found it no problem at all doing
>most of them using tools as elementary as paper and pen. Then again...[/color]

You missed his point: elementary C programming elements, not an elementary
execution environment.
[color=blue][color=green]
>> int main(int orange, char **apple)[/color]
>
>...I wasn't wilfully perverse, so maybe, just maybe, if you start taking
>it seriously, you would get a bit farther?[/color]

Since the program did not make *any* use of the main parameters, I fail to
see your point (if any).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

> >It's very difficult to do an exercise with elementary tools. It took me[color=blue][color=green]
> >about fifteen minutes to get exercise 1-7:
> >#include <stdio.h>
> >
> >int main(int orange, char **apple)
> >{
> > int c;
> > c=-5;
> > while(c != EOF )
> > {
> > c++;
> > }
> > printf("%d\t",c);
> > printf("%d\t",EOF);
> >return (0);
> >}
> >Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I think
> >it's right.[/color][/color]
[color=blue]
> Dan wrote:
> Nope, it isn't. Your while loop will eventually cause integer overflow,
> which is undefined behaviour in C. Furthermore, it is entirely irrelevant
> to your problem, whose solution is as simple as:
>
> #include <stdio.h>
>
> int main()
> {
> printf("%d\n", EOF);
> return 0;
> }[/color]

Thanks all for replies. Mr. Pop is correct that his shortened version of my
prog does indeed yield -1, but I liked the idea of trying to find the
appropriate answer with a while{}. Would Mr. Pop have the same criticism if
one began the loop with Mr. Barts' (I know I got your 's' this time, but did
I get the possessive correct?) INT_MIN suggestion, incremented in the usual
fashion, and it were stipulated that an EOF had indeed been #defined as an
int?
[color=blue][color=green]
> >Exercise 1-6 is giving me dyspepsia. This compiles and links but does[/color][/color]
not[color=blue][color=green]
> >behave according to my wishes:
> >#include <stdio.h>
> >
> >int main(int orange, char **mango)
> >{
> > int c;
> > c=(getchar() != EOF);
> > printf("%d\t",c);
> > return (0);
> >}
> >
> >I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am at[/color][/color]
my[color=blue][color=green]
> >wit's end, as I also seem to be unable to debug.[/color]
>
> Your program is almost correct. Replace \t by \n and it is fully correct.
> It would have been even better if you used a loop, with getchar() != EOF
> evaluating to 0 as the exit condition, but it works even in your version,
> if you understand that stdin, when connected to the terminal, is line
> buffered. So, nothing will happen until you press the Return/Enter key.
> Your platform may require it even after the eof key. After that, your
> getchar() call will return the code of the first character you have typed
> or EOF if you have typed the corresponding character for your platform
> (CTRL-Z for DOS/Windows, CTRL-D for Unix). So, you can expect a 1 as
> output most of the time, unless the first character you have typed was
> the one generating an end of file condition.
>
> This program is much easier to work with if you use a loop and redirect
> stdin from a file:[/color]

I too have other means of getting data to a prog and avoid the keyboard
during runtime like the plague, but the point of this exercise is to force
us into this straightjacket.[color=blue]
>
> fangorn:~/tmp 146> cat input
> 12345
> fangorn:~/tmp 147> cat test.c
> #include <stdio.h>
>
> int main()
> {
> int cond;
>
> while ((cond = getchar() != EOF) == 1) printf("%d ", cond);
> printf("%d\n", cond);
> return 0;
> }
> fangorn:~/tmp 148> gcc test.c
> fangorn:~/tmp 149> ./a.out <input
> 1 1 1 1 1 1 0[/color]
Among other things, I don't know whether your 'cat's are like my 'orange's.
In short, I've never touched Unix.[color=blue]
>
> The input file contains 6 characters: the five visible ones (12345)
> and the newline character. For each of them, the expression
> getchar() != EOF evaluates to 1 and a 1 is displayed in the program
> output. The seventh getchar() call generates and end of file condition
> on the stream and it returns EOF. At that point, the expression
> getchar() != EOF evaluates to 0 and the while loop is terminated.
> The corresponding value of the expression is displayed, followed by
> the mandatory newline character.[/color]

The following sentence immediately precedes ex. 1-6: "This has the effect
of setting c to 0 or 1, depending on whether or not the call of getchar
encountered EOF." The 'this' in reference is exactly the first line of my
code after declarations. I'm still not getting results. I think I remember
Heathfield made some remark about either putchar or getchar, but I can't
crack open that book, currently five feet from my knee, as I am going
through K&R sequentially. MPJ
Output:
http://home.comcast.net/~beckjensen/cstuff4.htm

Merrill & Michele wrote:[color=blue][color=green][color=darkred]
>>>It's very difficult to do an exercise with elementary tools. It took me
>>>about fifteen minutes to get exercise 1-7:
>>>#include <stdio.h>
>>>
>>>int main(int orange, char **apple)
>>>{
>>>int c;
>>>c=-5;
>>>while(c != EOF )
>>>{
>>> c++;
>>>}
>>>printf("%d\t",c);
>>>printf("%d\t",EOF);
>>>return (0);
>>>}
>>>Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I think
>>>it's right.[/color][/color]
>
>[color=green]
>>Dan wrote:
>>Nope, it isn't. Your while loop will eventually cause integer overflow,
>>which is undefined behaviour in C. Furthermore, it is entirely irrelevant
>>to your problem, whose solution is as simple as:
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>> printf("%d\n", EOF);
>> return 0;
>> }[/color]
>
>
> Thanks all for replies. Mr. Pop is correct that his shortened version of my
> prog does indeed yield -1, but I liked the idea of trying to find the
> appropriate answer with a while{}. Would Mr. Pop have the same criticism if
> one began the loop with Mr. Barts' (I know I got your 's' this time, but did
> I get the possessive correct?) INT_MIN suggestion, incremented in the usual
> fashion, and it were stipulated that an EOF had indeed been #defined as an
> int?[/color]

He would probably point out that your way is pointless and that you
should start engaging the gray stuff between your ears... However,
that is not mine to say.
If you would bother to read _and_ try to understand everything he says,
you would find out that the problem with the signed integer overflow
then still would not be resolved.
As EOF is a constant negative integer, you can start at INT_MIN and
stop at 0. If you do not want to do so, you have to make sure that c
is not increased when it has the value INT_MAX as this leads to
undefined behaviour.

[color=blue][color=green][color=darkred]
>>>Exercise 1-6 is giving me dyspepsia. This compiles and links but does[/color][/color][/color]

Once more: Give us the text -- not everyone has a copy right
next to his hand...[color=blue]
>
> not
>[color=green][color=darkred]
>>>behave according to my wishes:
>>>#include <stdio.h>
>>>
>>>int main(int orange, char **mango)
>>>{
>>>int c;
>>>c=(getchar() != EOF);
>>>printf("%d\t",c);
>>>return (0);
>>>}
>>>
>>>I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am at[/color][/color]
>
> my
>[color=green][color=darkred]
>>>wit's end, as I also seem to be unable to debug.[/color]
>>
>>Your program is almost correct. Replace \t by \n and it is fully correct.
>>It would have been even better if you used a loop, with getchar() != EOF
>>evaluating to 0 as the exit condition, but it works even in your version,
>>if you understand that stdin, when connected to the terminal, is line
>>buffered. So, nothing will happen until you press the Return/Enter key.
>>Your platform may require it even after the eof key. After that, your
>>getchar() call will return the code of the first character you have typed
>>or EOF if you have typed the corresponding character for your platform
>>(CTRL-Z for DOS/Windows, CTRL-D for Unix). So, you can expect a 1 as
>>output most of the time, unless the first character you have typed was
>>the one generating an end of file condition.
>>
>>This program is much easier to work with if you use a loop and redirect
>>stdin from a file:[/color]
>
>
> I too have other means of getting data to a prog and avoid the keyboard
> during runtime like the plague, but the point of this exercise is to force
> us into this straightjacket.[/color]

It is not.
[color=blue]
>[color=green]
>> fangorn:~/tmp 146> cat input
>> 12345
>> fangorn:~/tmp 147> cat test.c
>> #include <stdio.h>
>>
>> int main()
>> {
>> int cond;
>>
>> while ((cond = getchar() != EOF) == 1) printf("%d ", cond);
>> printf("%d\n", cond);
>> return 0;
>> }
>> fangorn:~/tmp 148> gcc test.c
>> fangorn:~/tmp 149> ./a.out <input
>> 1 1 1 1 1 1 0[/color]
>
> Among other things, I don't know whether your 'cat's are like my 'orange's.
> In short, I've never touched Unix.[/color]

cat <file> essentially reads the file <file> and outputs it to stdout.
The line "./a.out <input" executes the program "./a.out" and redirects
"input" to stdin for this program.

[color=blue][color=green]
>>The input file contains 6 characters: the five visible ones (12345)
>>and the newline character. For each of them, the expression
>>getchar() != EOF evaluates to 1 and a 1 is displayed in the program
>>output. The seventh getchar() call generates and end of file condition
>>on the stream and it returns EOF. At that point, the expression
>>getchar() != EOF evaluates to 0 and the while loop is terminated.
>>The corresponding value of the expression is displayed, followed by
>>the mandatory newline character.[/color]
>
>
> The following sentence immediately precedes ex. 1-6: "This has the effect
> of setting c to 0 or 1, depending on whether or not the call of getchar
> encountered EOF." The 'this' in reference is exactly the first line of my
> code after declarations. I'm still not getting results. I think I remember
> Heathfield made some remark about either putchar or getchar, but I can't
> crack open that book, currently five feet from my knee, as I am going
> through K&R sequentially. MPJ
> Output:
> http://home.comcast.net/~beckjensen/cstuff4.htm[/color]

To me, it seems that your main trouble is your programming environment.
Perhaps it would be better to use more basic tools and an environment
you can understand more easily.
This has been pointed out to you somewhere else, too.

Apart from that, if you follow the steps Dan pointed out, everything
should work fine.
Note that you get stuff from stdin via _any_ of the standard C input
functions only after you hit the return key.

Cheers
Michael

In <LtCdnQeFtqngavbcRVn-jw@comcast.com> "Merrill & Michele" <beckjensen@comcast.net> writes:
[color=blue]
>Thanks all for replies. Mr. Pop is correct that his shortened version of my
>prog does indeed yield -1, but I liked the idea of trying to find the
>appropriate answer with a while{}. Would Mr. Pop have the same criticism if
>one began the loop with Mr. Barts' (I know I got your 's' this time, but did
>I get the possessive correct?) INT_MIN suggestion, incremented in the usual
>fashion, and it were stipulated that an EOF had indeed been #defined as an
>int?[/color]

EOF is guaranteed to have the type int and a negative value. If you start
at INT_MIN you can't miss it before reaching 0. No undefined behaviour
in sight.
[color=blue]
>Output:
>http://home.comcast.net/~beckjensen/cstuff4.htm[/color]

What happens *after* you press the Return/Enter key, as I have asked you
to do?

Answer: you'll a get a 1 or 0 displayed, but you may never have
a chance to see it, if your IDE automatically closes your console
window after program termination. If this is the case, indeed, generate
the EXE file and run it by hand in a standalone console window.

The C beginner using K&R2 is better served by a command line compiler than
by any kind of IDE. All the examples and exercises have been designed
with a command line environment in mind.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[color=blue][color=green][color=darkred]
> >>>Merrill & Michele wrote:
> >>>It's very difficult to do an exercise with elementary tools. It took[/color][/color][/color]
me[color=blue][color=green][color=darkred]
> >>>about fifteen minutes to get exercise 1-7:
> >>>#include <stdio.h>
> >>>
> >>>int main(int orange, char **apple)
> >>>{
> >>>int c;
> >>>c=-5;
> >>>while(c != EOF )
> >>>{
> >>> c++;
> >>>}
> >>>printf("%d\t",c);
> >>>printf("%d\t",EOF);
> >>>return (0);
> >>>}
> >>>Since my printf's agree that window's EOF is Hamilton's (ijk)^2, I[/color][/color][/color]
think[color=blue][color=green][color=darkred]
> >>>it's right.[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >>Dan wrote:
> >>Nope, it isn't. Your while loop will eventually cause integer overflow,
> >>which is undefined behaviour in C. Furthermore, it is entirely[/color][/color][/color]
irrelevant[color=blue][color=green][color=darkred]
> >>to your problem, whose solution is as simple as:
> >>
> >> #include <stdio.h>
> >>
> >> int main()
> >> {
> >> printf("%d\n", EOF);
> >> return 0;
> >> }[/color][/color][/color]
[color=blue][color=green]
> > Thanks all for replies. Mr. Pop is correct that his shortened version[/color][/color]
of my[color=blue][color=green]
> > prog does indeed yield -1, but I liked the idea of trying to find the
> > appropriate answer with a while{}. Would Mr. Pop have the same[/color][/color]
criticism if[color=blue][color=green]
> > one began the loop with Mr. Barts' (I know I got your 's' this time, but[/color][/color]
did[color=blue][color=green]
> > I get the possessive correct?) INT_MIN suggestion, incremented in the[/color][/color]
usual[color=blue][color=green]
> > fashion, and it were stipulated that an EOF had indeed been #defined as[/color][/color]
an[color=blue][color=green]
> > int?[/color][/color]
[color=blue]
> "Michael Mair" wrote
> He would probably point out that your way is pointless and that you
> should start engaging the gray stuff between your ears... However,
> that is not mine to say.
> If you would bother to read _and_ try to understand everything he says,
> you would find out that the problem with the signed integer overflow
> then still would not be resolved.
> As EOF is a constant negative integer, you can start at INT_MIN and
> stop at 0. If you do not want to do so, you have to make sure that c
> is not increased when it has the value INT_MAX as this leads to
> undefined behaviour.[/color]

Mr. Pop does not require your input to disparage. You are incorrect that I
do not read and try to understand. You are further incorrect to claim K&R2
#defines EOF as a negative int. In the chapter I just read, he says it
can't be an int that could otherwise be a char. Demnach, EOF could be
between CHAR_MAX and INT_MAX. Furthermore, I can't remember if I have a
logical OR yet. Reflecting on it, I could use a for and increment from
INT_MIN to INT_MAX and do just fine, but this does not follow the
development.
[color=blue]
> Once more: Give us the text -- not everyone has a copy right
> next to his hand...[/color]

Schade.
[color=blue][color=green][color=darkred]
> >>>Exercise 1-6 is giving me dyspepsia. This compiles and links but
> >>> does not behave according to my wishes:
> >>>#include <stdio.h>
> >>>
> >>>int main(int orange, char **mango)
> >>>{
> >>>int c;
> >>>c=(getchar() != EOF);
> >>>printf("%d\t",c);
> >>>return (0);
> >>>}[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >>>I'm looking for a 0 or 1 when I peck randomly at the keyboard, and am[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >>>my wit's end, as I also seem to be unable to debug.[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >>Dan wrote:
>>>Your program is almost correct. Replace \t by \n and it is fully[/color][/color][/color]
correct.[color=blue][color=green][color=darkred]
> >>It would have been even better if you used a loop, with getchar() != EOF
> >>evaluating to 0 as the exit condition, but it works even in your[/color][/color][/color]
version,[color=blue][color=green][color=darkred]
> >>if you understand that stdin, when connected to the terminal, is line
> >>buffered. So, nothing will happen until you press the Return/Enter key.
> >>Your platform may require it even after the eof key. After that, your
> >>getchar() call will return the code of the first character you have[/color][/color][/color]
typed[color=blue][color=green][color=darkred]
> >>or EOF if you have typed the corresponding character for your platform
> >>(CTRL-Z for DOS/Windows, CTRL-D for Unix). So, you can expect a 1 as
> >>output most of the time, unless the first character you have typed was
> >>the one generating an end of file condition.[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >>This program is much easier to work with if you use a loop and redirect
> >>stdin from a file:[/color][/color][/color]
[color=blue][color=green]
> > MPJ wrote:
> > I too have other means of getting data to a prog and avoid the keyboard
> > during runtime like the plague, but the point of this exercise is to[/color][/color]
force[color=blue][color=green]
> > us into this straightjacket.[/color][/color]
[color=blue]
> "Michael Mair" wrote
> It is not.[/color]
It's amazing to announce the intent of an exercise of a book that you don't
have in hand.

[color=blue][color=green][color=darkred]
> > > Dan wrote
> >> fangorn:~/tmp 146> cat input
> >> 12345
> >> fangorn:~/tmp 147> cat test.c
> >> #include <stdio.h>
> >>
> >> int main()
> >> {
> >> int cond;
> >>
> >> while ((cond = getchar() != EOF) == 1) printf("%d ", cond);
> >> printf("%d\n", cond);
> >> return 0;
> >> }
> >> fangorn:~/tmp 148> gcc test.c
> >> fangorn:~/tmp 149> ./a.out <input
> >> 1 1 1 1 1 1 0[/color]
> >
> > Among other things, I don't know whether your 'cat's are like my[/color][/color]
'orange's.[color=blue][color=green]
> > In short, I've never touched Unix.[/color]
>
> "Michael Mair" wrote
> cat <file> essentially reads the file <file> and outputs it to stdout.
> The line "./a.out <input" executes the program "./a.out" and redirects
> "input" to stdin for this program.[/color]
Good to know.
[color=blue][color=green][color=darkred]
> > > Dan wrote:
> >>The input file contains 6 characters: the five visible ones (12345)
> >>and the newline character. For each of them, the expression
> >>getchar() != EOF evaluates to 1 and a 1 is displayed in the program
> >>output. The seventh getchar() call generates and end of file condition
> >>on the stream and it returns EOF. At that point, the expression
> >>getchar() != EOF evaluates to 0 and the while loop is terminated.
> >>The corresponding value of the expression is displayed, followed by
> >>the mandatory newline character.[/color]
> >
> >
> > The following sentence immediately precedes ex. 1-6: "This has the[/color][/color]
effect[color=blue][color=green]
> > of setting c to 0 or 1, depending on whether or not the call of getchar
> > encountered EOF." The 'this' in reference is exactly the first line of[/color][/color]
my[color=blue][color=green]
> > code after declarations. I'm still not getting results. I think I[/color][/color]
remember[color=blue][color=green]
> > Heathfield made some remark about either putchar or getchar, but I can't
> > crack open that book, currently five feet from my knee, as I am going
> > through K&R sequentially. MPJ
> > Output:
> > http://home.comcast.net/~beckjensen/cstuff4.htm[/color][/color]
[color=blue]
> "Michael Mair" wrote
> To me, it seems that your main trouble is your programming environment.
> Perhaps it would be better to use more basic tools and an environment
> you can understand more easily.
> This has been pointed out to you somewhere else, too.
>
> Apart from that, if you follow the steps Dan pointed out, everything
> should work fine.
> Note that you get stuff from stdin via _any_ of the standard C input
> functions only after you hit the return key.[/color]

My programming environment is definitely austere. I haven't found an
instance of where it has not performed properly given ANSI-compliant C. My
question then is, does the following code, when executed, take keystrokes
and put either a zero or a one as output depending on whether the keystroke
is, respectively, EOF or anything else?
#include <stdio.h>

int main(int orange, char **mango)
{
int c;
c=(getchar() != EOF);
printf("%d\n",c);
return (0);
}
I'll address some form of upgrade after I plough through K&R. MPJ

Hello,

Merrill & Michele wrote:[color=blue][color=green][color=darkred]
>>>Thanks all for replies. Mr. Pop is correct that his shortened version[/color][/color]
>
> of my
>[color=green][color=darkred]
>>>prog does indeed yield -1, but I liked the idea of trying to find the
>>>appropriate answer with a while{}. Would Mr. Pop have the same[/color][/color]
>
> criticism if
>[color=green][color=darkred]
>>>one began the loop with Mr. Barts' (I know I got your 's' this time, but[/color][/color]
>
> did
>[color=green][color=darkred]
>>>I get the possessive correct?) INT_MIN suggestion, incremented in the[/color][/color]
>
> usual
>[color=green][color=darkred]
>>>fashion, and it were stipulated that an EOF had indeed been #defined as[/color][/color]
>
> an
>[color=green][color=darkred]
>>>int?[/color][/color]
>
>[color=green]
>>"Michael Mair" wrote
>>He would probably point out that your way is pointless and that you
>>should start engaging the gray stuff between your ears... However,
>>that is not mine to say.
>>If you would bother to read _and_ try to understand everything he says,
>>you would find out that the problem with the signed integer overflow
>>then still would not be resolved.
>>As EOF is a constant negative integer, you can start at INT_MIN and
>>stop at 0. If you do not want to do so, you have to make sure that c
>>is not increased when it has the value INT_MAX as this leads to
>>undefined behaviour.[/color]
>
>
> Mr. Pop does not require your input to disparage.[/color]

Certainly not -- which is exactly what I said.
[color=blue]
> You are incorrect that I
> do not read and try to understand.[/color]

Well, then why do you not just do exactly what he suggests?
And then come back and ask questions? Instead of not doing
it and come back.
[color=blue]
> You are further incorrect to claim K&R2
> #defines EOF as a negative int.[/color]

I did not claim that -- this was just FYI.
[color=blue]
> In the chapter I just read, he says it
> can't be an int that could otherwise be a char. Demnach, EOF could be
> between CHAR_MAX and INT_MAX.[/color]

Right. Which the rest of my statement dealt with.
[color=blue]
> Furthermore, I can't remember if I have a
> logical OR yet.[/color]

.... and what does this have to do with it?
[color=blue]
> Reflecting on it, I could use a for and increment from
> INT_MIN to INT_MAX and do just fine,[/color]

Which is what I suggest.
[color=blue]
> but this does not follow the development.[/color]

???

[color=blue][color=green]
>>Once more: Give us the text -- not everyone has a copy right
>>next to his hand...[/color]
>
> Schade.[/color]

I _do_ have a copy. But not everyone has one and not necessarily
at the place where he reads your message from.

[color=blue][color=green][color=darkred]
>>>MPJ wrote:
>>>I too have other means of getting data to a prog and avoid the keyboard
>>>during runtime like the plague, but the point of this exercise is to[/color][/color]
>
> force
>[color=green][color=darkred]
>>>us into this straightjacket.[/color][/color]
>
>[color=green]
>>"Michael Mair" wrote
>>It is not.[/color]
>
> It's amazing to announce the intent of an exercise of a book that you don't
> have in hand.[/color]

It would be if I had not.

[color=blue][color=green]
>>"Michael Mair" wrote
>>To me, it seems that your main trouble is your programming environment.
>>Perhaps it would be better to use more basic tools and an environment
>>you can understand more easily.
>>This has been pointed out to you somewhere else, too.
>>
>>Apart from that, if you follow the steps Dan pointed out, everything
>>should work fine.
>>Note that you get stuff from stdin via _any_ of the standard C input
>>functions only after you hit the return key.[/color]
>
>
> My programming environment is definitely austere. I haven't found an
> instance of where it has not performed properly given ANSI-compliant C.[/color]

Yes. See Dan Pop's reply for reasons against it as I am tired of
reiterating what you already have been told more than twice.
[color=blue]
> My
> question then is, does the following code, when executed, take keystrokes
> and put either a zero or a one as output depending on whether the keystroke
> is, respectively, EOF or anything else?
> #include <stdio.h>
>
> int main(int orange, char **mango)
> {
> int c;
> c=(getchar() != EOF);
> printf("%d\n",c);
> return (0);
> }[/color]

It does. If you would hit the return key after entering something
producing EOF or not -- as Dan Pop and I have told you -- you would
find out for yourself.

[color=blue]
> I'll address some form of upgrade after I plough through K&R. MPJ[/color]

Not necessary.

I refer you to Dan Pop's reply further down the thread. Perhaps
his way of telling it to you will shed more light on it for you.

It might be a Good Idea to get a "naked" editor not integrated
in an IDE and a compiler either for DOS or Windows or to get
CygWin and learn things from scratch.

-- Michael

In <wbidnYQBv5sep_DcRVn-uQ@comcast.com> "Merrill & Michele" <beckjensen@comcast.net> writes:
[color=blue]
>question then is, does the following code, when executed, take keystrokes
>and put either a zero or a one as output depending on whether the keystroke
>is, respectively, EOF or anything else?
>#include <stdio.h>
>
>int main(int orange, char **mango)
>{
> int c;
> c=(getchar() != EOF);
> printf("%d\n",c);
> return (0);
>}[/color]

I have already explained you *exactly* what this program does. The
behaviour is less than obvious when stdin is connected to a terminal
because the getchar() call won't return until the user presses the
Return/Enter key (on some platforms it may return as soon as the eof
key is pressed). Once the user has pressed the Return key, the program
will display a 1 or a 0, depending on what was the first key pressed by
the user.

fangorn:~/tmp 206> cat test.c
#include <stdio.h>

int main(int orange, char **mango)
{
int c;
c=(getchar() != EOF);
printf("%d\n",c);
return (0);
}
fangorn:~/tmp 207> gcc test.c
fangorn:~/tmp 208> ./a.out
foo <------ my input
1
fangorn:~/tmp 209> ./a.out
0

In the second invocation, I merely pressed the eof key when the program
was expecting input. On my platform, no Return key was needed in this
case, but other platforms require it.

The behaviour of such programs is easier to understand if stdin is
redirected:

fangorn:~/tmp 213> ./a.out < /dev/zero
1
fangorn:~/tmp 214> ./a.out < /dev/null
0

/dev/zero is a device supplying an infinite stream of null bytes, while
/dev/null reports an end of file condition when read.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

> >MPJ wrote:[color=blue][color=green]
> >Thanks all for replies. Mr. Pop is correct that his shortened version of[/color][/color]
my[color=blue][color=green]
> >prog does indeed yield -1, but I liked the idea of trying to find the
> >appropriate answer with a while{}. Would Mr. Pop have the same criticism[/color][/color]
if[color=blue][color=green]
> >one began the loop with Mr. Barts' (I know I got your 's' this time, but[/color][/color]
did[color=blue][color=green]
> >I get the possessive correct?) INT_MIN suggestion, incremented in the[/color][/color]
usual[color=blue][color=green]
> >fashion, and it were stipulated that an EOF had indeed been #defined as[/color][/color]
an[color=blue][color=green]
> >int?[/color]
> Dan wrote:
> EOF is guaranteed to have the type int and a negative value. If you start
> at INT_MIN you can't miss it before reaching 0. No undefined behaviour
> in sight.
> What happens *after* you press the Return/Enter key, as I have asked you
> to do?
>
> Answer: you'll a get a 1 or 0 displayed, but you may never have
> a chance to see it, if your IDE automatically closes your console
> window after program termination. If this is the case, indeed, generate
> the EXE file and run it by hand in a standalone console window.
>
> The C beginner using K&R2 is better served by a command line compiler than
> by any kind of IDE. All the examples and exercises have been designed
> with a command line environment in mind.
>[/color]
Yeah, I missed it. The IDE was fine; the monkey running it, well .... I
can create the command line and would likely be better served by another
compiler. I'm not single-minded like George Bush in that I have single
thought in my head. I'm single-minded in that I don't change horses or
focus until I have to. MPJ