By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,002 Members | 1,299 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,002 IT Pros & Developers. It's quick & easy.

Must fread() use fgetc()?

P: n/a
Hi,

While reading ISO C Standard, I found follow text in 7.19.8.1:

size_t fread(void *restrict ptr, size_t SIZE, ...)

... For each object, SIZE calls are made to the fgetc function
and the results stored, in the order read, in an array of
unsigned char exactly overlaying the object.

My question is, should any fread() implementation call fgetc()?

Why not getc()? The standard says that getc() might be implemented
in macros. So I think fread() should prefer getc() over fgetc().

Actually, I wonder why Standard mention fgetc() to explain fread()
in the first place. In my opinion, it is enough to say that "read
a character" than "call fgetc()...". No?

If I misunderstood something, please let me know.

Regards,

May 1 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
In article <11**********************@u72g2000cwu.googlegroups .com>,
<ci****@gmail.com> wrote:
size_t fread(void *restrict ptr, size_t SIZE, ...)

... For each object, SIZE calls are made to the fgetc function
and the results stored, in the order read, in an array of
unsigned char exactly overlaying the object.

My question is, should any fread() implementation call fgetc()?
Everything in the standard is covered by the "as-if" rule, so a real
implementation doesn't need to actually implement it like that. It
just has to behave AS IF it was implemented like that.
Why not getc()? The standard says that getc() might be implemented
in macros. So I think fread() should prefer getc() over fgetc().
Real fread() implementations probably don't call either. There's
no way for you to tell (except by reading the source, which doesn't
count).
Actually, I wonder why Standard mention fgetc() to explain fread()
in the first place. In my opinion, it is enough to say that "read
a character" than "call fgetc()...". No?


It's just a way of simplifying the explanation and avoiding
duplication. It means that everything that's required of fgetc()
alos applies to fread().

-- Richard
May 1 '06 #2

P: n/a
On 1 May 2006 06:19:53 -0700, ci****@gmail.com wrote in comp.lang.c:
Hi,

While reading ISO C Standard, I found follow text in 7.19.8.1:

size_t fread(void *restrict ptr, size_t SIZE, ...)

... For each object, SIZE calls are made to the fgetc function
and the results stored, in the order read, in an array of
unsigned char exactly overlaying the object.

My question is, should any fread() implementation call fgetc()?
All input and output functions in C are defined in terms of calls to
fgetc() and fputc(). They do not actually need to be implemented that
way, they must merely operate "as if" they were implemented by calls
to fgetc() or fputs().
Why not getc()? The standard says that getc() might be implemented
in macros. So I think fread() should prefer getc() over fgetc().
If getc() is implemented as a macro, the standard requires that it
must be equivalent to fgetc().
Actually, I wonder why Standard mention fgetc() to explain fread()
in the first place. In my opinion, it is enough to say that "read
a character" than "call fgetc()...". No?
Once again, the standard defines all stream input and output, whether
performed by functions like fread() and fwrite(), or line oriented
like fgets() and fputs(), or formatted like fscanf() and fprintf(), in
terms of the functions fgetc() and fputs(), respectively.

That means that the features and semantics of reading a character from
a stream, or writing a character to a stream, needs to be defined only
once each, in those two functions. All other functions that read or
write streams operate the same as these two.
If I misunderstood something, please let me know.

Regards,


--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
May 1 '06 #3

P: n/a


Jack Klein wrote On 05/01/06 16:55,:
On 1 May 2006 06:19:53 -0700, ci****@gmail.com wrote in comp.lang.c:

Hi,

While reading ISO C Standard, I found follow text in 7.19.8.1:

size_t fread(void *restrict ptr, size_t SIZE, ...)

... For each object, SIZE calls are made to the fgetc function
and the results stored, in the order read, in an array of
unsigned char exactly overlaying the object.

My question is, should any fread() implementation call fgetc()?

All input and output functions in C are defined in terms of calls to
fgetc() and fputc(). They do not actually need to be implemented that
way, they must merely operate "as if" they were implemented by calls
to fgetc() or fputs().

Why not getc()? The standard says that getc() might be implemented
in macros. So I think fread() should prefer getc() over fgetc().

If getc() is implemented as a macro, the standard requires that it
must be equivalent to fgetc().


Almost, but you left out the crucial loophole starting with
the word "except:"

7.19.7.5/2: "The getc function is equivalent to fgetc,
except that if it is implemented as a macro, it may
evaluate stream more than once, so the argument should
never be an expression with side effects."

In an implementation where fread() is a macro, it must arrange
to evaluate each of its arguments exactly once (7.1.4/1), a
requirement that also applies to fgetc() but not to getc(). I
imagine that the authors of the Standard felt it might make the
document less clear if the fread() definition used getc() and
dragged in the multiple-evaluation hobgoblin; the definition
using fgetc() avoids the potential confusion.

--
Er*********@sun.com

May 1 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.