fread/fwrite

[Bill Cunningham]

That second parameter in fread/fwrite is most always simply 1 isn't it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused me. Are
there situations where it wouldn't be 1? If so when?

Bill

[Barry Schwarz]

On Sat, 29 Jul 2017 22:11:42 -0400, "Bill Cunningham"

Post by Bill Cunningham
That second parameter in fread/fwrite is most always simply 1 isn't it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused me. Are
there situations where it wouldn't be 1? If so when?

If you are reading an undetermined number of bytes, the specifying 1
for the second parameter (nominally named size in the standard) and
some maximum quantity for the third parameter (nominally named nmemb)
will allow fread to return the number of bytes read.

On the other hand, if you are attempting to read a number of fixed
length blocks, then size should be set to the length of a block and
nmemb set to some maximum quantity (of blocks, not bytes). If fread
retrieves x complete blocks, which obviously must not be more than
nmemb, it returns x and you immediately know how many blocks are in
your buffer. If x is less than nmemb, you can use feof and ferror to
determine why fread did not retrieve all the data you asked for.

[Rick C. Hodgin]

The 3rd is the count, and the second is the size of each thing being
written. You can write that way if you prefer, and the return value
will be the count written.

Most people use bytes and a 1 and then the count is byte count.

I don't see the reason to have the 2nd parameter. But, I've also
moved to _sopen() for shared file access in most cases. Then I use
read() and write() instead of fread() and fwrite().

Thank you,
Rick C. Hodgin

[Keith Thompson]

Post by Bill Cunningham
That second parameter in fread/fwrite is most always simply 1 isn't it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused me. Are
there situations where it wouldn't be 1? If so when?

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

[Bill Cunningham]

Post by Keith Thompson

Post by Bill Cunningham
That second parameter in fread/fwrite is most always simply 1 isn't it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused me. Are
there situations where it wouldn't be 1? If so when?

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

I was looking at n1276.pdf yesterday. I was looking in the §7 parts. I
see now.

Bill

[Keith Thompson]

Post by Bill Cunningham

Post by Keith Thompson

Post by Bill Cunningham
That second parameter in fread/fwrite is most always simply 1 isn't it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused me. Are
there situations where it wouldn't be 1? If so when?

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

I was looking at n1276.pdf yesterday. I was looking in the §7 parts. I
see now.

I presume you mean n1256.pdf. (Note that n1570.pdf, available in the
same location, is a draft of the current standard.)

[Bill Cunningham]

Post by Keith Thompson

Post by Bill Cunningham

Post by Keith Thompson

Post by Bill Cunningham
That second parameter in fread/fwrite is most always simply 1
isn't
it.
All the code I've been looking at it seems that all it ever is. The 3rd
parameter though changes. The 2nd and 3rd parameters always confused
me.
Are
there situations where it wouldn't be 1? If so when?

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

I was looking at n1276.pdf yesterday. I was looking in the §7 parts. I
see now.

I presume you mean n1256.pdf. (Note that n1570.pdf, available in the
same location, is a draft of the current standard.)

Yes, yes. Sorry that's it. 1256.pdf. I lost it several times. Now in
backup storage.

Bill

[Bill Cunningham]

"Keith Thompson" <kst-***@mib.org> wrote in message news:***@kst-u.example.com...

...

Post by Keith Thompson
I presume you mean n1256.pdf. (Note that n1570.pdf, available in the
same location, is a draft of the current standard.)

OK so would 1570.pdf be better to have? Is a post 2000 standard. I am
comforable with C99.

Bill

[F. Russell]

Post by Bill Cunningham
Are
there situations where it wouldn't be 1? If so when?

Certainly.

If one is reading binary floating point data into an
array of same then it would be preferable to use:

fread(array, sizeof(double), numb, stream);

The same for reading back the contents of a struct
or an array of struct that have been stored as binary.

Storing binary floating point values is more efficient
than storing the string representation of the value,
and it may avoid other problems as well.

[Keith Thompson]

Post by F. Russell

Post by Bill Cunningham
Are
there situations where it wouldn't be 1? If so when?

Certainly.
If one is reading binary floating point data into an
fread(array, sizeof(double), numb, stream);
The same for reading back the contents of a struct
or an array of struct that have been stored as binary.

The question (which I don't think you've answered) is why you'd write:
fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);
or
fread(array, 1, sizeof(double), stream);

The second argument is the size of each element; the third is the
number of elements. The distinction matters only if you care about
partial reads. fread() returns the number of elements that it
successfully read. If a partial read is no better than a complete
failure, then it doesn't matter which call you use.

Post by F. Russell
Storing binary floating point values is more efficient
than storing the string representation of the value,
and it may avoid other problems as well.

It can also cause problems if you try to write data on a system with one
floating-point represenation and read it on a system with a different
representation.

[Bill Cunningham]

Post by F. Russell

Post by F. Russell

Post by Bill Cunningham
Are
there situations where it wouldn't be 1? If so when?

Certainly.
If one is reading binary floating point data into an
fread(array, sizeof(double), numb, stream);
The same for reading back the contents of a struct
or an array of struct that have been stored as binary.

fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);
or
fread(array, 1, sizeof(double), stream);
The second argument is the size of each element; the third is the
number of elements. The distinction matters only if you care about
partial reads. fread() returns the number of elements that it
successfully read. If a partial read is no better than a complete
failure, then it doesn't matter which call you use.

Post by F. Russell
Storing binary floating point values is more efficient
than storing the string representation of the value,
and it may avoid other problems as well.

It can also cause problems if you try to write data on a system with one
floating-point represenation and read it on a system with a different
representation.

I think I can see what you mean Keith. Simple numb * sizeof(double)
could backfire.

Bill

[f***@gmail.com]

Post by F. Russell
fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);

The OP asked for a situation where the second param could
be other than 1 and I gave him a couple of examples.

I didn't expect some nitpicker to come along and tear it apart.

Post by F. Russell
It can also cause problems if you try to write data on a system with one
floating-point represenation and read it on a system with a different
representation.

The floating point formats have been standardized since IEE1985.

Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

[Kenny McCormack]

Post by f***@gmail.com

Post by F. Russell
fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);

The OP asked for a situation where the second param could
be other than 1 and I gave him a couple of examples.
I didn't expect some nitpicker to come along and tear it apart.

You must be new around here.

Post by f***@gmail.com

Post by F. Russell
It can also cause problems if you try to write data on a system with one
floating-point represenation and read it on a system with a different
representation.

The floating point formats have been standardized since IEE1985.
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

Leader Kiki is not going to like this. Expect to be banned from the group
any day now. Leader Kiki has that power.

[Keith Thompson]

Post by f***@gmail.com

Post by F. Russell
fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);

The OP asked for a situation where the second param could
be other than 1 and I gave him a couple of examples.
I didn't expect some nitpicker to come along and tear it apart.

You didn't expect someone to expand on what you wrote and provide more
information. You probably should have.

Post by f***@gmail.com

Post by F. Russell
It can also cause problems if you try to write data on a system with one
floating-point represenation and read it on a system with a different
representation.

The floating point formats have been standardized since IEE1985.
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

(It's IEEE 754-1985, updated as IEEE 754-2008. The equivalent
international standard is ISO/IEC/IEEE 60559:2011.)

Even if all systems use IEEE floating-point, they don't all use
the same byte order. I just tried an experiment, writing a file
on a system with one byte order and reading on another system with
a different byte order, and got garbage (as I expected).

I'm not saying that writing binary floating-point values to a file is
always unacceptable. I'm merely pointing out some of the tradeoffs.

[Gordon Burditt]

Post by f***@gmail.com
The floating point formats have been standardized since IEE1985.

Not sufficiently for how you want to use them.

Post by f***@gmail.com
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

Endianness is still an issue for floating-point binary representations,
even if both machines conform to IEEE 754-1985.

"long double" has much less standardization than "float" and "double"
(and yes, it's a floating point format also, although you probably
don't want to use it as a transfer format between machines, as
there are many more problems than with "float" and "double").

IEEE 754-1985 does not specify what format a C compiler must use
for "long double". "long double" may be bit-for-bit identical to
"double" (e.g. on Windows Visual C++), so sizeof(long double) = 8.

Linux, the BSDs and OS X use the x86 80-bit extended format for
"long double". This takes up 10 bytes, however, sizeof(long double)
may be either 12 or 16, depending on alignment constraints. It's
conceivable that sizeof(long double) could be 10 on an 8086 for
16-bit alignment. The same bit patterns are used (modulo endianness)
but the different size of the padding will cause trouble.

IEEE 754-2008 defines some formats longer than 80 bits (128 and 256
bits) which could be used for long double.

The GNU C compiler uses a non-standard format for "long double" on
PowerPC and SPARC.

[James R. Kuyper]

On 07/31/2017 12:38 PM, ***@gmail.com wrote:
...

Post by f***@gmail.com
The floating point formats have been standardized since IEE1985.

That's funny. I'm still responsible for programs that parse data coming
down from satellites that provide some of their data in 48-bit
MIL-STD-1750A format <http://en.wikipedia.org/wiki/MIL-STD-1750A>. The
designs for those satellites were finalized in the mid-1990s, long after
you claim "floating point formats [had] been standardized". Possibly,
not everyone got the memo?

Post by f***@gmail.com
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

Well, it was a bit of a pain, decoding those formats on a system that
had neither hardware support nor software emulation for such types, but
I was in no position to punish anybody for making that choice.

[j***@gmail.com]

Post by James R. Kuyper
...

Post by f***@gmail.com
The floating point formats have been standardized since IEE1985.

That's funny. I'm still responsible for programs that parse data coming
down from satellites that provide some of their data in 48-bit
MIL-STD-1750A format <http://en.wikipedia.org/wiki/MIL-STD-1750A>. The
designs for those satellites were finalized in the mid-1990s, long after
you claim "floating point formats [had] been standardized". Possibly,
not everyone got the memo?

Post by f***@gmail.com
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

Well, it was a bit of a pain, decoding those formats on a system that
had neither hardware support nor software emulation for such types, but
I was in no position to punish anybody for making that choice.

I've seen MIL-STD-1750A floating points, but only encoded in the I/O of a
device like an EGI on the MIL-STD-1553 bus. Those floating point types
though are pretty few and far between, but not inexistant.

The DoD has a penchant for choosing to start development with standards that
are considered stable (~10+ years old), so by the time you get to begin the
implementation after the requirements and design phases, you're already at
obsolescence.

Best regards,
John D.

[s***@casperkitty.com]

Post by f***@gmail.com
Any system that does not adhere to IEEE1985 is inviting serious
repercussions and deserves no mercy.

The IEEE-754 formats have advantages on hardware that supports them, but
systems which lack floating-point hardware (common in the embedded world)
would often be better off using something else. For example, a type which
uses a 32-bit significand with explicit leading "1" could in many cases
on non-FPU systems than an IEEE single despite offering better precision.
Further, while IEEE-754 had anticipated that systems would computations by
converting operands to an extended-precision type (**which must be made
available to the programmer**), performing a sequence of operations, and
then converting back to a "packed" type, that style of computation has been
replaced by the approach of using one type constantly throughout
computations, which ends up being less precise for many purposes, and can
also hurt efficiency by discouraging the development of instructions to e.g.
multiply two float values yielding a double result, and then add a double to
the product.

[Keith Thompson]

Keith Thompson <kst-***@mib.org> writes:
[...]

Post by F. Russell
fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);
or
fread(array, 1, sizeof(double), stream);

Sorry, copy-and-paste error. I meant:

fread(array, sizeof(double), numb, stream);
rather than
fread(array, numb * sizeof(double), 1, stream);
or
fread(array, 1, numb * sizeof(double), stream);

(I omitted the "numb *" in the third call.)

[Steve Carroll]

So, yeah, I buy into my own fancy, fully knowing it would never be discovered by others, because it makes me reconsider my script, improving it.

All joking aside, those of you who troll are not able to check KDE any more. Not only did jacobnavia's request not refer to the "KDE", it has nada to do with UNIX. Marek should learn to read ;)

It was Marek who stated that he and his work friends used to troll grade school kids all the time and it was arousing, not even a slight concern. You refuse to take responsibility for your own words. Actions that are easily found in a search. You're like a fool wearing a gorilla outfit at the prom. We all see you hiding there and wonder how you can be so stupid. And you're so ignorant you keep failing to see it.

[Steven Petruzzellis]

You can say I am President Trump for all I care. Robert Wessel shreds bartc in every way possible.

bartc doesn't have any clue what he is blubbering about. Why do you keep quoting yourself? It is obvious at least some of the posts are hand generated because some of them are keyed in to posts that occur in very specific ways that underscore they are a response, so not from a computer auto-generator. Which can only be bartc.

Why the need to open a ticket via usenet in a super computer system? Of course, he didn't list this as part of his, what would undoubtedly be, continually changing 'requirements'. Almost all regulars in this forum do customizations either as a hobby or as a career, so I am skeptical anyone here considers writing macros to be "black magic".


Puppy Videos!
http://www.5z8.info/nic_cage_naked_y8b5qk_torrentEverything
http://www.5z8.info/add-worm_z4r9qk_fakelogin
Jonas Eklundh Communication AB

[Jonas Eklundh]

What did God have to say about this miraculous, years long string of oddities? Most of the time he would try to push others to trust they're students of his who just happened to have an extremely bizarre entrance into usenet. All makes total sense, NOT! That's what God does when he gets mad. He always creates a nym, starts a thread so he can claim here made a mistake. Don't blame me it was my left hand... and then he talks to it with his right hand. Sandman trolls God. Here is a list of names Jonas Eklundh has admitted he attributes to God "Cactus Pete", "Donald", "Donald Miller", "Horace McSwain", "Hymen", "meat","Mike Weaver", "Modena IV Drid", "Omar Murad Asfour", "Rhino Plastee", "Soapy", "SopwithCamel", "Sunny Day", "Takuya Saitoh", "The Letter Q", "tmelmosfire", "zevon". And the herd is stupid enough to believe him. I am working on a system which will be more than anything God can do!

How is existing brain matter tied to a broken AI in any way going to lead to enlightened group discussion?

Your system will crawl while downloading the mass of flood posts. And it takes a long time. The guy is as well liked as a tax collector -- and with good reason.