bytes calculation

[seema]

Hi all,

How to calculate upper 4 bytes and lower 4 bytes of a value? Can
somebody please explain??
say for example,
unsigned int scnlen_lo;
int scnlen_hi;
unsigned long long scnlen;

scnlen=888888;
scnlen_hi= ??//how to calculate upper 4 bytes of scnlen?
scnlen_lo =?? //how to calculate lower 4 bytes of scnlen??

Thanks in advance,
Seema Rao

[Richard Heathfield]

jacob navia said:

Spoon wrote:

>Pietro Cerutti wrote:

>>Assuming that sizeof(unsigned long long) == 64 and sizeof(int) == 32

I think you meant "Assuming CHAR_BIT == 8, sizeof(int) == 4, and
sizeof(unsigne d long long) == 8".

Please, are you a lawyer?

Can you tell me of a machine where char_bit != 8 ?

Assuming you mean CHAR_BIT, the use of 16- and even 32-bit bytes is
commonplace in modern digital signal processors. SHARC DSPs are an
obvious example.

And please, a machine in use 2007 ok?

It is not unlikely that you use several such processors yourself,
whether you realise it or not. DSPs are in common use in mobile phones,
for example.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Pietro Cerutti]

Mark Bluemel wrote:

Pietro Cerutti wrote:

>jacob navia wrote:

>>Pietro Cerutti wrote:

Richard Heathfield wrote:

... your
code invokes undefined behaviour.

Can you explain me this point, please?
At least, is it so under C99?

...

>>>
Please do not believe everything heathfield says...

He is a language lawyer, and those people do not live by the
same rules as the rest of us

...

>I can't get the point.
Does my code invokes undefined behavior or not?

My guess is that if Richard H says it invokes undefined behaviour, it
does. I'm a little disappointed that he has not felt fit to explain why
and give chapter and verse, but that's his perogative.

I agree on both your first and second sentence.

>
However, the undefined behaviour on the implementations you happen to
use (or indeed most or even all implementations ) may be for the code to
do what you expect.

Yes, I'm not assuming that my code is correct only because it gives the
result I was expecting..
--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[jacob navia]

Mark Bluemel wrote:

Pietro Cerutti wrote:

>jacob navia wrote:

>>Pietro Cerutti wrote:

Richard Heathfield wrote:

... your
code invokes undefined behaviour.

Can you explain me this point, please?
At least, is it so under C99?

...

>>>
Please do not believe everything heathfield says...

He is a language lawyer, and those people do not live by the
same rules as the rest of us

...

>I can't get the point.
Does my code invokes undefined behavior or not?

My guess is that if Richard H says it invokes undefined behaviour, it
does. I'm a little disappointed that he has not felt fit to explain why
and give chapter and verse, but that's his perogative.

However, the undefined behaviour on the implementations you happen to
use (or indeed most or even all implementations ) may be for the code to
do what you expect.

You agree with me then, that a shift right of 32 bits should give
you the upper 4 bytes ok?

I am getting nuts with all the language lawyers around.

Here we enter into the realms of philosophy and personal taste - Mr
Heathfield wishes for all C code to be provably correct (loosely
speaking) for a general abstract C implementation which sticks to the
letter of the language specification,

Typical legalese of lawyers's taste.

while Mr Navia will accept C code

working on the sample of machines he happens to work with.

What?

If sizeof(unsigned long long) is 8 and sizeof(int) is 4,
(and CHAR_BIT is 8)

unsigned long long >32 gives the upper 32 bits,
that can be safely stored into a 32 bit integer!

This in all machines as far as I can see.

By the way, I am using this code in
PowerPC (64 bits)
Solaris (Sparc)
64 bit windows
64 bit linux
32 bit windows
32 bit linux

[Disclaimer - I do not speak for either party here, and my comments
above are my interpreations of their positions]

OK, but I tell you: my position is that a right shift should do
it in ANY machine. You disagree with that???

You yourself you are unable to say why it should NOT work.
You have used (surely) this code.

Incredible, how lawyers scare people with legalese!

[Spoon]

Jacob Navia wrote:

Spoon wrote:

>Pietro Cerutti wrote:

>>Assuming that sizeof(unsigned long long) == 64 and sizeof(int) == 32

I think you meant "Assuming CHAR_BIT == 8, sizeof(int) == 4, and
sizeof(unsigne d long long) == 8".

Please, are you a lawyer?
Can you tell me of a machine where char_bit != 8 ?
And please, a machine in use 2007 ok?

cf. comp.arch.embed ded

[Mark Bluemel]

Richard Heathfield wrote:
....

Here's a solution that I believe to be correct - I don't have a C99
compiler, so I can't check it (because of the unsigned long long) - but
corrections are most welcome:

Good job too.

[snip]

/* first ensure that a result is possible */
if(sizeof scnlen_lo < 4 || scnlen_hi < 4)

This should surely be:-

if(sizeof scnlen_lo < 4 ||sizeof scnlen_hi < 4)

And given the issues we meet later, I'd be inclined to add parentheses
(but then I'm often inclined to add parentheses):-

if((sizeof scnlen_lo < 4) ||(sizeof scnlen_hi < 4))

....

if(scnlen & mask <= UINT_MAX)

if((scnlen & mask) <= UINT_MAX)

....

if(scnlen & mask <= INT_MAX)

if((scnlen & mask) <= INT_MAX)

....

[Pietro Cerutti]

Richard Heathfield wrote:

Pietro Cerutti said:

>seema wrote:

>>Hi all,

How to calculate upper 4 bytes and lower 4 bytes of a value? Can
somebody please explain??
say for example,
unsigned int scnlen_lo;
int scnlen_hi;
unsigned long long scnlen;

scnlen=888888;
scnlen_hi= ??//how to calculate upper 4 bytes of scnlen?
scnlen_lo =?? //how to calculate lower 4 bytes of scnlen??

sclen_hi = scnlen >32;
sclen_lo = scnlen & 0xFFFFFFFF;

Assuming that sizeof(unsigned long long) == 64 and sizeof(int) == 32

Under those assumptions and assuming CHAR_BIT is 8, sclen_hi now
actually contains the top 28 bytes of scnlen, which isn't what was
asked.

If you meant those to be bit counts rather than byte counts, your code
invokes undefined behaviour.

You seem not to be willing to help me understanding why my code invokes
undefined behavior.
Maybe you're expecting some more work on my side, which I've done:
My source is n1124.

As of "6.5.7", shift operators invoke undefined only if the right
operand is negative (not the case in my code) or greater than the width
of the left operand (not the case in my code).
Moreover, the left shift operator (which I do not use) invokes undefined
behavior if the result is not representable in the result type.

As of "6.5.10", the bitwise AND operator never causes undefined behavior.

So, please, could you point me to where the problem is?
Thank you in advance.

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Richard Heathfield]

Mark Bluemel said:

<snip>

My guess is that if Richard H says it invokes undefined behaviour, it
does.

That's a good guess, but on this occasion you're mistaken. The code does
not in fact invoke undefined behaviour, and I was mistaken to claim
otherwise. I therefore owe apologies to Mr Cerutti and Mr Navia.

I'm a little disappointed that he has not felt fit to explain
why and give chapter and verse, but that's his perogative.

My reasoning (which would have worked just fine if I'd been right about
the UB) was that Mr Navia should have been perfectly capable of working
out the answer for himself and announcing it by himself. This turns out
to be impossible, of course, because I was mistaken in my claim, and
therefore incorrectly "corrected" a more or less correct post, in which
there was no UB to spot.

Now that I've taken my lumps, I'll explain what I thought was wrong. It
was the right shift by 32 bits. This is *not* undefined behaviour
because it is performed on an integer that is guaranteed to occupy more
than 32 bits (at least 64, in fact).

To make matters worse, I checked the code *twice* after spotting the
"bug" (as I thought it was), before posting my "correction ".

The assumptions by both Mr Navia and Mr Cerutti that bytes are always 8
bits wide, whilst incorrect, pale in comparison with my own blunder.

<snip>

And now I suppose it's time for the clowns to have their field day. Pace
regs - I shall not be reading their responses.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Mark Bluemel said:

Richard Heathfield wrote:
...

>Here's a solution that I believe to be correct - I don't have a C99
compiler, so I can't check it (because of the unsigned long long) -
but corrections are most welcome:

Good job too.

<Three corrections snipped>

Today is not being a good day, is it?

Thank you for the corrections.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Pfaff]

Richard Heathfield <rj*@see.sig.in validwrites:

Pietro Cerutti said:

>seema wrote:

>>Hi all,

How to calculate upper 4 bytes and lower 4 bytes of a value? Can
somebody please explain??
say for example,
unsigned int scnlen_lo;
int scnlen_hi;
unsigned long long scnlen;

scnlen=888888;
scnlen_hi= ??//how to calculate upper 4 bytes of scnlen?
scnlen_lo =?? //how to calculate lower 4 bytes of scnlen??

sclen_hi = scnlen >32;
sclen_lo = scnlen & 0xFFFFFFFF;

Assuming that sizeof(unsigned long long) == 64 and sizeof(int) == 32

If you meant those to be bit counts rather than byte counts, your code
invokes undefined behaviour.

Let me expand on this. Consider the first assignment:
sclen_hi = scnlen >32;
scnlen has type "unsigned long long", which is at least 64 bits
wide. Thus, shifting it right by a mere 32 bits is
well-defined. The result is then assigned to sclen_hi, which has
type "unsigned int". Regardless of whether "unsigned int" is
large enough to hold 32 bits, the assignment is acceptable: any
high bits will simply be trimmed off.

Consider the second assignment:
sclen_lo = scnlen & 0xFFFFFFFF;
I believe that 0xFFFFFFFF has type "int", "unsigned int",
"unsigned long int", or "unsigned long long int", depending.
Regardless of its type, the "&" operation against scnlen will
cause it to be promoted to "unsigned long long int". The result
is assigned to sclen_lo.

The possibility for undefined behavior seems to be in the range
of "int", which is the type of sclen_lo. If "int" is 32 bits,
then converting a large 32-bit unsigned integer to "int" invokes
undefined behavior, because it is outside the range of "int". I
imagine that this is what Richard is talking about.

Another possibility is that Richard is concerned about the
possibility of padding bits in various types. Padding bits are
interesting theoretically but rarely come up in real life, so I'm
not going to go any further in this direction.

The example number of 888888 would not yield undefined behavior,
as far as I can see. I don't think that's the issue at hand.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

[Mark Bluemel]

jacob navia wrote:

Mark Bluemel wrote:

>>
My guess is that if Richard H says it invokes undefined behaviour, it
does. I'm a little disappointed that he has not felt fit to explain
why and give chapter and verse, but that's his perogative.

However, the undefined behaviour on the implementations you happen to
use (or indeed most or even all implementations ) may be for the code
to do what you expect.

You agree with me then, that a shift right of 32 bits should give
you the upper 4 bytes ok?

Given the full set of constraints - 8-bit bytes, 64-bit unsigned long
longs, 32-bit signed and unsigned ints - yes, I agree it should work.
However, I admit that my understanding is not complete, especially when
we look at the fine detail of the language specification.

As I said above, if Richard H says that this invokes undefined
behaviour, based on my experiences of his postings I'm inclined to
believe him, though I'd rather like to see chapter and verse.

>
I am getting nuts with all the language lawyers around.

>Here we enter into the realms of philosophy and personal taste - Mr
Heathfield wishes for all C code to be provably correct (loosely
speaking) for a general abstract C implementation which sticks to the
letter of the language specification,

Typical legalese of lawyers's taste.

This is not legalese - or at least I did not intend it to be so. I was
trying to accurately characterise Richard H's position, which is a
purist position relying only on what the language specification asserts.

>while Mr Navia will accept C code
working on the sample of machines he happens to work with.

What?

If sizeof(unsigned long long) is 8 and sizeof(int) is 4,
(and CHAR_BIT is 8)

unsigned long long >32 gives the upper 32 bits,
that can be safely stored into a 32 bit integer!

This in all machines as far as I can see.

By the way, I am using this code in
PowerPC (64 bits)
Solaris (Sparc)
64 bit windows
64 bit linux
32 bit windows
32 bit linux

This is the point where we need to wheel out the DS9K I suspect.

Other posters have already pointed out platforms where some of the
initial constraints are broken.

>

>[Disclaimer - I do not speak for either party here, and my comments
above are my interpreations of their positions]

OK, but I tell you: my position is that a right shift should do
it in ANY machine. You disagree with that???

You yourself you are unable to say why it should NOT work.

I have stated above that I recognise that my knowledge is limited, and
I'm more inclined to trust Richard's informed judgement than mine on
this point.

You have used (surely) this code.

Code I work with uses such constructions, but it is code which is
regarded as platform-specific, not as totally portable.