Alright, this is puzzling me. Here's what it says:
Exercise 1-7. Write a program to print the value of EOF.
Which is from the book "The C Programming Language". How would I go
about writing that program, I honestly don't understand what it means,
please help. Thanks.
40  18423 
Matt wrote: Alright, this is puzzling me. Here's what it says:
Exercise 1-7. Write a program to print the value of EOF.
Which is from the book "The C Programming Language". How would I go
about writing that program, I honestly don't understand what it
means, please help. Thanks.
EOF is simply an integer.
0 or 1? If so, I just don't get how to do that...would it be like
this?:
#include <stdio.h>
main()
{
int val1, val2;
val1 = 1;
val2 = 0;
printf("EOF is equal to either: %d %d\n", val2, val1);
}
? I'm not sure...
In article <11**********************@f14g2000cwb.googlegroups .com>, no******@gmail.com says... 0 or 1? If so, I just don't get how to do that...would it be like
this?:
#include <stdio.h>
main()
{
int val1, val2;
val1 = 1;
val2 = 0;
printf("EOF is equal to either: %d %d\n", val2, val1);
}
? I'm not sure...
You've got to be kidding. Please say you're joking.
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
Matt wrote: 0 or 1?
No, EOF must be some negative integer. Neither 0 nor 1 qualifies.
If so, I just don't get how to do that...would it be like
this?:
#include <stdio.h>
main()
{
int val1, val2;
val1 = 1;
val2 = 0;
printf("EOF is equal to either: %d %d\n", val2, val1);
}
Not even close. This really isn't so hard:
#include <stdio.h>
int main(void)
{
printf("EOF == %d\n", EOF);
return 0;
}
[(implementation-specific) output]
EOF == -1
Matt wrote: 0 or 1?
Neither. EOF is an integer value that is guaranteed to NOT be a valid
char value. On my system it shows as -1, but it could easily be
anything else on your system.
#include <stdio.h>
main()
{
int val1, val2;
val1 = 1;
val2 = 0;
printf("EOF is equal to either: %d %d\n", val2, val1);
}
? I'm not sure...
How about printf("EOF=%d\n",EOF) ?
Randy Howard wrote: You've got to be kidding. Please say you're joking.
Be kind now. We were all in that some boat before.
"Matt" <no******@gmail.com> writes: 0 or 1? If so, I just don't get how to do that...would it be like
this?:
Since you snipped the context, it's hard to tell what your "0 or 1?"
refers to. Since I just read the parent article, I happen to know
that Jason wrote "EOF is simply an integer." is the parent article.
And the answer to your question is no; EOF does not have the value 0
or 1. (Why would you assume that it does?)
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
Hint: EOF is a macro defined in <stdio.h>. Your program (not quoted
here) does not refer to EOF, so it can't print its value.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
I'm sorry for being stupid, but I just didn't understand the question
in the book. Now I do, thanks for helping Jason and Martin Ambuhl
In article <11**********************@o13g2000cwo.googlegroups .com>, ma******@hotmail.com says...
Randy Howard wrote: You've got to be kidding. Please say you're joking.
Be kind now. We were all in that some boat before.
If you say so. In what schools do they teach that the set of
integers consists of the numbers 0 and 1 only? I want to be
sure not to send my children to one of them.
I never said those were the only integers I know. Shall I write them
all out for you?
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 ,21,22,23,24,25,26,27,28,29,30,31,32,etC.
I just didn't understand the question.
"Matt" <no******@gmail.com> writes: I never said those were the only integers I know. Shall I write them
all out for you?
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 ,21,22,23,24,25,26,27,28,29,30,31,32,etC.
I just didn't understand the question.
Several articles upthread, Jason wrote:
] EOF is simply an integer.
Your response was:
] 0 or 1? If so, I just don't get how to do that...would it be like
] this?:
]
] #include <stdio.h>
]
] main()
] {
] int val1, val2;
]
] val1 = 1;
] val2 = 0;
]
] printf("EOF is equal to either: %d %d\n", val2, val1);
] }
]
] ? I'm not sure...
I'm sure you understand that 0 and 1 aren't the only integers, but
what you wrote *seemed* to imply exactly that.
I'm not trying to give you a hard time, just explaining why some of us
reacted the way we did. (I still don't understand where your "0 or 1?"
comment came from, but that's not important; if you've got a good
handle on it now, I suggest we just drop it and move on.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On Tue, 19 Apr 2005 16:46:12 -0700, Jason wrote:
Matt wrote: 0 or 1?
Neither. EOF is an integer value that is guaranteed to NOT be a valid
char value.
No, EOF is commonly defined as -1 on implementations where char is signed
i.e. can represent the value -1. EOF is required to be a negative value
which means that it can't be a valid *unsigned char* value. That's
relevant because functions like getchar() return a character represented
as an unsigned char value converted to int, so when such functions return
EOF it is a distinct value from any valid character (except in a certain
theoretical situation which isn't usually worth worrying about).
On my system it shows as -1, but it could easily be
anything else on your system.
As long as it is a negative int value.
Lawrence
On Wed, 20 Apr 2005 13:29:21 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote: On Tue, 19 Apr 2005 16:46:12 -0700, Jason wrote:
Matt wrote: 0 or 1?
Neither. EOF is an integer value that is guaranteed to NOT be a valid
char value.
No, EOF is commonly defined as -1 on implementations where char is signed
i.e. can represent the value -1. EOF is required to be a negative value
which means that it can't be a valid *unsigned char* value. That's
relevant because functions like getchar() return a character represented
as an unsigned char value converted to int, so when such functions return
EOF it is a distinct value from any valid character (except in a certain
theoretical situation which isn't usually worth worrying about).
You're referring to sizeof int == 1 or some other case?
Is there any chance of dropping the "plain char may be signed" from the
spec. totally? Since it may be signed or unsigned no conforming code
can depend on it being signed, and everywhere I've seen signed char is
more of a problem (indeed, I don't think I've ever seen it required).
Chris C
Lawrence Kirby wrote: On Tue, 19 Apr 2005 16:46:12 -0700, Jason wrote: Neither. EOF is an integer value that is guaranteed to NOT be a
valid char value.
No, EOF is commonly defined as -1 on implementations where char is
signed i.e. can represent the value -1. EOF is required to be a negative
value which means that it can't be a valid *unsigned char* value.
Correct. I should have said EOF is guaranteed to not be a valid
unsigned char value.
Chris Croughton <ch***@keristor.net> writes:
[...] Is there any chance of dropping the "plain char may be signed" from the
spec. totally? Since it may be signed or unsigned no conforming code
can depend on it being signed, and everywhere I've seen signed char is
more of a problem (indeed, I don't think I've ever seen it required).
Interesting idea. I doubt that it will happen because there are so
many implementations in which plain char is signed (in fact most of
the ones I'm familiar with), and there's probably non-portable code
that depends on that. The code will break anyway when ported to a
system with unsigned plain char. As for the implementations, since
they have to support unsigned char and signed char anyway, making
plain char equivalent to one rather than the other shouldn't be too
much of a burden.
I'm for it, but I don't think they'll listen to me.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
EOF equals to -1
"Matt" <no******@gmail.com>
??????:11**********************@z14g2000cwz.google groups.com... Alright, this is puzzling me. Here's what it says:
Exercise 1-7. Write a program to print the value of EOF.
Which is from the book "The C Programming Language". How would I go
about writing that program, I honestly don't understand what it means,
please help. Thanks.
"Qi Yue" <yu*******@hotmail.com> writes: EOF equals to -1
Please don't top-post.
EOF is not necessarily equal to -1. The standard only guarantees that
it's negative.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Qi Yue wrote: "Matt" <no******@gmail.com>
Alright, this is puzzling me. Here's what it says:
Exercise 1-7. Write a program to print the value of EOF.
Which is from the book "The C Programming Language". How would I go
about writing that program, I honestly don't understand what it means,
EOF equals to -1
WRONG. And please do not top-post, which is rude and unacceptable
in this newsgroup. I fixed this one.
EOF is a macro defined in stdio.h (and other places). All that is
known about it is that is negative, fits into an int, and is
outside the range of char. So the OPs original problem is
isometric to printing the value of an int.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote: Qi Yue wrote:
EOF equals to -1
EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
All that is known about it is that is negative, fits into an int,
True.
and is outside the range of char.
No. If char is signed (as it is on many implementations), then -1
(the most common value of EOF) is well within its range. It's
(necessarily) outside the range of unsigned char.
--
Peter
Peter Nilsson wrote: CBFalconer wrote: Qi Yue wrote:
EOF equals to -1
EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
Thanks for correction. I was thinking of stddef.h, but not so.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On 27 Apr 2005 04:00:49 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote: CBFalconer wrote: Qi Yue wrote: >
> EOF equals to -1
EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
All that is known about it is that is negative, fits into an int,
True.
and is outside the range of char.
No. If char is signed (as it is on many implementations), then -1
(the most common value of EOF) is well within its range.
However ISTR that EOF is guaranteed not to be any char that the
platform uses (else how would the std library functions differentiate
eof from a valid char?), so for some definitions of 'out of range' its
out.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre <ma**********@spamcop.net> writes: On 27 Apr 2005 04:00:49 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:
CBFalconer wrote: Qi Yue wrote:
>
> EOF equals to -1
EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
All that is known about it is that is negative, fits into an int,
True.
and is outside the range of char.
No. If char is signed (as it is on many implementations), then -1
(the most common value of EOF) is well within its range.
However ISTR that EOF is guaranteed not to be any char that the
platform uses (else how would the std library functions differentiate
eof from a valid char?), so for some definitions of 'out of range' its
out.
CBFalconer simply made a slight error (which he later acknowledged).
The value of EOF is required to be a negative number which, because
it's negative, is necessarily outside the range of values of unsigned
char.
There's no implication that EOF needs to be a (signed) char value that
the platform doesn't use. For example, on a system with signed 8-bit
char using ISO 8859-1, the char value -1 corresponds to a printable
character (a 'y' with a diaresis (umlaut)). This isn't a problem for
the standard library functions. For example, fgetc() returns either
EOF (on end-of-file or error) or the input character interpreted as an
*unsigned* char converted to int.
The standard does require (C99 6.2.5p3) that all members of the basic
character set have to have positive values when expressed as plain
char, but that's not necessarily related to EOF. (I'm not even sure
why that requirement exists.) ASCII-based character sets meet this
requirement automatically; EBCDIC-based character sets require plain
char to be unsigned.
(If I were designing the language from scratch today, I'd require
plain char to be unsigned, avoiding all the stuff about having to
interpret characters as unsigned char in various contexts. I'd also
make a stronger distinction between character types and integer types,
and between characters and bytes. Too late.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mark McIntyre wrote: However ISTR that EOF is guaranteed not to be any char that the
platform uses (else how would the std library functions differentiate
eof from a valid char?), so for some definitions of 'out of range' its
out.
Standard Library functions need not be written in portable C,
so there's any number of ways.
But, you can use ferror to differentiate,
for output functions, for example.
int fputs(const char *s, FILE *stream)
{
while (*s != '\0') {
if (putc(*s, stream) == EOF && ferror(stream) != 0) {
return EOF;
}
++s;
}
return 0;
}
feof can be used additionally
to get the whole story of what's going on with input functions.
--
pete
In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:
If I were designing the language from scratch today, I'd require
plain char to be unsigned, avoiding all the stuff about having to
interpret characters as unsigned char in various contexts.
I've wondered whether there are architectures where forcing char to
be unsigned would adversely affect performance - if for example there
was a fast sign-propagating widening operation but not a fast non-
propagating one.
My assumption is that C89 left the signedness of plain char up to the
implementation because there were existing pre-standard implementations
on both sides, but I'd be interested to hear if performance was also
possibly a consideration.
--
Michael Wojcik mi************@microfocus.com
Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!
>Mark McIntyre wrote: However ISTR that EOF is guaranteed not to be any char that the
platform uses (else how would the std library functions differentiate
eof from a valid char?) ...
The fgetc() function returns a value "as if" the (plain) char had
been unsigned to start with, so that on ordinary signed-char 8-bit
systems, fgetc() returns either EOF, or a value in [0..255]. As
long as UCHAR_MAX <= INT_MAX, EOF can be defined as any negative
"int" value.
The fputc() function should logically be called with equivalent
values, but the Standard says that it just converts its argument
to unsigned char -- so fputc(EOF, stream) just does the same thing
as fputc((unsigned char)EOF, stream).
Hosted implementations on machines in which "char" and "int" have
the same range (e.g., 32-bit char and 32-bit int) have a problem.
(The only implementations I know of in which char and int have the
same range are not "hosted", so they do not have to make stdio
work.)
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Standard Library functions need not be written in portable C,
so there's any number of ways.
Indeed. On the other hand, the example below is not particularly
good, I think:
But, you can use ferror to differentiate,
for output functions, for example.
int fputs(const char *s, FILE *stream)
{
while (*s != '\0') {
if (putc(*s, stream) == EOF && ferror(stream) != 0) {
return EOF;
}
++s;
}
return 0;
}
The first problem is that ferror(stream) could be nonzero even
before entering this fputs(). (This is not actually harmful in
this case, as I will explain in a moment, but it suggests a
perhaps-incorrect model. Just because output failed earlier
does not necessarily mean that output will continue to fail.
Consider a floppy disk with a single bad sector, in which writes
to the bad sector fail, but writes to the rest of the disk work.)
The second problem is that the test is redundant, except on those
UCHAR_MAX > INT_MAX implementations that have problems implementing
fgetc(). The reason is that fputc() returns the character put,
i.e., (unsigned char)*s, on success. If UCHAR_MAX <= INT_MAX,
fputc() (and thus putc()) can only return EOF on failure, in the
same way that fgetc() can only return EOF on failure-or-EOF.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote: In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Standard Library functions need not be written in portable C,
so there's any number of ways.
Indeed. On the other hand, the example below is not particularly
good, I think:
But, you can use ferror to differentiate,
for output functions, for example.
int fputs(const char *s, FILE *stream)
{
while (*s != '\0') {
if (putc(*s, stream) == EOF && ferror(stream) != 0) {
return EOF;
}
++s;
}
return 0;
}
The first problem is that ferror(stream) could be nonzero even
before entering this fputs(). (This is not actually harmful in
this case, as I will explain in a moment, but it suggests a
perhaps-incorrect model.
I don't see any problem with putc(*s, stream)
if ferror(stream) is nonzero.
Just because output failed earlier
does not necessarily mean that output will continue to fail.
Consider a floppy disk with a single bad sector, in which writes
to the bad sector fail, but writes to the rest of the disk work.)
I would say that whether or not it continues to write
after a failed bad sector, is up to the implementor,
and in this case that's me.
The second problem is that the test is redundant, except on those
UCHAR_MAX > INT_MAX implementations that have problems implementing
fgetc().
UCHAR_MAX > INT_MAX counts.
This code is for reading and discussing.
I'm not posting an example of code to use.
--
pete
Chris Torek wrote: Mark McIntyre wrote: However ISTR that EOF is guaranteed not to be any char that the
platform uses
(else how would the std library functions differentiate
eof from a valid char?) ...
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Standard Library functions need not be written in portable C,
so there's any number of ways.
Indeed. On the other hand, the example below is not particularly
good, I think:
But, you can use ferror to differentiate,
for output functions, for example.
int fputs(const char *s, FILE *stream)
{
while (*s != '\0') {
if (putc(*s, stream) == EOF && ferror(stream) != 0) {
return EOF;
}
++s;
}
return 0;
}
The first problem is that ferror(stream) could be nonzero even
before entering this fputs(). (This is not actually harmful in
this case, as I will explain in a moment, but it suggests a
perhaps-incorrect model. Just because output failed earlier
does not necessarily mean that output will continue to fail.
Consider a floppy disk with a single bad sector, in which writes
to the bad sector fail, but writes to the rest of the disk work.)
Do you think it would be more better if fputs started
with a clearerr function call?
--
pete
pete wrote:
Chris Torek wrote:Mark McIntyre wrote:
> However ISTR that EOF is guaranteed not to be any char that the
> platform uses
> (else how would the std library functions differentiate
> eof from a valid char?) ...
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Standard Library functions need not be written in portable C,
so there's any number of ways.
Indeed. On the other hand, the example below is not particularly
good, I think:
But, you can use ferror to differentiate,
for output functions, for example.
int fputs(const char *s, FILE *stream)
{
while (*s != '\0') {
if (putc(*s, stream) == EOF && ferror(stream) != 0) {
return EOF;
}
++s;
}
return 0;
}
The first problem is that ferror(stream) could be nonzero even
before entering this fputs(). (This is not actually harmful in
this case, as I will explain in a moment, but it suggests a
perhaps-incorrect model. Just because output failed earlier
does not necessarily mean that output will continue to fail.
Consider a floppy disk with a single bad sector, in which writes
to the bad sector fail, but writes to the rest of the disk work.)
Do you think it would be more better if fputs started
with a clearerr function call?
Or to put it another way:
What are output functions supposed to do
if the error indicator is set
prior to the output function being called?
--
pete
>>Chris Torek wrote: ... ferror(stream) could be nonzero even before entering this
[implementation's output-producing code]. [But] Just because output
failed earlier does not necessarily mean that output will continue
to fail.
pete wrote: Do you think it would be more better if fputs started
with a clearerr function call?
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Or to put it another way:
What are output functions supposed to do
if the error indicator is set
prior to the output function being called?
As far as I can tell, the Standards are not very specific.
For the first question I think it is "obvious" that no output
function (fputs, fwrite, fputc, etc.) should clear the error
indicator at entry. It is supposed to be cumulative, so that:
do_some_output();
do_more_output();
do_yet_more_output();
if (ferror(outstream)) ... handle failure of any earlier output ...
It is even more obvious that clearerr() is wrong because clearerr()
clears both the error and EOF indicators. :-) (Of course, the
EOF indicator should probably be clear in the first place, as it
is set only on failure-in-fgetc()-or-equivalent and cleared by any
fseek or rewind operation, which one would normally find between
input and output attempts. But I believe Standard C allows an
output operation immediately after an input operation that returns
EOF.)
Now, once the EOF flag is set, C99 requires that further read
attempts continue to return EOF:
/* this first line assumes UCHAR_MAX <= INT_MAX */
if (getchar() == EOF && getchar() != EOF)
puts("this is not a valid C99 implementation");
if (feof(stream) && fgetc(stream) != EOF)
puts("this is not a valid C99 implementation");
(C89 allows the puts() calls to occur.) One might then argue that if
error is set in an earlier output operation, further attempts to
output should also fail immediately. But I think neither C89 nor
C99 require this.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
On Fri, 29 Apr 2005 06:07:54 +0000, pete wrote: pete wrote:
Chris Torek wrote: >
> >Mark McIntyre wrote:
> >> However ISTR that EOF is guaranteed not to be any char that the
> >> platform uses
> >> (else how would the std library functions differentiate
> >> eof from a valid char?) ...
> In article <42***********@mindspring.com>
> pete <pf*****@mindspring.com> wrote:
> >Standard Library functions need not be written in portable C,
> >so there's any number of ways.
>
> Indeed. On the other hand, the example below is not particularly
> good, I think:
>
> >But, you can use ferror to differentiate,
> >for output functions, for example.
> >
> >int fputs(const char *s, FILE *stream)
> >{
> > while (*s != '\0') {
> > if (putc(*s, stream) == EOF && ferror(stream) != 0) {
> > return EOF;
> > }
> > ++s;
> > }
> > return 0;
> >}
>
> The first problem is that ferror(stream) could be nonzero even
> before entering this fputs(). (This is not actually harmful in
> this case, as I will explain in a moment, but it suggests a
> perhaps-incorrect model. Just because output failed earlier
> does not necessarily mean that output will continue to fail.
> Consider a floppy disk with a single bad sector, in which writes
> to the bad sector fail, but writes to the rest of the disk work.)
Do you think it would be more better if fputs started
with a clearerr function call?
Or to put it another way:
What are output functions supposed to do
if the error indicator is set
prior to the output function being called?
Output functions should never clear the error indicator. It is a common
and reasonable approach to perform several output operations and then use
ferror() to check if any of them failed. Committee members have stated
that the error indicator is supposed to be sticky.
If fputs() is called with the error indicator already set then it could
either return a failure or attempt to perform the operation as normal.
Either way the error indicator would still be set on return.
Lawrence
I accidentally emailed this to Chris Torek first
with my munged return address. Sorry about that!
Chris Torek wrote: Chris Torek wrote:
... ferror(stream) could be nonzero even before entering this
[implementation's output-producing code].
[But] Just because output
failed earlier does not necessarily mean that output will continue
to fail. pete wrote: Do you think it would be more better if fputs started
with a clearerr function call?
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:Or to put it another way:
What are output functions supposed to do
if the error indicator is set
prior to the output function being called?
As far as I can tell, the Standards are not very specific.
For the first question I think it is "obvious" that no output
function (fputs, fwrite, fputc, etc.) should clear the error
indicator at entry. It is supposed to be cumulative, so that:
do_some_output();
do_more_output();
do_yet_more_output();
if (ferror(outstream)) ... handle failure of any earlier output ...
It is even more obvious that clearerr() is wrong because clearerr()
clears both the error and EOF indicators. :-)
I realised that after some moments of thought.
(Of course, the
EOF indicator should probably be clear in the first place, as it
is set only on failure-in-fgetc()-or-equivalent and cleared by any
fseek or rewind operation, which one would normally find between
input and output attempts. But I believe Standard C allows an
output operation immediately after an input operation that returns
EOF.)
Now, once the EOF flag is set, C99 requires that further read
attempts continue to return EOF:
/* this first line assumes UCHAR_MAX <= INT_MAX */
if (getchar() == EOF && getchar() != EOF)
puts("this is not a valid C99 implementation");
if (feof(stream) && fgetc(stream) != EOF)
puts("this is not a valid C99 implementation");
(C89 allows the puts() calls to occur.) One might then argue that if
error is set in an earlier output operation, further attempts to
output should also fail immediately. But I think neither C89 nor
C99 require this.
Thank you.
But then, is the definition of fputs that I posted,
wrong or is it just not so great?
My intention was for it to be minimilisticly adequate for the DS9k.
--
pete
On 28 Apr 2005 17:23:18 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote: In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:
If I were designing the language from scratch today, I'd require
plain char to be unsigned, avoiding all the stuff about having to
interpret characters as unsigned char in various contexts.
I've wondered whether there are architectures where forcing char to
be unsigned would adversely affect performance - if for example there
was a fast sign-propagating widening operation but not a fast non-
propagating one.
There was one originally very important one: the PDP-11, at least
to-register, the common case for computation though not assignment and
arg passing. Although the impact on programs overall would vary. And
if you (mean to) only force plain char unsigned but still allow
explicitly signed char -- as C did for all other integer types until
<spit> _Bool </> -- the programmer would have the choice.
My assumption is that C89 left the signedness of plain char up to the
implementation because there were existing pre-standard implementations
on both sides, but I'd be interested to hear if performance was also
possibly a consideration.
11 was mostly gone by 89, and IIRC even VAX was beginning to falter.
Though development of the standard had started years earlier.
<sig NOT trimmed> Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!
I'll see your trace data and raise you a Conditional End Bracket and
(I think my favorite) an Isolated Pacing Response. But, at least in
the long-gone days I looked at it, it was Formats *and Protocols*,
which was vital for breaking the 1000-page mark.
- David.Thompson1 at worldnet.att.net
In article <qf********************************@4ax.com>, Dave Thompson <da*************@worldnet.att.net> writes: On 28 Apr 2005 17:23:18 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
I've wondered whether there are architectures where forcing char to
be unsigned would adversely affect performance - if for example there
was a fast sign-propagating widening operation but not a fast non-
propagating one.
There was one originally very important one: the PDP-11, at least
to-register, the common case for computation though not assignment and
arg passing.
Ah. Thanks for the example. I never did anything much with the -11,
so I don't know much about its architecture (though I have read posts
about it on a.f.c).
Although the impact on programs overall would vary. And
if you (mean to) only force plain char unsigned but still allow
explicitly signed char -- as C did for all other integer types until
<spit> _Bool </> -- the programmer would have the choice.
Yes, that's what I meant - platforms where performance might suffer
if C required that plain char be unsigned, rather than making it
implementation-defined.
I'll see your trace data and raise you a Conditional End Bracket and
(I think my favorite) an Isolated Pacing Response. But, at least in
the long-gone days I looked at it, it was Formats *and Protocols*,
which was vital for breaking the 1000-page mark.
At some point IBM split the various protocols off into separate
books. LU6.2, for example, was split off first into the _LU6.2
Format and Protocol Reference Manual_, which later became _LU6.2
Reference: Peer Protocols_.
That leaves my edition of _SNA Formats_ (ver 16, from 1996) at a
trim 700 pages or so.
--
Michael Wojcik mi************@microfocus.com
[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_
On 10 May 2005 15:58:31 GMT,
Michael Wojcik <mw*****@newsguy.com> wrote:
Yes, that's what I meant - platforms where performance might suffer
if C required that plain char be unsigned, rather than making it
implementation-defined.
Besides, if the character set being used was pure ASCII or one of
the equivalent iso646 variants all characters encountered would have
positive values in a 8 bit signed integer type. The eight bit was usualy
a parity bit which were stripped before the characters reached the user
level program. On MS-DOS, which have always used some form of 8-bit
character set, the char type was usualy unsigned, so all 256 character
values could be positive.
Villy
In article <11*********************@o13g2000cwo.googlegroups. com>,
Peter Nilsson <ai***@acay.com.au> wrote:
.... EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
I think the program belows shows that it is defined in other places, too:
#include <stdio.h>
#ifdef EOF
char *s1 = "'ifdef' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (1)!
#endif
#if defined(EOF)
char *s2 = "'if defined' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (2)!
#endif
int main(int argc,char **argv)
{
printf("s1 = '%s'\n",s1);
printf("s2 = '%s'\n",s2);
return 0;
}
Kenny McCormack wrote:
In article <11*********************@o13g2000cwo.googlegroups. com>,
Peter Nilsson <ai***@acay.com.au> wrote:
... EOF is a macro defined in stdio.h (and other places).
It's only defined in <stdio.h>.
I think the program belows shows that it is defined in other places, too:
#include <stdio.h>
#ifdef EOF
char *s1 = "'ifdef' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (1)!
#endif
[...]
No, it doesn't. It merely shows that something, somewhere, has defined
it by the time you hit the #ifdef. It does absolutely nothing to tell
you where it was defined.
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
In article <42***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote: Kenny McCormack wrote:
In article <11*********************@o13g2000cwo.googlegroups. com>,
Peter Nilsson <ai***@acay.com.au> wrote:
... >> EOF is a macro defined in stdio.h (and other places).
>
>It's only defined in <stdio.h>.
I think the program belows shows that it is defined in other places, too:
#include <stdio.h>
#ifdef EOF
char *s1 = "'ifdef' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (1)!
#endif
[...]
No, it doesn't. It merely shows that something, somewhere, has defined
it by the time you hit the #ifdef. It does absolutely nothing to tell
you where it was defined.
They just said that it wasn't defined anywhere other than in stdio.h, and
I disproved that. Obviously, it is defined in my program.
On Sat, 16 Jul 2005 00:06:37 +0000, Kenny McCormack wrote: In article <42***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:Kenny McCormack wrote:
In article <11*********************@o13g2000cwo.googlegroups. com>,
Peter Nilsson <ai***@acay.com.au> wrote:
...
>> EOF is a macro defined in stdio.h (and other places).
>
>It's only defined in <stdio.h>.
I think the program belows shows that it is defined in other places, too:
#include <stdio.h>
#ifdef EOF
char *s1 = "'ifdef' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (1)!
#endif
[...]
No, it doesn't. It merely shows that something, somewhere, has defined
it by the time you hit the #ifdef. It does absolutely nothing to tell
you where it was defined.
They just said that it wasn't defined anywhere other than in stdio.h, and
I disproved that. Obviously, it is defined in my program.
Because <stdio.h> defines it. It is the act of including <stdio.h> which
causes it to be defined. There is nothing else in your program that
defines it.
What the output of your program is saying is that at the point of the
preprocessor tests a definition of EOF is visible. It is not saying that
the definition itself is in your source file.
Lawrence
Lawrence Kirby <lk****@netactive.co.uk> wrote: On Sat, 16 Jul 2005 00:06:37 +0000, Kenny McCormack wrote: In article <42***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:Kenny McCormack wrote:
In article <11*********************@o13g2000cwo.googlegroups. com>,
Peter Nilsson <ai***@acay.com.au> wrote:
...
>> EOF is a macro defined in stdio.h (and other places).
>
>It's only defined in <stdio.h>.
I think the program belows shows that it is defined in other places, too:
#include <stdio.h>
#ifdef EOF
char *s1 = "'ifdef' says EOF is defined here - in "__FILE__;
#else
#error EOF is not defined (1)!
#endif
[...]
No, it doesn't. It merely shows that something, somewhere, has defined
it by the time you hit the #ifdef. It does absolutely nothing to tell
you where it was defined.
They just said that it wasn't defined anywhere other than in stdio.h, and
I disproved that. Obviously, it is defined in my program.
Because <stdio.h> defines it. It is the act of including <stdio.h> which
causes it to be defined. There is nothing else in your program that
defines it.
What the output of your program is saying is that at the point of the
preprocessor tests a definition of EOF is visible. It is not saying that
the definition itself is in your source file.
First Peter Nilsson said the macro EOF was defined [had a definition]
only in <stdio.h>. Then Kenny McCormack said (and gave "a proof")
it was defined [remained defined] elsewhere, too (ie. after
#include <stdio.h>).
In a way, both were right.
At first I thought it was meant to be joke, until you people started
to treat it so seriously. :-)
--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g` This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: G Kannan |
last post by:
Hey all!
I have written a perl script to retrieve information from a HTML Form
and insert the data into an Oracle database table. I am gettting the
the following error message:
"Use of...
|
by: otto |
last post by:
i need to read a variable in a javascript and translate it to a form in
html
the javascript variable is:
<SCRIPT LANGUAGE='JavaScript'>RF2N('Total');</script>
and i need to put that...
|
by: Eric Chang |
last post by:
I was working on this simple form with radio boxes.
And when I click on one of the radio box, it tell me the value is
"undefined"
Why is that ? I did defined the value of each radio box:
...
|
by: cwizard |
last post by:
I'm calling on a function from within this form, and there are values set
but every time it gets called I get slammed with a run time error...
document.frmKitAmount.txtTotalKitValue is null or not...
|
by: dbuchanan |
last post by:
Hello,
Here is the error message;
----------------------------
Exception Message:
ForeignKeyConstraint Lkp_tbl040Cmpt_lkp302SensorType requires the child
key values (5) to exist in the...
|
by: tania |
last post by:
i have this table in my database:
CREATE TABLE FILM(
F_ID INT(5) NOT NULL AUTO_INCREMENT,
F_TITLE VARCHAR(40) NOT NULL,
DIRECTOR_FNAME VARCHAR(20) NOT NULL,
DIRECTOR_LNAME VARCHAR(20) NOT NULL,...
|
by: cbellew |
last post by:
Hi guys,
I have a problem with an option group and a two corresponding text boxes. When the user chooses an option value i want the text boxes to populate with text dependent on the choice made....
|
by: Astley Le Jasper |
last post by:
Sorry for the numpty question ...
How do you find the reference name of an object?
So if i have this
bob = modulename.objectname()
how do i find that the name is 'bob'
|
by: vivekgs2007 |
last post by:
Hi i am doing a application that add the rate of the staff evaluation please go through o=it and need help
<?php
include("../db.php");
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD...
|
by: Vivekneo |
last post by:
Hi
I am very new to web programming, trying to achieve a task, I have a form with 3 dropdown box and a text field(which is readonly).
My problem now is, after selecting the above 3 dropdown boxes,...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
