Can C do it ?

[Herbert Rosenau]

>
It says "we have to do two different things with it (test, and
print)". I think this assertion is closely related to the code they
run and explain in the same page.

However, with '\n', we just need to test it and not to print it ? So
why is a int variable needed ? The question should be how come int
variable c can be both in getchar() and !=EOF ?

What's the point of testing a int variable against '\n' ? '\n' is a
character, isn't it?

To make something that looks complicated really simple and easy:

C i/o is stream based. That means that C itself does nothing know
about real devices like keyboard, screen, printer and so on. C sees
simply a stream of characters! getchar() is a primitive function that
does nothing else than to look into the stream it is assigned too to
get the next not already readed character from that stream. This
stream may or may not buffered - it does not matter as the job of
getchar is simply to get the next not already readed character out of
the stream. When there is at least not a single character left in the
stream then getchar signals this fact by returning an int that is
named EOF. Whereas 'nothing left' means exactly that the stream is
closed (dircetly assigned to a device like a keyboard and the devicce
is closed) or in case that the stream is not directly assigned to a
device but a file that the file is readed completely, noch character
unreaded left.

Another case getchar may return EOF is that something went wrong while
getchar was trying to get the next unreaded character from the stream.
That is commonly named a read error occured. Even as read errors are
rare on current hardware you should be pedantic and ditinguish between
EOF and error by asking ferror(stdin) for the occurence of an error or
really EOF.

So normally you would read char by char until you finds one you are
specially interested in like a TAB ('\t'), a forfeed ('\f'), a newline
('\n') or something else you are searchig for. '\n' is in C a special
case as on some systems '\n' is in real a combination of "\r\n" or
"0x0d0a" or '0x0d' or '0x0a' depending on the OS. The C runtime will
know what character(s) the OS uses to xsignal a newline and convert
that singe char or the multiple char combination into the singe char
'\n' in input and the same char back to the system dependant char or
combination.

So normally you'll read/write simply '\n' and anything is done right
in the background - except you are reading/writing in binary mode. In
binary mode to conversion is made!


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Keith Thompson]

C i/o is stream based. That means that C itself does nothing know
about real devices like keyboard, screen, printer and so on. C sees
simply a stream of characters! getchar() is a primitive function that
does nothing else than to look into the stream it is assigned too to
get the next not already readed character from that stream. This
stream may or may not buffered - it does not matter as the job of
getchar is simply to get the next not already readed character out of
the stream. When there is at least not a single character left in the
stream then getchar signals this fact by returning an int that is
named EOF. Whereas 'nothing left' means exactly that the stream is
closed (dircetly assigned to a device like a keyboard and the devicce
is closed) or in case that the stream is not directly assigned to a
device but a file that the file is readed completely, noch character
unreaded left.

Quibble: The fact that a stream has reached the end-of-file doesn't
mean that the stream is closed. It can then be closed by a separate
operation, i.e., calling the close() function.

[...]

So normally you'll read/write simply '\n' and anything is done right
in the background - except you are reading/writing in binary mode. In
binary mode to conversion is made!

Typo: you meant that "In binary mode *no* conversion is made!".

 

[Herbert Rosenau]

Is there a way to access and take a picture of the buffer ? Let say
with hexa values as descriptions ?

There are 3 different type of streams:
1. unbuffered
any character gets directly from the device into the program
2. line buffered
the OS reads the stream into a buffer and releaes this buffer only
when a whole line is complete or EOF or error occures.
3. full buffered
the OS releases the buffer only when it is full, that means that
multiple lines fully or the last line partially incomplete because
buffer full.

So getchar() and getc() are designed to deliver only one char at a
time - but until the OS delivers the buffer (if there is one) to the C
runtime nothing can occure.

Make you Brain free and accept getchar(), getc() fgetc() as simple
function that gets exactly one charater from the stream, forget any
buffering the OS or the C runtime may use or not until you have a case
to ask for the special behavior of the current stream.

Don't mak things more complicate than really needed until you have a
special case wher it is really important which kind of buffering is
assigned to the stream and/or how the current OS and the current C
implementation does the work with the exact kind of stream you are
working with.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Keith Thompson]

Quibble: there is no such function in standard C. You meant the
fclose() function.

Whoops, right.

 

[David Thompson]

Willem <[email protected]> writes:

It's not actually gcc's printf. Under glibc, the runtime library
commonly used with the gcc compiler on Linux (or GNU/Linux) systems,
passing a null pointer to printf("%s") does seem to print "(null)"
-- although in one case I got a segmentation fault.

But if djgpp doesn't use glibc (I don't think it does), then this is
irrelevant to the OP.

It doesn't, but djlsr# src\libc\ansi\stdio\doprnt.c does have this:
/*tabexpanded for newspost!*/
....
static char NULL_REP[] = "(null)";
....
case 's':
if (!(t = va_arg(argp, char *)))
t = NULL_REP;

And plenty of others have had the same idea. Including Java.

But in any case, the OP's code doesn't attempt to pass a null pointer
to printf -- assuming the code he posted is actually the code he's
compiling and running.

Nor the other stuff reported, nor indeed anything at all to *printf.

If his description so far is accurate, reinstalling his C
implementation is probably the next step.

Something is indeed quite weird.

Much as I generally hate the 'wipe and start over' attitude that is
highly correlated with MS systems and users -- though _by no means_
unique or new with them -- that may sadly be the least bad choice.

 

[Nick Keighley]

I came to this conclusion :

Make a code work under windows following C99 standards with some
tweaks and without conio...

C89 might be better. C99 isn't widely implemented and in particular
Microsoft have made no attempt to implement it. I'm not sure what
"some tweaks" are. Definitely avoid conio.

will be equivalent to implement the code
in linux following C99 standards strictly speaking (without any
tweaks) ?

even on Linux full C99 implementations are as rare s hen's teeth.
Again I don't understand your "tweaks". If the program can be
implemented
in portable C89 then it has a good chance of running on a variety of
platforms. Including Windows and Linux.

So far, after 3-4 months of learning, user's inputs seem to be the
most difficult chapter

user imput can be hard. This is because people are unrestrained
and even imaginative in what they can type. You have to
allow for the most evil of possibilities.

when for a few lines of code as a beginner, i'd
like the code to work on as many plateform as possible.

ok (I think)

Many websites show scanf and %s to read strings with classic variables

I'm not sure what a classic variable is

as well as with pointers (my tutorial as well).

they read pointers with scanf("%s")? Could you give some examples?

int main (void)
{
char s [10];
char *p;

scanf ("%s", s); /* may overflow */
scanf ("%s", p); /* REALLY WRONG! */

return 0;
}

the second scanf() is writing into an uninitialised pointer.
This is VERY BAD. I hope the tutorials you used didn't do this.

To my eyes and
experience, scanf seems very easy to implement on both plateform...

actually its quite hard to implement! It's a little parser.
It's quite easy to *use* if you don't care about errors. This
can fool beginners. As a bare minimum I'd use fgets() and sscanf()
rather than bare scanf() as error recovery is easier. **Always** check
the return value of anf scanf() style function. Don't use %s but
use %10s etc. This way you can avoid overflow.

In some other websites and here in this forum, some say scanf is not
best to read strings of characters because of security reasons. Then
what would be the best counterpart ?

fegts() or limit the number of characters read by the %s format.