C IO
Bill Cunningham
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
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
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.
--
-ed- emdelY...@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Bill Cunningham
"Emmanuel Delahaye" <emdelY...@noos.fr> wrote in message
news:Xns93A88F2CE42...@130.133.1.4...
>
> What does your C-book say about it?
>
>
> 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.
>
type?
bd
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.
--
Freenet distribution not available
Your boss climbed the corporate ladder, wrong by wrong.
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."
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
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
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"If dolphins are so smart, why do they live in igloos?" -Eric Cartman
lawrenc...@eds.com
>
> 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
lawrenc...@eds.com wrote:
> Richard Heathfield <dont...@address.co.uk.invalid> wrote:
>>
>> 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
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.
Dan Pop
>Richard Heathfield <dont...@address.co.uk.invalid> wrote:
>>
>> 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
lawrenc...@eds.com
>
> 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
people tell me to use FILENAME_MAX. Dan says it's not a good idea.
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.
Bill Cunningham
"Dan Pop" <Dan...@cern.ch> wrote in message
news:bdrphr$sjn$2...@sunnews.cern.ch...
> In <3f007...@corp.newsgroups.com> "Bill Cunningham" <so...@some.net>
writes:
>
> >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
overflows, can FILENAME_MAX produce a buffer overflow? I KNOW you advocate
fgets over gets. My apollogies.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message
>news:bdrphr$sjn$2...@sunnews.cern.ch...
>> In <3f007...@corp.newsgroups.com> "Bill Cunningham" <so...@some.net>
>writes:
>>
>> >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.
>>
>Gee Dan I thought for sure you said that. You've talked alot about buffer
>overflows, can FILENAME_MAX produce a buffer overflow?
Pretty much anything can produce a buffer overflow, if given a chance and
FILENAME_MAX is no exception. Nevertheless, it's still the best choice
when sizing a buffer supposed to receive a file name. Just don't assume
that anything that's *supposed* to be a file name will fit into such a
buffer.
>I KNOW you advocate fgets over gets. My apollogies.
Nope, I don't: both are severely flawed! scanf is much better than
fgets (for getting user input into a buffer) and this is what I
advocate, for a quick and dirty solution.
The standard C library simply does not provide a robust solution for this
problem, each programmer is doomed to write his own.