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

On 03/12/12 10:29 AM, Joe keane wrote:
> '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?

--
Ian Collins

jgk@panix.com (Joe keane) writes:

> '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.

--
Ben.

On Sat, 10 Mar 2012 18:02:07 -0500, Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

> On Mar 10, 10:29Â*pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>> On Sat, 10 Mar 2012 15:39:41 -0500, Malcolm McLean
>>
>> <malcolm.mcle...@btinternet.com> wrote:
>> > /*
>> > Â* 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.
>>
> 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.
--
Morris Keesan -- mkeesan@post.harvard.edu

On Mar 11, 4:08*pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> "Morris Keesan" <mkee...@post.harvard.edu> writes:
> > On Sat, 10 Mar 2012 14:44:13 -0500, Tim Rentsch
> > <t...@alumni.caltech.edu> *wrote:
>
> >> * * for( *i = 3; *i >= 0; *i-- *) *bytes[i] = 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

In article <9s4k3mFa8vU4@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:
>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?].

Le 12/03/12 13:56, tom st denis a écrit :
> On Mar 11, 4:08 pm, Tim Rentsch<t...@alumni.caltech.edu> wrote:
>> "Morris Keesan"<mkee...@post.harvard.edu> writes:
>>> On Sat, 10 Mar 2012 14:44:13 -0500, Tim Rentsch
>>> <t...@alumni.caltech.edu> wrote:
>>
>>>> for( i = 3; i>= 0; i-- ) bytes[i] = 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:

>> 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.

jgk@panix.com (Joe keane) writes:
> In article <9s4k3mFa8vU4@mid.individual.net>,
> Ian Collins <ian-news@hotmail.com> wrote:
>>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.


--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-03-13, Keith Thompson <kst-u@mib.org> wrote:
> Not all Usenet clients make it easy to see the parent article.

Not all homes have running water. So what?

On Mar 12, 11:01*pm, jacob navia <ja...@spamsink.net> wrote:

> 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.

On 2012-03-13, gwowen <gwowen@gmail.com> wrote:
[about

bytes[i] = what % 256, what /= 256;

]

> 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.

There can be a good reason to write code like that.
Suppose we have variables x and y that represent the position
of a bishop on a chess board. The piece is currently on
a black square, and this is an invariant according to the rules
of the game. No legal move can put it on a white square.
Now we move it from (x, y) (black square) to (x+3, y-3) (black square).

It could be written like this:

/* initial: black square */
x = x+3;
/* intermediate: white square */
y = y-3;
/* final: black square */

but the intermediate state violates the invariant and that's ugly.
It would be cleaner to write it like this (using Python-like multiple
assignment):

/* initial: black square */
x, y = x+3, y-3;
/* final: black square */

and avoid the invalid intermediate state.
Of course C does not have multiple assignment, but this comes close:

/* initial: black square */
x = x+3, y = y-3;
/* final: black square */

I think here the use of a comma expression leads to somewhat cleaner
code: the fact that it's a single statement shows the intention
to make one legal move, instead of two illegal moves that combine
into a legal move.

"Geoff" <geoff@invalid.invalid> ha scritto nel messaggio
news:g6gnl7d6uha7f01dmomc14k4i4smmleqrf@4ax.com...
> On Sat, 10 Mar 2012 18:00:50 +0000, MS <ms@no_spam_thanks.com> wrote:
>
>>Hi,
>>
>>I need some help with something which is a little over my pay grade.
>>
>>The file which I must write has a header followed by a sequence of ints
>>each of which must be written as a 4 byte big-endian.
>>
>>The comp.lang.c has advice on finding out whether your machine is
>>little-endian or big-endian (little-endian in my case) but not on how to
>>do the kind of operation I need to do.
>>
>>I am sorry to say that I simply have no idea whatsoever how to write an
>>int to a file as a 4 byte big-endian. Can someone show me how please?

what about, where u32 is unsigned 32 bit and u8 is unsigned 8 bit
u32 ValueToTraslateBytes=J;
u8 v[4];

u[0]= (ValueToTraslateBytes>>24) &0xFF;
u[1]= (ValueToTraslateBytes>>16) &0xFF;
u[2]= (ValueToTraslateBytes>> 8) &0xFF;
u[3]= ValueToTraslateBytes &0xFF;

i don't remember if above is little of big endian... it is the way here
number are written in memory.. u32 7 is in hex bites are 0x07 0x00 0x00 0x00
or 07 00 00 00

>>Many thanks.
>
> 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.

i agree

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4f5f2e83$0$1383$4fafbaef@reader1.news.tin.it. ..
>
> "Geoff" <geoff@invalid.invalid> ha scritto nel messaggio
> news:g6gnl7d6uha7f01dmomc14k4i4smmleqrf@4ax.com...
>> On Sat, 10 Mar 2012 18:00:50 +0000, MS <ms@no_spam_thanks.com> wrote:
>>
>>>Hi,
>>>
>>>I need some help with something which is a little over my pay grade.
>>>
>>>The file which I must write has a header followed by a sequence of ints
>>>each of which must be written as a 4 byte big-endian.
>>>
>>>The comp.lang.c has advice on finding out whether your machine is
>>>little-endian or big-endian (little-endian in my case) but not on how to
>>>do the kind of operation I need to do.
>>>
>>>I am sorry to say that I simply have no idea whatsoever how to write an
>>>int to a file as a 4 byte big-endian. Can someone show me how please?
>
> what about, where u32 is unsigned 32 bit and u8 is unsigned 8 bit
> u32 ValueToTraslateBytes=J;
> u8 v[4];
>
> u[0]= (ValueToTraslateBytes>>24) &0xFF;
> u[1]= (ValueToTraslateBytes>>16) &0xFF;
> u[2]= (ValueToTraslateBytes>> 8) &0xFF;
> u[3]= ValueToTraslateBytes &0xFF;

i realize here the correct way number appear here in memory should be:

u[0]= ValueToTraslateBytes &0xFF; // 7
u[1]= (ValueToTraslateBytes>> 8) &0xFF;
u[2]= (ValueToTraslateBytes>>16) &0xFF;
u[3]= (ValueToTraslateBytes>>24) &0xFF;

> i don't remember if above is little of big endian... it is the way here
> number are written in memory.. u32 7 is in hex bites are 0x07 0x00 0x00 0x00
> or 07 00 00 00
>
>>>Many thanks.
>>
>> 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.
>
> i agree
>
>
>
>
>

gwowen <gwowen@gmail.com> writes:

> On Mar 12, 11:01Â*pm, jacob navia <ja...@spamsink.net> wrote:
>
>> 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.

I fully agree about clarity, but how unclear was the code and in what
way? I don't like the idea of avoiding parts of the language because
some future reader might not might not know it. For one thing, where do
you draw the line? Who decides what's generally well understood? But
my real objection is that the lack of clarity is superficial -- a quick
look on the web, or a check in a book and everything becomes clear again.

When I was, however briefly, doing this sort of maintenance, I never
minded that sort of "clever" code. Seeing a neat way to write something
made a dull job a little more interesting. I really don't ever recall
making a mistake because of a syntactic misunderstanding, nor do recall
being significantly impeded by such a thing.

All of the hard maintenance problems I recall came from trying to
understand the dynamic behaviour of a program. The most obvious example
in C is whether allocated memory is used after it's lifetime has ended,
but there are lots of other. The worst I ever saw was an old Unix sort
utility which passed pointers around without the proper conversions. It
was almost impossible to tell if the pointer you had at some point was
really a char pointer or a struct pointer and, because this was a
word-addressed machine, that mattered. It took weeks to get it running
and I very much doubt I got all the bugs out even then. I would have
happily traded a thousand uses of the most obscure C syntax for a
clearer and better organised program.

On the use of the comma operator, I agree with Tim that it's useful when
the purpose of the expressions are closely related. I use it,
for example, when a function "returns" more than one thing:

return *reason = ZERO_DIVIDE, FAIL;

--
Ben.

tom st denis <tom@iahu.ca> writes:

> On Mar 11, 4:08 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> "Morris Keesan" <mkee...@post.harvard.edu> writes:
>> > On Sat, 10 Mar 2012 14:44:13 -0500, Tim Rentsch
>> > <t...@alumni.caltech.edu> wrote:
>>
>> >> for( i = 3; i >= 0; i-- ) bytes[i] = 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.

If you worked under me you would learn that different
groups have rather different ideas about what constitutes
good or readable coding style, and it's better not to
be so dogmatic about it. But then neither one of those
hypotheticals holds, does it?

gwowen <gwowen@gmail.com> writes:

> On Mar 12, 11:01 pm, jacob navia <ja...@spamsink.net> wrote:
>
>> 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.

The case in question was purely an issue of coding style. Some
people (I happen to be one of them) think the particular style
used improves clarity, not reduces it. If someone prefers a
different style, I'm okay with that. But I wouldn't call it
"clever" or "not clever", just a different style.