Can C do it ?

[Keith Thompson]

Keith Thompson wrote: [...]

When the user types ^D or ^Z, it's interpreted by (some layer of)
the OS as an end-of-file indication. If a C program is reading
from the correspoding input stream by repeatedly calling getchar(),
after the getchar() has processed the last character that preceded
the ^D or ^Z, the *end-of-file indicator* for the stream is set.
When getchar() is called on a stream whose end-of-file indicator
is set, it returns the value of EOF.

The end-of-file indicator is set differently for a file or for the
keyboard. And yes, the I/O system knows which. Sending a line to
getchar() ending with '\n' does not set the end-of-file (eof)
indicator. The eof gets set only when you attempt to read beyond the
last byte of a file or when, from the keyboard, ^D or ^Z follows '\n'.

A line ending with '\n' doesn't signal end-of-file for a disk file
either.

The input model, as far as getchar() is concerned, is pretty much
the same either for a disk file or for input from a keyboard.
Both are modeled as input text streams, and both are composed of
a sequence of lines, each terminated by '\n'. The end-of-file
condition is triggered differently: for a disk file, typically as
defined by the filesystem's idea of how many bytes the file contains,
and for keyboard input, typically by the user entering some special
key combination. But the behavior as seen by a C program calling
getchar() is very similar. (The C implementation, including the OS,
goes to considerable effort to make them look similar.)

The ^D or ^Z keypresses immediately following '\n', followed by '\n'
or Enter is the keyboard version of end-of-file. Otherwise 4 and 26
are just charters with that value.

s/charters/characters/

nNote also that, under Unix, typing ^D twice in the middle of a line
also signals an end-of-file condition; getchar() can then return
EOF without having previously returned '\n'. And ^V^D causes
getchar() to return '\004'. (Both ^V and ^D can be reconfigured
to other values.) I'm less familiar with how Windows does this.

The ^Z written as a character to signify the end of a text file is an
artifact of CP/M carried over into early MSDOS. CP/M wrote files in
128-byte chunks. The filesystem couldn't tell you whether a file was 3
bytes or 123 bytes. You needed to read it and stop at the 1A.

Relatively modern systems retain this legacy. Many Microsoft text
files still end with 1A for no other obvious reason.

And, IIRC, a 1A byte in the middle of a Windows text file is treated
as an end-of-file marker (but only if you read it in text mode;
in binary mode it's just another byte).

 

[bpascal123]

That's to be expected.


Describing a rough approximation of the output you got doesn't do
anybody any good.  If you can copy-and-paste the *exact* output (or at
least a portion of it), we have a fighting chance of diagnosing the
problem.

Hi,
I understand this isn't the best way to describe something. My excuse
for the delay, it's just that windows takes so long to boot...

The message i get :

"from (null):4294967295,
from (null):4294967295,"
....

It happens when i compile : gcc myfile.c -o myfile.exe

Overnight i thought about it and I have to tell that earlier in the
day this happened i "re-arrange" folders in my djgpp directory. But i
only moved folders where i had saved codes NOT folders with
application system files in it (unless i moved a file i shouldn't have
moved by mistake...). SO IF THIS SIMPLE CODE IS WORKING IN YOUR
WINDOWS MACHINE IT MIGHT BE THAT I MESSED UP WITH A FILE and i need to
see this with people at djgpp. I am certain i rearranged files (only
folders with code i had written and nothing else) just before trying
to compile the code from http://c-faq.com/~scs/cclass/notes/sx6b.html.
However, i can compile any other code that includes printf, scanf...
in Windows.

Thanks
Pascal

 

[Phil Carmody]

Note also that, under Unix, typing ^D twice in the middle of a line
also signals an end-of-file condition; getchar() can then return
EOF without having previously returned '\n'. And ^V^D causes
getchar() to return '\004'. (Both ^V and ^D can be reconfigured
to other values.) I'm less familiar with how Windows does this.

Erk. ^D^D /may/ signal to the tty that it is to report on an e-o-f
condition to the program attached to it. On my Unix consoles here,
it certainly doesn't:

FreeBSD 5.3 zsh - mid-line ^D tab completes, ^D^D backs out
SunOS 5.8 csh - mid-line ^D tab completes, ^D^D duplicates.
SunOS 5.9 bash - mid-line ^D does nothing perpetually
Linux bash - mid-line ^D does nothing perpetually

So I can't reproduce it on a console. (It may behave differently
via a telnet or SSH session, perhaps, as there are two ends to consider.)

Phil

 

[Richard Tobin]

Erk. ^D^D /may/ signal to the tty that it is to report on an e-o-f
condition to the program attached to it. On my Unix consoles here,
it certainly doesn't:

FreeBSD 5.3 zsh - mid-line ^D tab completes, ^D^D backs out
SunOS 5.8 csh - mid-line ^D tab completes, ^D^D duplicates.
SunOS 5.9 bash - mid-line ^D does nothing perpetually
Linux bash - mid-line ^D does nothing perpetually

All those shells are probably putting the terminal in raw mode (or at
least a not-fully-cooked mode) and interpreting the characters
themselves. Try it inside "cat" on each system. It should
echo the line after the first one, and exit after the second.

-- Richard

 

[Phil Carmody]

All those shells are probably putting the terminal in raw mode (or at
least a not-fully-cooked mode) and interpreting the characters
themselves.

Absolutely. Context is everything. "under Unix" wasn't quite
enough context to isolate the behaviour posited.

Try it inside "cat" on each system. It should
echo the line after the first one, and exit after the second.

In that context, all of the above perform exactly as you state.

Phil

 

[Willem]

Phil Carmody wrote:
) Absolutely. Context is everything. "under Unix" wasn't quite
) enough context to isolate the behaviour posited.

How about 'a C program, using getchar(), under Unix' ?
I believe getchar() was in the original context.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[bpascal123]

Ooops,
I have to amend what i said my latest posts. It seems only this code
that makes use of getchar (simply as it is) is not working under
Windows.

I went on to check many files i had been practising c with (tutorial
files) with getchar in it and when getchar is in the file like in the
c-faq.com code, it works only in linux and returns an infinite loop :
from (null):4294967295 in windows.

When getchar has some tweakings in it such as the !='\n' check...it
seems it works on both platforms and not as i said earlier, IT ALSO
WORKS IN WINDOWS, sorry if i misled you.

As a newbie, i understand that getchar() is not easy to deal with. I
guess that if i read until i understand what was said above and keep
on coding.

Replies earlier are of great quality, thanks

Pascal

 

[bpascal123]

Hi,

I came to this conclusion :

Make a code work under windows following C99 standards with some
tweaks and without conio... will be equivalent to implement the code
in linux following C99 standards strictly speaking (without any
tweaks) ?

So far, after 3-4 months of learning, user's inputs seem to be the
most difficult chapter when for a few lines of code as a beginner, i'd
like the code to work on as many plateform as possible.

Many websites show scanf and %s to read strings with classic variables
as well as with pointers (my tutorial as well). To my eyes and
experience, scanf seems very easy to implement on both plateform...

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 ?

Thanks,

Pascal

 

[Keith Thompson]

I understand this isn't the best way to describe something. My excuse
for the delay, it's just that windows takes so long to boot...

The message i get :

"from (null):4294967295,
from (null):4294967295,"
...

It happens when i compile : gcc myfile.c -o myfile.exe

Are you really saying that you get the above message *at compile
time*?

And you see that message when you compile the exact code that you
posted earlier, but not when you compile other C programs?

If so, you have a serious problem with your compiler.

 

[Lew Pitcher]

Hi,
I understand this isn't the best way to describe something. My excuse
for the delay, it's just that windows takes so long to boot...

The message i get :

"from (null):4294967295,
from (null):4294967295,"

For what it's worth, 4294967295 is another way of expressing the value
0xFFFFFFFF. That's a very suspicious number.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[bpascal123]

[...]

I understand this isn't the best way to describe something. My excuse
for the delay, it's just that windows takes so long to boot...

The message i get :

"from (null):4294967295,
from (null):4294967295,"
...

It happens when i compile : gcc myfile.c -o myfile.exe

Are you really saying that you get the above message *at compile
time*?

Yes, when i run gcc myfile.c -o myfile.exe in windows

And you see that message when you compile the exact code that you
posted earlier, but not when you compile other C programs?

Not when i compile other programs, at least not when getchar is
present.

If so, you have a serious problem with your compiler.

What would be this problem about?

I ran a full Kapersky antivirus analysis, and nothing relevant came
out...

 

[Lew Pitcher]

[...]

I understand this isn't the best way to describe something. My excuse
for the delay, it's just that windows takes so long to boot...

The message i get :

"from (null):4294967295,
from (null):4294967295,"
...

It happens when i compile : gcc myfile.c -o myfile.exe

Are you really saying that you get the above message *at compile
time*?

Yes, when i run gcc myfile.c -o myfile.exe in windows

OK, it's sounding more and more like you have a problem with your /compiler/
on Windows. Now, you imply that you use the Gnu Compiler Collection ("GCC")
on Windows, yes? If so, /which/ implementation of GCC are you using? DJGPP?
Cygwin? MingW?

You might try reinstalling your Windows C compiler, along with all the
prerequisite packages.

(BTW: my /guess/ is that the compiler is attempting to read the equivalent
of /dev/null (the "(null)" in your error message) and is encountering an
unexpected EOF (the 4294967295 (or 0xFFFFFFFF or -1) in your error message.
This implies that you are either invoking the compiler incorrectly, or it
is missing some component that would permit it to successfully read your
source code.)



--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Willem]

Lew Pitcher wrote:
) (BTW: my /guess/ is that the compiler is attempting to read the equivalent
) of /dev/null (the "(null)" in your error message)

I think it's more likely that the "(null)" refers to a null pointer.

IIRC, if you pass a null pointer to GCC's printf("%s") you get the string
"(null)"


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

Lew Pitcher wrote:
) (BTW: my /guess/ is that the compiler is attempting to read the equivalent
) of /dev/null (the "(null)" in your error message)

I think it's more likely that the "(null)" refers to a null pointer.

IIRC, if you pass a null pointer to GCC's printf("%s") you get the string
"(null)"

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.

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.

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

 

[Phil Carmody]

Phil Carmody wrote:
) Absolutely. Context is everything. "under Unix" wasn't quite
) enough context to isolate the behaviour posited.

How about 'a C program, using getchar(), under Unix' ?
I believe getchar() was in the original context.

Presuming cat uses getchar as it reproduces the effect at the
console described demonstrates that your guess is quite wrong:

asdf ~ echo -e '\004\004not seen' | cat
not seen

This is a property of the terminal passing characters to the programs,
and not a property of the programs that finally sink the characters
themselves.

Phil

 

[bpascal123]

If so, you have a serious problem with your compiler.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Hi,

The compiler is now working and i can compile any files under windows.
From what i can tell, it wasn't working because i have downloaded a c
code file from the internet and it might have messed with the one of
the compiler files...So problem is solved.

Thx,
Pascal

 

[Keith Thompson]

Hi,

The compiler is now working and i can compile any files under windows.
From what i can tell, it wasn't working because i have downloaded a c
code file from the internet and it might have messed with the one of
the compiler files...So problem is solved.

Glad to hear it.

BTW, the usual way to show who wrote quoted text is to retain the
attribution line ("so-and-so <[email protected]> write:"), not to quote the
signature.

 

[bpascal123]

BTW, the usual way to show who wrote quoted text is to retain the
attribution line ("so-and-so <[email protected]> write:"), not to quote the
signature.

yes, it makes sense

 

[bpascal123]

The message i get :

OK, it's sounding more and more like you have a problem with your /compiler/
on Windows. Now, you imply that you use the Gnu Compiler Collection ("GCC")
on Windows, yes? If so, /which/ implementation of GCC are you using? DJGPP?
Cygwin? MingW?

You might try reinstalling your Windows C compiler, along with all the
prerequisite packages.

(BTW: my /guess/ is that the compiler is attempting to read the equivalent
of /dev/null (the "(null)" in your error message) and is encountering an
unexpected EOF (the 4294967295 (or 0xFFFFFFFF or -1) in your error message.
This implies that you are either invoking the compiler incorrectly, or it
is missing some component that would permit it to successfully read your
source code.)

Hi,

The compiler is working again for any file. It seems as i said in this
thread and in comp.os.msdos.djgpp ..."Compile a simple C code with
getchar and i get : from (null):4294967295 "... it was all about a c
file i had downloaded from a website or a copy/paste

About that 4294967295 number, i remember i have dealt with it early in
learning c book. It was just giving examples on dealing with things
like below and i see this is the same number as the one the compiler
was returning saying something about Null :

short int 0xFFFF : -1
unsigned int 0xFFFF : 65535
long int 0xFFFFFFFF : -1
unsigned long int 0xFFFFFFFF : 4294967295

I haven't really learned how to deal with hexa and alike values as
until recently, i was thinking these would concern people who are
looking to deal with robots, microcontrolers, electronic devices and
drivers... As an accountant, i focus on "more visible" programming
knowledge... However, as i work with linux, i'd like to be able one
day to understand how drivers work.

From your post, i understand 4294967295 is an integer for EOF so when
we say :

....
int c ;
while ( (c = getchar()) != '\n' && c != EOF )
....

<=> instead we could write :
....
while ( (c = getchar()) != '\n' && c != 4294967295 )
....
the latter looks less practical i must admit, but are the 2
equivalent?

Pascal

 

[Keith Thompson]

yes, it makes sense

Then please do so.

Yes, I see the smiley, but you posted another article an hour later in
which you deleted all attribution lines. Please don't do that.