Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #102713 > unrolled thread

Using fread function

Back to article view | Back to comp.lang.c

Contents

  Using fread function janus <emekamicro@gmail.com> - 2017-01-29 10:07 -0800
    Re: Using fread function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 14:31 -0500
      Re: Using fread function supercat@casperkitty.com - 2017-01-30 08:03 -0800
      Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 13:59 -0800
        Re: Using fread function jameskuyper@verizon.net - 2017-02-05 11:40 -0800
          Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 22:04 -0800
            Re: Using fread function jameskuyper@verizon.net - 2017-02-09 05:39 -0800
              Re: Using fread function supercat@casperkitty.com - 2017-02-09 07:47 -0800
                Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-09 09:19 -0800
                  Re: Using fread function supercat@casperkitty.com - 2017-02-09 09:55 -0800
                    Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-09 12:10 -0800
                      Re: Using fread function supercat@casperkitty.com - 2017-02-09 13:01 -0800
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 09:36 -0800
                  Re: Using fread function supercat@casperkitty.com - 2017-02-12 10:52 -0800
                    Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:19 -0800
                      Re: Using fread function supercat@casperkitty.com - 2017-02-20 09:35 -0800
                        Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-20 09:52 -0800
                          Re: Using fread function supercat@casperkitty.com - 2017-02-20 11:15 -0800
                            Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-20 11:45 -0800
                              Re: Using fread function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-20 15:38 -0500
                                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 12:12 -0800
                                  Re: Using fread function jameskuyper@verizon.net - 2017-02-24 10:37 -0800
                        Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 05:04 -0800
                          Re: Using fread function supercat@casperkitty.com - 2017-02-23 07:58 -0800
                            Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 11:48 -0800
                              Re: Using fread function jameskuyper@verizon.net - 2017-02-25 13:44 -0800
                                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 13:12 -0700
                                  Re: Using fread function supercat@casperkitty.com - 2017-04-17 13:50 -0700
              Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 09:31 -0800
    Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-29 13:14 -0800
    Re: Using fread function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-30 08:18 -0800
      Re: Using fread function supercat@casperkitty.com - 2017-01-30 08:44 -0800
      Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-30 11:58 -0800
        Re: Using fread function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-30 13:05 -0800
          Re: Using fread function supercat@casperkitty.com - 2017-01-30 13:39 -0800
          Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-30 13:57 -0800

Page 2 of 2 — ← Prev page 1 [2]

#104519

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 02/20/2017 02:45 PM, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>>> So again, I ask, what do you mean by a "Standard C program"?  Or, to
>>> put it another way, what must a collection of source text do, and
>>> refrain from doing, to qualify as a "Standard C program"?
>>
>> As far as I can tell, the first use of the phrase "Standard C program"
>> is in the article to which I'm replying.  I suggest you figure out who
>> who, if anyone, actually used that phrase and ask them.
>
> He was certainly incorrect to talk about 'your use of the term
> "Standard C Program"' in his response to a message of yours, since you
> never used anything like that term.
> However, Tim Rentsch did talk about "programs written in Standard C",
> [...]

If you are going to quote me (ie, with text in quotation marks),
please quote me exactly.

[toc] | [prev] | [next] | [standalone]

#104617

On Thursday, February 23, 2017 at 3:12:25 PM UTC-5, Tim Rentsch wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
...
> > However, Tim Rentsch did talk about "programs written in Standard C",
> > [...]
> 
> If you are going to quote me (ie, with text in quotation marks),
> please quote me exactly.

Sorry: "programs that are written in standard C".

[toc] | [prev] | [next] | [standalone]

#104488

supercat@casperkitty.com writes:

> On Sunday, February 19, 2017 at 11:19:50 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>> The "language" in which Strictly Conforming programs can be written may be
>>> usable for some purposes, but it is totally unsuitable for most of the
>>> tasks which are performed by programs written in various dialects of C.
>>
>> You are confusing two different classes of program here, to wit,
>> programs that are written in standard C, and programs that are
>> strictly conforming.  My comment is about standard C, not about
>> C programs that are strictly conforming.
>
> The Standard defines two classes of programs:  those which are Strictly
> Conforming, and those which are Conforming but not Strictly Conforming.
> I would interpret the class of "Strictly Conforming" programs as including
> some which make use of some implementation-defined behaviors but will meet
> their stated requirements with any combination of such behaviors that
> conforming implementations could define (and thus to not rely upon any
> Implementation Defined behaviors being defined in any *particular* fashion).
>
> The Standard does not define any category of "Standard C" programs other
> than the above, and the category of "Conforming" programs is so broad that
> I don't think all such programs can be meaningfully described as being in
> the same language, so if you're not referring to the category of "Strictly
> Conforming" programs extended as above, to what are you referring?

Did you ever work in a job where you got paid by the word?  Just
curious.

An important part of good writing is removing unnecessary stuff.
Here you could have said just "What do you mean by standard C?"

By standard C I mean the language described in the ISO C standard,
not including any constructions that would draw a mandatory
diagnostic or run afoul of compile-time undefined behavior (eg,
a line starting with # other than one of the usual pre-processing
directives).  Extensions are probably okay provided they don't
alter either of the two conditions in the last sentence.

[toc] | [prev] | [next] | [standalone]

#104498

On Thursday, February 23, 2017 at 7:04:46 AM UTC-6, Tim Rentsch wrote:
> By standard C I mean the language described in the ISO C standard,
> not including any constructions that would draw a mandatory
> diagnostic or run afoul of compile-time undefined behavior (eg,
> a line starting with # other than one of the usual pre-processing
> directives).  Extensions are probably okay provided they don't
> alter either of the two conditions in the last sentence.

That does not seem like a particularly useful category to define.  It
also seems a bit ambiguous.  Is the following, for example, written in
what you would call "Standard C"?

    #include <stdint.h>
    #include <stdio.h>
    int main(void) { 
      int_least18_t q = 131071;
      return printf("%ld\n", (long)(q+1));
    }

Some implementations would reject such code together, some might be required
to output 131072, and some might accept it but yield arbitrary behavior.  So
is it "standard C"?

[toc] | [prev] | [next] | [standalone]

#104714

supercat@casperkitty.com writes:

> On Thursday, February 23, 2017 at 7:04:46 AM UTC-6, Tim Rentsch wrote:
>> By standard C I mean the language described in the ISO C standard,
>> not including any constructions that would draw a mandatory
>> diagnostic or run afoul of compile-time undefined behavior (eg,
>> a line starting with # other than one of the usual pre-processing
>> directives).  Extensions are probably okay provided they don't
>> alter either of the two conditions in the last sentence.
>
> That does not seem like a particularly useful category to define.

Hey don't blame me for your question!  I was just using the
term - it was you who asked for a definition.

> It
> also seems a bit ambiguous.  Is the following, for example, written in
> what you would call "Standard C"?

The answer to that is a definite no.  But then I didn't use
the term "Standard C".

>     #include <stdint.h>
>     #include <stdio.h>
>     int main(void) {
>       int_least18_t q = 131071;
>       return printf("%ld\n", (long)(q+1));
>     }
>
> Some implementations would reject such code together, some might be required
> to output 131072, and some might accept it but yield arbitrary behavior.  So
> is it "standard C"?

Can it be accepted by a conforming implementation, without any
mandatory diagnostics, without any compile-time undefined
behavior, and without using any extensions that would change
either of the previous two aspects?  Is that a question you are
able to answer?  If it is, then can you explain why you would
have trouble answering your own question?

[toc] | [prev] | [next] | [standalone]

#104722

On Saturday, February 25, 2017 at 2:48:13 PM UTC-5, Tim Rentsch wrote:
> supercat@casperkitty.com writes:
> 
> > On Thursday, February 23, 2017 at 7:04:46 AM UTC-6, Tim Rentsch wrote:
> >> By standard C I mean the language described in the ISO C standard,
> >> not including any constructions that would draw a mandatory
> >> diagnostic or run afoul of compile-time undefined behavior (eg,
> >> a line starting with # other than one of the usual pre-processing
> >> directives).  Extensions are probably okay provided they don't
> >> alter either of the two conditions in the last sentence.
> >
> > That does not seem like a particularly useful category to define.
> 
> Hey don't blame me for your question!  I was just using the
> term - it was you who asked for a definition.

You're the one who's use of the term prompted the question. It seems to me to
be a reasonable thing to ask you what you meant by that term.

> > It
> > also seems a bit ambiguous.  Is the following, for example, written in
> > what you would call "Standard C"?
> 
> The answer to that is a definite no.  But then I didn't use
> the term "Standard C".

His question traces back to your message
<https://groups.google.com/d/msg/comp.lang.c/_p8LSNnsRdA/i2rVPAe5AQAJ> in which
you did introduce the term "standard C" into the discussion. It was not used in
the message you were responding to, nor in any message preceding that one. Why
are you so reluctant to accept responsibility for the meaning of a term you
introduced into the discussion? It's certainly not a term that the standard
itself defines.

> >     #include <stdint.h>
> >     #include <stdio.h>
> >     int main(void) {
> >       int_least18_t q = 131071;
> >       return printf("%ld\n", (long)(q+1));
> >     }
> >
> > Some implementations would reject such code together, some might be required
> > to output 131072, and some might accept it but yield arbitrary behavior.  So
> > is it "standard C"?
> 
> Can it be accepted by a conforming implementation, without any
> mandatory diagnostics, without any compile-time undefined
> behavior, and without using any extensions that would change
> either of the previous two aspects? ...

It doesn't contain a #error directive, so a conforming implementation is
allowed to accept it. A conforming implementation is allowed to define
int_least18_t in <stdint.h>. If so, no diagnostic is required. A conforming
implementation is allowed to have INT_MAX>131071, so q+1 doesn't overflow. I
see no other possible reason why a diagnostic should be mandatory, or the
behavior should be undefined, but I might easily have missed something. Whether
int_least18_t is supported is unspecified behavior, and the value of INT_MAX is
implementation-defined - neither constitutes an extension to C. The answer to
your question seems to me to be "Yes".

Above you said "No" when asked whether this code is written in Standard C -
which feature of your definition does it violate?

[toc] | [prev] | [next] | [standalone]

#108244

jameskuyper@verizon.net writes:

> On Saturday, February 25, 2017 at 2:48:13 PM UTC-5, Tim Rentsch wrote:
>> supercat@casperkitty.com writes:
>>
>>> On Thursday, February 23, 2017 at 7:04:46 AM UTC-6, Tim Rentsch wrote:
>>>> By standard C I mean the language described in the ISO C standard,
>>>> not including any constructions that would draw a mandatory
>>>> diagnostic or run afoul of compile-time undefined behavior (eg,
>>>> a line starting with # other than one of the usual pre-processing
>>>> directives).  Extensions are probably okay provided they don't
>>>> alter either of the two conditions in the last sentence.
>>>
>>> That does not seem like a particularly useful category to define.
>>
>> Hey don't blame me for your question!  I was just using the
>> term - it was you who asked for a definition.
>
> You're the one who's use of the term prompted the question.  It
> seems to me to be a reasonable thing to ask you what you meant by
> that term.

I don't mind being asked to explain what I meant.  What I object
to is the insinuation that I was trying to coin a new term, or
to sharply define it - neither of which I was doing - rather than
just using a phrase in ordinary English, without needing a sharp
definition.

Note that supercat followed his usual dickish habit of oversnipping
quoted material, to obscure the context and change the subject.

>>> It
>>> also seems a bit ambiguous.  Is the following, for example, written in
>>> what you would call "Standard C"?
>>
>> The answer to that is a definite no.  But then I didn't use
>> the term "Standard C".
>
> His question traces back to your message
> <https://groups.google.com/d/msg/comp.lang.c/_p8LSNnsRdA/i2rVPAe5AQAJ> in which
> you did introduce the term "standard C" into the discussion.

Yes, I used the phrase "standard C".  Not "Standard C".  Capitalizing
a phrase makes it a proper noun, which is exactly what I did /not/
want to do.

> It was not used in the message you were responding to, nor in any
> message preceding that one.  Why are you so reluctant to accept
> responsibility for the meaning of a term you introduced into the
> discussion?

Because I didn't introduce a term, I simply wrote a phrase in
ordinary English.

[toc] | [prev] | [next] | [standalone]

#108247

On Monday, April 17, 2017 at 3:12:25 PM UTC-5, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
> 
> > On Saturday, February 25, 2017 at 2:48:13 PM UTC-5, Tim Rentsch wrote:
> >> supercat@casperkitty.com writes:
> >>
> >>> On Thursday, February 23, 2017 at 7:04:46 AM UTC-6, Tim Rentsch wrote:
> >>>> By standard C I mean the language described in the ISO C standard,
> >>>> not including any constructions that would draw a mandatory
> >>>> diagnostic or run afoul of compile-time undefined behavior (eg,
> >>>> a line starting with # other than one of the usual pre-processing
> >>>> directives).  Extensions are probably okay provided they don't
> >>>> alter either of the two conditions in the last sentence.
> >>>
> >>> That does not seem like a particularly useful category to define.
> >>
> >> Hey don't blame me for your question!  I was just using the
> >> term - it was you who asked for a definition.
> >
> > You're the one who's use of the term prompted the question.  It
> > seems to me to be a reasonable thing to ask you what you meant by
> > that term.
> 
> I don't mind being asked to explain what I meant.  What I object
> to is the insinuation that I was trying to coin a new term, or
> to sharply define it - neither of which I was doing - rather than
> just using a phrase in ordinary English, without needing a sharp
> definition.
> 
> Note that supercat followed his usual dickish habit of oversnipping
> quoted material, to obscure the context and change the subject.

I'm quoting all of the above, so as to avoid any accusation of selective
editing.  I'll also include all of your text from Feb. 19 which I think
was where this sub-issue started:

|> On Sunday, February 12, 2017 at 11:36:31 AM UTC-6, Tim Rentsch wrote:
|>> supercat writes:
|>>> I also find it peculiar that the Standard doesn't require that
|>>> implementations do anything useful with qualifiers like "restrict" and
|>>> "register" but requires that even implementations where they serve no
|>>> purpose must still go through the effort of validating them.  [...]
|>>
|>> It does because the point of a language standard is to define
|>> a standard language.  Apparently that's a deeper concept than
|>> I realized.
|>
|> What fraction of tasks that are done by programs written for various C
|> implementations could be accomplished by Strictly Conforming programs in
|> a way that was just as readable and just as efficient?
|>
|> The "language" in which Strictly Conforming programs can be written may be
|> usable for some purposes, but it is totally unsuitable for most of the
|> tasks which are performed by programs written in various dialects of C.
|
|You are confusing two different classes of program here, to wit,
|programs that are written in standard C, and programs that are
|strictly conforming.  My comment is about standard C, not about
|C programs that are strictly conforming.

My question was, and remains, what criteria would distinguish "programs
that are written in standard C" [your exact phrasing] from other text files
that would cause some implementations to behave in useful fashion?

You seem to offer a definition on Feb 25:

|Can it be accepted by a conforming implementation, without any
|mandatory diagnostics, without any compile-time undefined
|behavior, and without using any extensions that would change
|either of the previous two aspects?  Is that a question you are
|able to answer?  If it is, then can you explain why you would
|have trouble answering your own question? 

but I'm not clear what exactly you mean by the last point.  If some
implementations would be required to define certain types, and others
would be forbidden from doing so, should such types be regarded as
"extensions" for purposes of the above definition?

[toc] | [prev] | [next] | [standalone]

#103739

jameskuyper@verizon.net writes:

> On Thursday, February 9, 2017 at 1:04:12 AM UTC-5, Tim Rentsch wrote:
> ...
>> Seems like rather a long way of saying, "I think you're right.
>> It seems clear that the intention is that there be undefined
>> behavior in such cases, but AFAICT the Standard never actually
>> comes right out and says so (or gives any explicit statement to
>> that effect)."
>
> It would have been, had that been what I wanted to say.  What I
> wanted to say was "You're right, and here's an explanation why."
> Obviously, you don't need the explanation - its for other people
> reading this thread.  [...]

I see.  Thank you for the explanation (ie, the meta-explanation).

[toc] | [prev] | [next] | [standalone]

#102729

janus <emekamicro@gmail.com> writes:
> I just noticed that swapping the positions of the inner parameters
> does not have any material effect on result. That led me to think that
> "fread" function just multiple the two parameters.
>
> size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
>
> size_t fread(void *ptr,  size_t nmemb, size_t size, FILE *stream);
>
> Is my position correct?

I wrote about this here:

http://stackoverflow.com/a/8589688/827263

Quick summary: fread() returns the number of elements it was able
to read, and the ordering of the 2nd and 3rd arguments lets you
define what an element is.  Read a single data element if a partial
read is no better than not reading anything at all. Read in smaller
chunks if partial reads are useful.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#102760

On Sunday, January 29, 2017 at 6:07:29 PM UTC, janus wrote:
> Hello All,
> 
> I just noticed that swapping the positions of the inner parameters does not have any material effect on result. That led me to think that "fread" function just multiple the two parameters.
> 
> size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
> 
> size_t fread(void *ptr,  size_t nmemb, size_t size, FILE *stream);
> 
> Is my position correct?
> 
Essentially yes. Having two parameters is pretty useless and you might as well pass
in a size of memory buffer you wish to fill. It also tends to encourage code such 
as

  fread(x, sizeof(double), 10, fp);

which isn't very portable. 

The only slight advantage is that it tells you how many doubles were read correctly.
The number of times the information "7 out of 10" is more useful than "not all ten"
is vanishingly low, however.
 

[toc] | [prev] | [next] | [standalone]

#102761

On Monday, January 30, 2017 at 10:18:44 AM UTC-6, Malcolm McLean wrote:
> Essentially yes. Having two parameters is pretty useless and you might as well pass
> in a size of memory buffer you wish to fill. It also tends to encourage code such 
> as
> 
>   fread(x, sizeof(double), 10, fp);
> 
> which isn't very portable. 
> 
> The only slight advantage is that it tells you how many doubles were read correctly.
> The number of times the information "7 out of 10" is more useful than "not all ten"
> is vanishingly low, however.

I wonder if the intention was that an input stream which currently had
74 bytes but might receive more would input nine complete 8-byte values
and leave two pending?  Not all operating systems could support such a
construct (they may have no way of finding out how much data is left
without trying to read it, and no way to push back data that had been
read) but for a system which could support it such a construct could be
useful.

[toc] | [prev] | [next] | [standalone]

#102789

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, January 29, 2017 at 6:07:29 PM UTC, janus wrote:
>> I just noticed that swapping the positions of the inner parameters
>> does not have any material effect on result. That led me to think
>> that "fread" function just multiple the two parameters.
>> 
>> size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
>> 
>> size_t fread(void *ptr,  size_t nmemb, size_t size, FILE *stream);
>> 
>> Is my position correct?
>> 
> Essentially yes.

Essentially no.

>                  Having two parameters is pretty useless and you might as well pass
> in a size of memory buffer you wish to fill. It also tends to encourage code such 
> as
>
>   fread(x, sizeof(double), 10, fp);
>
> which isn't very portable. 

How is that not portable (assuming x points to a chunk of memory big
enough to hold 10 doubles)?

> The only slight advantage is that it tells you how many doubles were read correctly.
> The number of times the information "7 out of 10" is more useful than "not all ten"
> is vanishingly low, however.

If the distinction isn't useful, you can read a single chunk of 10
doubles.  If it is, you can read 10 elements of sizeof(double) bytes
each.  I presume that flexibility is quite intentional.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#102799

On Monday, January 30, 2017 at 7:57:46 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> >   fread(x, sizeof(double), 10, fp);
> >
> > which isn't very portable. 
> 
> How is that not portable (assuming x points to a chunk of memory big
> enough to hold 10 doubles)?
> 
Because it breaks if your machine representation isn't the same as the
binary file. 

I've collected a series of routines here. Even the integral cases aren't entirely straighforwards and intuitive.

https://github.com/MalcolmMcLean/ieee754

[toc] | [prev] | [next] | [standalone]

#102804

On Monday, January 30, 2017 at 3:05:56 PM UTC-6, Malcolm McLean wrote:
> On Monday, January 30, 2017 at 7:57:46 PM UTC, Keith Thompson wrote:
> > How is that not portable (assuming x points to a chunk of memory big
> > enough to hold 10 doubles)?
> > 
> Because it breaks if your machine representation isn't the same as the
> binary file. 

For files that will be read back on the same machine as they were written,
that is a complete non-problem.  Otherwise, the extremely vast majority of
C implementations use one of two representations, so a requirement that
code use a particular format would limit the simply-written code to the
implementations which use that format--not universal portability, but still
portable to a rather wide range of platforms.

If the maintainers of the C Standard want to facilitate more portable code,
they should include optional types whose exact layout would be rigidly
specified by the Standard and/or controlled by the programmer.  A quality
implementation for a given platform should include, at minimum, the types
the hardware natively provides, but could also support others.

If instead of using "double" code used "__fp_ieee754_double_8l" which was
defined by the Standard as indicating an IEEE-754 double stored as eight
octets LSB first, some compilers for a big-endian machine might refuse to
accept that type, but some could generate code which performed the necessary
byte-swapping operations to use it.

Note that inclusion of such types would not "discriminate" against unusual
architectures, but quite the opposite: it would encourage people targeting
more commonplace architectures to write code in a fashion that would allow
implementations for unusual architectures to automatically generate the
bit-level code necessary to import and export data from other machines.

[toc] | [prev] | [next] | [standalone]

#102806

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, January 30, 2017 at 7:57:46 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> >   fread(x, sizeof(double), 10, fp);
>> >
>> > which isn't very portable. 
>> 
>> How is that not portable (assuming x points to a chunk of memory big
>> enough to hold 10 doubles)?
>> 
> Because it breaks if your machine representation isn't the same as the
> binary file. 

You're right, of course.  I should have thought of that (I've made the
same point myself enough times).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web