C IO

[Bill Cunningham]

I said I wouldn't repeat my C problems over again and I intend to keep my
promise. I think my problems in learning C my stem from the fact I'm used
to OOP and not procedural languages. C++ fstream, easy. Java's FileInput,
piece of cake. C's FILE typedef, lost. Is this the proper format for
fread(&p... the p is refering to an address a pointer is refering too right?

Bill

 

[Emmanuel Delahaye]

I said I wouldn't repeat my C problems over again and I intend to keep
my promise. I think my problems in learning C my stem from the fact I'm
used to OOP and not procedural languages. C++ fstream, easy. Java's
FileInput, piece of cake. C's FILE typedef, lost. Is this the proper
format for fread(&p... the p is refering to an address a pointer is
refering too right?

What does your C-book say about it?

306 Committee Draft — January 18, 1999 WG14/N869

7.19.8 Direct input/output functions
7.19.8.1 The fread function

Synopsis
1 #include <stdio.h>
size_t fread(void * restrict ptr,
size_t size, size_t nmemb,
FILE * restrict stream);

Description
2 The fread function reads, into the array pointed to by ptr, up to nmemb
elements whose size is specified by size, from the stream pointed to by
stream. The file position indicator for the stream (if defined) is
advanced by the number of characters successfully read. If an error
occurs, the resulting value of the file position indicator for the stream
is indeterminate. If a partial element is read, its value is
indeterminate.

Returns
3 The fread function returns the number of elements successfully read,
which may be less than nmemb if a read error or end-of-file is
encountered. If size or nmemb is zero, fread returns zero and the contents
of the array and the state of the stream remain unchanged.

 

[Bill Cunningham]

What does your C-book say about it?

306 Committee Draft - January 18, 1999 WG14/N869

7.19.8 Direct input/output functions
7.19.8.1 The fread function

Synopsis
1 #include <stdio.h>
size_t fread(void * restrict ptr,
size_t size, size_t nmemb,
FILE * restrict stream);

Description
2 The fread function reads, into the array pointed to by ptr, up to nmemb
elements whose size is specified by size, from the stream pointed to by
stream. The file position indicator for the stream (if defined) is
advanced by the number of characters successfully read. If an error
occurs, the resulting value of the file position indicator for the stream
is indeterminate. If a partial element is read, its value is
indeterminate.

Returns
3 The fread function returns the number of elements successfully read,
which may be less than nmemb if a read error or end-of-file is
encountered. If size or nmemb is zero, fread returns zero and the contents
of the array and the state of the stream remain unchanged.

It looks like fread() returns a size_t. What the hell. Is size_t a data
type?

Bill

 

[Richard Heathfield]

[size_t is] an unsigned integer type returned (is this an appropriate
term?) by sizeof, and should be used to hold the size of an object or area
in memory.

In fact, it is useful for holding count and size information generally.

To answer your question, yes, the C Standard refers at least once to an
operator "returning" a value[1], and sizeof is an operator.


[1] C89 draft, section 3.3:

"These operators return values that depend on the internal representations
of integers, and thus have implementation-defined aspects for signed
types."

 

[Erik de Castro Lopo]

I said I wouldn't repeat my C problems over again and I intend to keep my
promise. I think my problems in learning C my stem from the fact I'm used
to OOP and not procedural languages. C++ fstream, easy. Java's FileInput,
piece of cake. C's FILE typedef, lost.

Sorry, that just doesn't make sense. What you wrote can be
paraphrased as "I know C++'s fstream and Java's FileInput
so I find them easy". However, for learning the C FILE
streams, you have not bothered to get a book or some other
documentation to help you figure out how to use them.


Erik

 

[lawrence.jones]

To answer your question, yes, the C Standard refers at least once to an
operator "returning" a value[1], and sizeof is an operator.

As far as I can tell, it's exactly once. The more common (and more
correct) usage is that an operator "yields" a value.

-Larry Jones

When I want an editorial, I'll ASK for it! -- Calvin

 

[Richard Heathfield]

[cross-posted to comp.std.c, followups set]

To answer your question, yes, the C Standard refers at least once to an
operator "returning" a value [...]

As far as I can tell, it's exactly once. The more common (and more
correct) usage is that an operator "yields" a value.

Does that mean the Standard is /wrong/ to refer to an operator returning a
value? If so, has a DR been raised?

<snip>

 

[Bill Cunningham]

Yes, it is. It's an unsigned integer type returned (is this an appropriate
term?) by sizeof, and should be used to hold the size of an object or area
in memory.

My C book doesn't really get much into what alot of standard C functions do.
But it does list their parameters.
That's the only critical point with the appendices Dennis wrote in k&r2.

Bill

 

[Dan Pop]

To answer your question, yes, the C Standard refers at least once to an
operator "returning" a value[1], and sizeof is an operator.

As far as I can tell, it's exactly once.

Once in C89, twice in C99 ;-)

The more common (and more
correct) usage is that an operator "yields" a value.

Then, why does the unary & operator *return* the address of its operand
in C99? ;-)

Dan

 

[lawrence.jones]

Then, why does the unary & operator *return* the address of its operand
in C99? ;-)

Experience.

That's what lets you recognize a mistake when you make it again.


-Larry Jones

Somebody's always running my life. I never get to do what I want to do.
-- Calvin

 

[Bill Cunningham]

I dunno, when Dan or Richard speaks it's better to listen. I know a lot of
people tell me to use FILENAME_MAX. Dan says it's not a good idea.

Bill

 

[Richard Heathfield]

I dunno, when Dan or Richard speaks it's better to listen.

Kind words, but you perhaps aren't aware that it's a pretty good idea to
listen to Larry, too. He's on the ISO C committee, for a start.

He and I happen to disagree on the terminology issue, and that is a good
reason to make me re-think my own attitude toward the idea of operators
"returning" values.

As it happens, /having/ re-thought, I still see no problem with that
terminology. Oh well. If we all agreed all the time, what would the world
be like?

<snip>

 

[Dan Pop]

I dunno, when Dan or Richard speaks it's better to listen. I know a lot of
people tell me to use FILENAME_MAX. Dan says it's not a good idea.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I can't remember ever having said that (on the contrary, I'm advocating
the usage of FILENAME_MAX). Please have the decency NOT to put words
in my mouth.

Dan

 

[Bill Cunningham]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I can't remember ever having said that (on the contrary, I'm advocating
the usage of FILENAME_MAX). Please have the decency NOT to put words
in my mouth.

Dan

Gee Dan I thought for sure you said that. You've talked alot about buffer
overflows, can FILENAME_MAX produce a buffer overflow? I KNOW you advocate
fgets over gets. My apollogies.

Bill