Having Trouble

[ext_u]

I'm trying to learn C from "The C Programming Language" (by K&R) and I
am about halfway through the first chapter.

I am using Miracle C as my text editor and compiler.

Up until this point everything was working fine, but now the book has
started into Line and Word counting programs. I am entering the
programs into the text editor exactly like they are in the book and
they are not working right at all. They compile fine and when I run
them they do no produce any output like they should be. Its strange.
I think it may be my compiler. Someone recommended my using DJPGG (i
think it was called) and I tried to install and run that program but
it seems way way way to complicated for me and I have noone who can
show me how to get it to run properly.

This is the line counting Prog:
#include <stdio.h>
main()
{
int c, nl;
nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

When I type things into the cmdprompt it will not give me any output (
i guess its called) Its almost like the printf cmd isnt there and it
is just taking in the data and not displaying anything. The word
counting program was basically the same and gave me the same result.
I enter something , hit enter and instead of printing anything on the
screen it pauses for a moment and then moves down to the next line.
Its frustrating. There is also wc program that comes straight from
UNIX in the book and when I enter the code exactly as it is in the
book into my compiler I get a weird error like it thinks the word OUT
is the number 0. Very strange....

I think the problem is my compiler. Can anyone recommend a good and
easy to use C compiler/text editor??

 

[Tor Hildrum]

This is the line counting Prog:
#include <stdio.h>
main()
{
int c, nl;
nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

int main(void)
{
int nl;
char c;
nl = 0;

while( (c = getchar() ) != EOF)
{
if( c == '\n')
++nl;
}

printf("%d\n", nl);

return 0;
}

This type of program takes the input-file on standard input, so you
basically need to redirect a file to your program.

Example:
[hildrum:C-Programming] tor% wc -l linecount.c
18 linecount.c
[hildrum:C-Programming] tor% ./linecount < linecount.c
18

Tor

 

[Matt Gregory]

I'm trying to learn C from "The C Programming Language" (by K&R) and I
am about halfway through the first chapter.

I am using Miracle C as my text editor and compiler.

Up until this point everything was working fine, but now the book has
started into Line and Word counting programs. I am entering the
programs into the text editor exactly like they are in the book and
they are not working right at all. They compile fine and when I run
them they do no produce any output like they should be. Its strange.
I think it may be my compiler. Someone recommended my using DJPGG (i
think it was called) and I tried to install and run that program but
it seems way way way to complicated for me and I have noone who can
show me how to get it to run properly.

This is the line counting Prog:
#include <stdio.h>
main()
{
int c, nl;
nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

When I type things into the cmdprompt it will not give me any output (
i guess its called) Its almost like the printf cmd isnt there and it
is just taking in the data and not displaying anything. The word
counting program was basically the same and gave me the same result.
I enter something , hit enter and instead of printing anything on the
screen it pauses for a moment and then moves down to the next line.
Its frustrating. There is also wc program that comes straight from
UNIX in the book and when I enter the code exactly as it is in the
book into my compiler I get a weird error like it thinks the word OUT
is the number 0. Very strange....

I think the problem is my compiler. Can anyone recommend a good and
easy to use C compiler/text editor??

No, the program is right. It's waiting for you to signal an EOF.
Control-Z should work for DOS. You might have to hit enter.

That program would work better by sending a file for it to read.

prog.exe < file.txt

Read about command output redirection, filters, and pipes somewhere.
I don't know of a good overview offhand, but it's some fundamental
knowledge.

 

[Bill Reed]

I'm trying to learn C from "The C Programming Language" (by K&R) and I
am about halfway through the first chapter.

I am using Miracle C as my text editor and compiler.

Up until this point everything was working fine, but now the book has
started into Line and Word counting programs. I am entering the
programs into the text editor exactly like they are in the book and
they are not working right at all. They compile fine and when I run
them they do no produce any output like they should be. Its strange.
I think it may be my compiler. Someone recommended my using DJPGG (i
think it was called) and I tried to install and run that program but
it seems way way way to complicated for me and I have noone who can
show me how to get it to run properly.

This is the line counting Prog:
#include <stdio.h>
main()
{
int c, nl;
nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

Your problem might be that you need a text file in the same directory
as your executable. Just type a few lines in a new text file or copy a
readme file from somewhere. Then on the command line enter:

"program_name" < "text_file_name"

then your program will count the number of lines.

I believe this is your problem.

Bill

Bill Reed
Email = Subject: must include "clc"

 

[Steve Zimmerman]

I'm trying to learn C from "The C Programming Language" (by K&R) and I
am about halfway through the first chapter.

I am using Miracle C as my text editor and compiler.

Up until this point everything was working fine, but now the book has
started into Line and Word counting programs. I am entering the
programs into the text editor exactly like they are in the book and
they are not working right at all. They compile fine and when I run
them they do no produce any output like they should be. Its strange.
I think it may be my compiler. Someone recommended my using DJPGG (i
think it was called) and I tried to install and run that program but
it seems way way way to complicated for me and I have noone who can
show me how to get it to run properly.

This is the line counting Prog:
#include <stdio.h>
main()
{
int c, nl;
nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

When I type things into the cmdprompt it will not give me any output (
i guess its called) Its almost like the printf cmd isnt there and it
is just taking in the data and not displaying anything. The word
counting program was basically the same and gave me the same result.
I enter something , hit enter and instead of printing anything on the
screen it pauses for a moment and then moves down to the next line.
Its frustrating. There is also wc program that comes straight from
UNIX in the book and when I enter the code exactly as it is in the
book into my compiler I get a weird error like it thinks the word OUT
is the number 0. Very strange....

I think the problem is my compiler. Can anyone recommend a good and
easy to use C compiler/text editor??

I like the gcc compiler, which comes with the Linux
operating system. Here's how the program works with
gcc. (I've numbered the lines, so I can explain what
they mean.)

(1) gcc line_count.c -o line_count
(2) ./line_count
(3) The quick brown fox
(4) jumped over the
(5) gnarly net.
(6) Control-d
(7) 3

You type lines 1 and 2 into the computer.
Then you can type however many lines you want,
and then type Control-d, and the computer will
tell you how many lines you just entered into
the computer (minus the Control-d line).

 

[CBFalconer]

I'm trying to learn C from "The C Programming Language" (by K&R) and I
am about halfway through the first chapter.

I am using Miracle C as my text editor and compiler.

Up until this point everything was working fine, but now the book has
started into Line and Word counting programs. I am entering the
programs into the text editor exactly like they are in the book and
they are not working right at all. They compile fine and when I run
them they do no produce any output like they should be. Its strange.
I think it may be my compiler. Someone recommended my using DJPGG (i
think it was called) and I tried to install and run that program but
it seems way way way to complicated for me and I have noone who can
show me how to get it to run properly.
.... snip ...

I think the problem is my compiler. Can anyone recommend a good and
easy to use C compiler/text editor??

You didn't follow instructions on the DJGPP installation. It is
NOT a program, it is a system. Among other things you will get
gcc, the best C compiler available, and pretty well universally
used. Go through the sip-picker again, and be sure to get unzip32
with it, and to follow instructions.

 

[Nils Petter Vaskinn]

while ((c = getchar()) != EOF)

When I type things into the cmdprompt it will not give me any output

This program reads until it gets to an EOF (end of file) character, so
unless you supply one it won't ever complete.

In linux ctrl-d (I think it was) makes and EOF character, don't know if
that works in windows but it may be worth a try. If it doesn't you'll have
to search the documentation to figure out how to input and EOF character

hth
NPV

 

[Arjan]

In message <4aW%a.23577$KF1.317975@amstwist00>

int main(void)
{
int nl;
char c;

Doesn't getchar() return an int?

nl = 0;

while( (c = getchar() ) != EOF)
{
if( c == '\n')
++nl;
}

printf("%d\n", nl);

return 0;
}

Groeten,
Arjan

 

[Jan Engelhardt]

while ((c = getchar()) != EOF)

In linux ctrl-d (I think it was) makes and EOF character, don't know if

it was.

that works in windows but it may be worth a try. If it doesn't you'll have

sometimes. otherwise try ctrl-z. if that doesnot work too, I can't help either.

 

[Keith Thompson]

This program reads until it gets to an EOF (end of file) character, so
unless you supply one it won't ever complete.

Quibble: EOF is not a character, it's a macro that expands to a
negative integer constant expression ((-1) is typical). That's why
getchar() returns an int rather than a character type, so it can
return either a character value or EOF.

Just to add to the confusion, many systems use a specific input
character to signal an EOF condition for interactive input.

<OT>
Unix-like systems typically use control-D, but a program reading from
the keyboard will see an EOF condition, not a control-D character
('\004') -- though a mechanism exists for entering a control-D
character so that it will be seen by the reading program, *without*
triggering an EOF condition (control-V control-D). A control-D
character in a disk file will be read as a '\004' character, and will
*not* signal EOF. Other systems may behave differently; for example,
I think that a control-Z character ('\026') in an MS-DOS text file
actually does signal EOF.
</OT>

 

[Mark McIntyre]

In message <4aW%a.23577$KF1.317975@amstwist00>


Doesn't getchar() return an int?

indeed, and not only that, but EOF is not guaranteed to fit into a
char, so this is generally a bug.

 

[CBFalconer]

indeed, and not only that, but EOF is not guaranteed to fit
into a char, so this is generally a bug.

In fact EOF is guaranteed NOT to fit into a char.

 

[Jarno A Wuolijoki]

In fact EOF is guaranteed NOT to fit into a char.

Wouldn't such a guarantee render any hosted implementation with
sizeof(int)==1 non-conforming?

 

[Lew Pitcher]

Wouldn't such a guarantee render any hosted implementation with
sizeof(int)==1 non-conforming?

To me

sizeof(int) == 1

would imply that

CHAR_BIT > 8

because the standard's guarantees for INT_MAX couldn't be satisfied otherwise.

I don't know what is implied wrt the standard if
INT_MAX <= CHAR_MAX

Perhaps one of the language experts here could tell us.


--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

 

[Mark McIntyre]

In fact EOF is guaranteed NOT to fit into a char.

is sizeof(int)==1 illegal ? Where does it say so?

 

[Joona I Palaste]

is sizeof(int)==1 illegal ? Where does it say so?

It would make sizeof(int)==sizeof(char), making EOF fit into a char.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

 

[Ben Pfaff]

It would make sizeof(int)==sizeof(char), making EOF fit into a char.

Unfortunately, that's a valid way to design and build a C
implementation.

 

[Joona I Palaste]

Unfortunately, that's a valid way to design and build a C
implementation.

Then, how is the C implementation able to distinguish between EOF and a
real char? If char and int are signed, I can very well envision a
scenario where a byte of all-bits-one would be mistaken for EOF.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Insanity is to be shared."
- Tailgunner

 

[Phil Tregoning]

What do you mean by "real char"? `EOF' must be distinguishable from any
character in a stream, but if I'm not mistaken, there is no requirement
that every possible character value must be representable in a stream.
(Somebody please correct me if this is wrong.)

My pleasure

For example, I could imagine an implementation with a 32 bit char type,
but 8 bit characters in streams. Reading from a stream would simply
return one of 256 possible values, so there are plenty of possible
values for `EOF' left which can never occur in a stream. Writing a
character to a stream would ignore 24 of the 32 bits.

C99 7.19.2p3:

Data read in from a binary stream shall compare equal to the
data that were earlier written out to that stream, under the
same implementation.

Phil T

 

[The real OS2 guy]

Then, how is the C implementation able to distinguish between EOF and a
real char? If char and int are signed, I can very well envision a
scenario where a byte of all-bits-one would be mistaken for EOF.

The standard guarantees: CHR_BITS >= 8

That is the world outside the C continuum interprets
char = 8 bits.

But hardware designers are sometimes crude and defines that
the mashine should have no possibility to address less than
9, 12, 16 or 32 or.... bits. As C is designed to be
effective it will then define char bits as the smallest number
of bits the mashine can address in its memory.

As external chars are commonly exactly 8 bit wide the
implementation will transfer the 8 bit to the internal
char wide and reverse. The result will be that your
32 bit char has 24 bits unused (or sign extended in case of
signed char.

So when your implementation tells you that sizeof(char) == sizeof(int)
== sizeof(long) == 1 then your
- unsigned char uses 8 bits, the sign bit ignored
and the unused bits zeroed (or set mashine dependant)
- signed char uses 8 bits, the sign bit set depending
on the sign of the incoming char and the unused bits
set to a value that is mashine and sign dependant.
- typeless char is truly mashine specific, means
represented as either unsigned or signed char.

This lefts anyway enough space to define
max(<int>, <char>) differently, so that
EOF gets defined as a negative number that is less than
MIN_SCHAR and so outside the value range of char, even
as sizeof(int) == 1 == sizeof(char)

By that in more than 20 years of programming I have always given the
order to the compiler to treate chars as unsigned to avoid possible
problems. That doesn't mean that it is impossible to declare signed
char explizity, but a signed char MUST be declared explicity then,
even as the compiler may enabled in default to use only signed char in
default. For that either a compiler switch or a #pragma is to use.

As char is originally designed to hold any character of the character
set(s) of the mashine/os and each character set known (we speak here
NOT about wchar or unicode) one can assume saveley that only the
values 0 - 255 are used. When one uses char as arithmetic types then
one will always be quickly incompatible when one uses values outside
the range 0-255 (unsigned) or -127 - 127 (signed) anyway and then you
have no need to ask for EOF.

--
Tschau/Bye

Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 german is in beta testing