Write int as a 4 byte big-endian to file.

[Morris Keesan]

s/3/4/ (assuming you want to output four bytes)


s/intvalue/ltemp/

Oops. Correct on both counts. That's what I get for hitting "send"
without proofreading.

 

[Morris Keesan]

/*
write a 32 bit big endian integer to file
Params: x - the integer
fp - the open file
Returns: 0 on success, error code on fail
*/
int fput32bigendian(long x, FILE *fp)
{

Not quite. x should be unsigned long. If x is negative, then
the results of the right shifts are implementation-defined, and
(perhaps surprisingly) there are no constraints on what the implementation
may define as the result.

 

[Ike Naar]

for( i = 3; i >= 0; i-- ) bytes = what % 256, what /= 256;

What ??? Did you do this with a comma operator just to make it hard
to read? If so, it worked. I started to post this as a correction,
before I did a double-take and realized that the assignment has
higher priority than the comma.

Is it really hard to read, or do you just dislike the comma operator?

 

[Malcolm McLean]

Not quite.  x should be unsigned long.  If x is negative, then
the results of the right shifts are implementation-defined, and
(perhaps surprisingly) there are no constraints on what the implementation
may define as the result.

It might zero-pad or sign extend the long, but that's OK because we
ignore those bits. It wil break if it defines a right shift of a
negative number as some sort of runtime error, but it will also fail
on one's complement systems, or where the filing system uses 16-bit
binary bytes.

 

[Joe Pfeiffer]

Hi, I'm not a C expert, but the following worked for me on a
low-endian 32-bit machine, a low-endian 64-bit machine, and a
big-endian 32-bit machine:

int i = 12345678;
printf("%d\n", (i & 0xFF000000) >> 32);
printf("%d\n", (i & 0x00FF0000) >> 16);
printf("%d\n", (i & 0x0000FF00) >> 8);
printf("%d\n", i & 0x000000FF);

output (identical on all three machines):

0
188
97
78

Except that he wants to write four bytes, not four strings.

 

[Bl0ckeduser]

Except that he wants to write four bytes, not four strings.

In my test program, I was using printf() to check the right numbers were
being put in the bytes, and I posted this as-is.

I guess I'll be more careful next time, thanks for the tip.

 

[Stephen Sprunk]

MAX_INT is only guaranteed to be 32767;

[...]

and is spelled INT_MAX.

Argh! Well, at least I only messed up the commentary, not the code.

S

 

[Stephen Sprunk]

What's wrong with using htonl()? Let your implementation worry about
the endianness of your platform. Use ntohl() to convert it when
reading the data back from the file.

htonl() et al are not part of Standard C; they usually come with a BSD
sockets library, which the OP may or may not have.

In any event, just giving him such functions would mean he misses out on
the opportunity to learn something very important, which he will likely
need to know when he later runs into file formats or network protocols
that, for historical reasons, require numbers to be in little-endian
order rather than the standard order.

S

 

[Malcolm McLean]

In any event, just giving him such functions would mean he misses out on
the opportunity to learn something very important, which he will likely
need to know when he later runs into file formats or network protocols
that, for historical reasons, require numbers to be in little-endian
order rather than the standard order.

Yes, those little endians tried to take over the world, but they've
now been beaten back, and we can all open our integers at the big end
again.

 

[Tim Rentsch]

for( i = 3; i >= 0; i-- ) bytes = what % 256, what /= 256;

What ??? Did you do this with a comma operator just to make it hard
to read?

No, I used a comma operator because I think of the two assignments
as a single conceptual unit (extract the low order bits and shift
those bits out of the word being worked on), so it seems natural
to express that conceptual unit as a single statement.

If so, it worked. I started to post this as a correction,
before I did a double-take and realized that the assignment has
higher priority than the comma.

The whole point of the comma operator is to allow multiple
side-effecting operations in a single expression, so it
makes sense that it would have lower precedence than assignment.

 

[Joe keane]

'fread' reads an array of bytes ['char *']

'fwrite' writes an array of bytes ['char *']

passing an 'int *' or 'struct foo *' [with a cast to defeat the type
system] is at best unportable and at worst really broken

 

[Ian Collins]

'fread' reads an array of bytes ['char *']

'fwrite' writes an array of bytes ['char *']

passing an 'int *' or 'struct foo *' [with a cast to defeat the type
system] is at best unportable and at worst really broken

Are you replying to something?

 

[Ben Bacarisse]

'fread' reads an array of bytes ['char *']

'fwrite' writes an array of bytes ['char *']

Did you have a nightmare where you woke up in 1979? It's been a while
since fread and fwrite had char * parameters.

passing an 'int *' or 'struct foo *' [with a cast to defeat the type
system] is at best unportable and at worst really broken

It's perfectly well-defined, needs no cast, and is a common idiom.

 

[Morris Keesan]

It might zero-pad or sign extend the long, but that's OK because we
ignore those bits. It wil break if it defines a right shift of a
negative number as some sort of runtime error, but it will also fail
on one's complement systems, or where the filing system uses 16-bit
binary bytes.

If zero-fill or sign-fill were the only allowed implementation-defined
results of right-shifting a negative quantity, that would be okay.
But there are no constraints on the values of any of the bits, even the
the bits that you might expect to be shifted. The result of right-shifting
a negative number could be alternating 1 and 0 bits. By declaring the
variable as unsigned, you avoid that uncertainty.

 

[tom st denis]

On Sat, 10 Mar 2012 14:44:13 -0500, Tim Rentsch

    for(  i = 3;  i >= 0;  i--  )  bytes = what% 256,  what /= 256;

What ???  Did you do this with a comma operator just to make it hard
to read?

No, I used a comma operator because I think of the two assignments
as a single conceptual unit (extract the low order bits and shift
those bits out of the word being worked on), so it seems natural
to express that conceptual unit as a single statement.

If you worked under me I'd make you re-write that code properly.
"Clever" people tend to write code that holds up less under the test
of time.

Tom

 

[Joe keane]

Are you replying to something?

The subject line starts with "Re: ".

On my machine, you press left-arrow key.

In this here case, the subject line is fine, and the text is just a
recapitulation, explaining that he can't solve the problem [which is
implied, otherwise why the article?].

 

[jacob navia]

Le 12/03/12 13:56, tom st denis a écrit :

@alumni.caltech.edu> wrote:

for( i = 3; i>= 0; i-- ) bytes = what % 256, what /= 256;

What ??? Did you do this with a comma operator just to make it hard
to read?

No, I used a comma operator because I think of the two assignments
as a single conceptual unit (extract the low order bits and shift
those bits out of the word being worked on), so it seems natural
to express that conceptual unit as a single statement.

If you worked under me I'd make you re-write that code properly.
"Clever" people tend to write code that holds up less under the test
of time.

Tom

I can fully understand why you do not like clever people.

Happily, he is not working for you so he can be clever instead of being
forced to being dumb.

You didn't even try to understand what he is saying:

 

[Keith Thompson]

Are you replying to something?

The subject line starts with "Re: ".

On my machine, you press left-arrow key.

In this here case, the subject line is fine, and the text is just a
recapitulation, explaining that he can't solve the problem [which is
implied, otherwise why the article?].

Not all Usenet clients make it easy to see the parent article.
Mine does, but then it's not necessarily trivial to get back to the
article I was reading (multiple articles can have the same parent).
That's why most of us, out of consideration for our readers, quote
enough context for each followup to make sense when read on its own.

 

[Kaz Kylheku]

Not all Usenet clients make it easy to see the parent article.

Not all homes have running water. So what?

 

[gwowen]

I can fully understand why you do not like clever people.

Clever people do not write code like that. Clever people *can* write
code like that, but are clever enough not to, because they understand
maintainance burdens, and why code clarity beats code cleverness in
99.9999% of cases.