bytes calculation

[Richard]

What is funny (or maybe sad) is how people that are surely
competent programmers start doubting the most elementary
stuff when a lawyer starts telling them:

this is illegal... You can be prosecuted/sued for this.

This does happen a lot and is my main criticism of what this group has
become. One of my favorite examples being RH's description of something
like "*p++=c;". Never, in all my years in IT (many hours accumulated
training new recruits in various languages) have I seen anything so
twisted and bent out of shape and thus leaving the nOOb totally and
utterly confused.

 

[Ben Pfaff]

[attributions are long, confusing, and mostly irrelevant]

No, it is *unsigned* int, so the assignment of an unsigned long long
is perfectly legal, see the message where Heathfield apologizes
for his mistake in this thread

I swapped the types of sclen_lo and sclen_hi. Oops. I think
that my comments otherwise apply.

 

[Keith Thompson]

Why does one have to be a lawyer to point out that sizeof yields a
number of bytes, not a number of bits?

1) ADSP-TS201 TigerSHARC Processor Programming Reference 1-11 cites
bytes as a processor data type. (8 bit bytes)

[snip]

The way the processor manuals use the word "byte" is less relevant
than the value of CHAR_BIT in the C implementation used on that
processor. I don't happen to know what value is used for CHAR_BIT,
but it's plausible that it's greater than 8, regardless of what the
processor manual says.

In any case, if you're going to assume that CHAR_BIT==8, what's wrong
with making that assumption explicit?

[...]

And you tell me that bytes are not recognized by that processor?

Nobody said that.

 

[Kelsey Bjarnason]

you say that like it's a bad thing...

Note: sizeof returns the number of chars in an object (or type)
*not* the number of bits.



But like you I'm puzzled as to why a 32-bit shift
on a 64-bit quantity doesn't yield the top 32-bits.
Unless I misunderstood something...

unsigned long long scnlen;
int scnlen_hi;
sclen_hi = scnlen >> 32;

If the upper half of scnlen contains a value within the range of the upper
32 bits of an unsigned long long, but outside the range of a 32-bit signed
int, bad things could happen, no?

 

[Kelsey Bjarnason]

[snips]

FWIW, there is nothing wrong with making mistakes. There is something
very wrong, however, when sneering at people and acting like a little
princess and being wrong all in one.

People who should know better have been ragging him repeatedly for giving
correct and helpful answers, even if ones that may require a little noodle
work on their part. Why should he *not* give these people a hearty "Screw
you if you don't want help"?

He should. He has. Such people are contemptible.

 

[Pietro Cerutti]

unsigned long long scnlen;
int scnlen_hi;
sclen_hi = scnlen >> 32;

If the upper half of scnlen contains a value within the range of the upper
32 bits of an unsigned long long, but outside the range of a 32-bit signed
int, bad things could happen, no?

Yep, that's why sclen_hi should be unsigned int, as somebody wrote
elsewhere in this post.

 

[jacob navia]

Yep, that's why sclen_hi should be unsigned int, as somebody wrote
elsewhere in this post.

NO, since it holds the SIGN bit. If you assign a 32 bit quantity to
an int, if the sign bit is set in the unsigned right hand side, the
integer becomes negative, that is all.

If we have an unsigned long long FF FF FF FF 00 00 00 00,
the high part will be -1.

 

[Charles Bailey]

NO, since it holds the SIGN bit. If you assign a 32 bit quantity to
an int, if the sign bit is set in the unsigned right hand side, the
integer becomes negative, that is all.

If we have an unsigned long long FF FF FF FF 00 00 00 00,
the high part will be -1.

I'm not sure I understand this. When you say the "sign bit is set in
the unsigned right hand side", presumably you are talking about
assigning to a signed 32-bit integer type from an unsigned integer
type of longer width? In this case there is no sign bit in the
unsigned type but it is possible that the bit corresponding to the
sign bit is, in the unsigned representation, either a value bit or a
padding bit.

It doesn't much matter which case it is, if the integer value of the
unsigned type is not in the range of values representable by the
32-bit integer type to which you are assigning, then as far as I can
see the result is implementation-defined.

If the bit corresponding to the sign bit of a 32-bit integer is a
value bit in the corresponding unsigned type, then as the postive
values of the integer type must have the same representation as those
of the unsigned type, the value bit that the sign bit corresponds to
must represent a higher power of 2 than any of the value bits in the
signed integer type. If this bit is indeed a value bit and is set in
the unsigned type then the value represented by the unsigned type
cannot be a valid value for the signed type.

 

[CBFalconer]

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

Why do you even conceive that sclen_hi (or lo) contains 4 bytes?

You can usually use the modulo and division instructions to do this
sort of isolation.

 

[CBFalconer]

....

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

Yes. Nothing enforces CHAR_BIT == 8 for one thing. Then you have
unbandied use of ints to hold unsigned values. etc.

 

[CBFalconer]

.... snip ...

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, while Mr Navia will
accept C code working on the sample of machines he happens to work
with. [Disclaimer - I do not speak for either party here, and my
comments above are my interpreations of their positions]

However, RH's code is much more likely to work on any machine than
JNs. If RH wishes to use machine specific code he can do so, and
isolate it in easily replaced modules. Believe it or not, there
is no extra effort involved in doing this. If does, however,
require knowing the restrictions and limitations placed on C by the
standard.

 

[CBFalconer]

NO, since it holds the SIGN bit. If you assign a 32 bit quantity to
an int, if the sign bit is set in the unsigned right hand side, the
integer becomes negative, that is all.

scnlen is an unsigned quantity. It can never be negative.

 

[Jack Klein]

Please, are you a lawyer?

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

And please, a machine in use 2007 ok?

Sure, the Texas Instruments TMS320F2812. We have it on two different
boards in a safety-cricitcal medical device. I have written quite a
bit of code for it, and will be writing some more later this week.

CHAR_BIT = 16
sizeof (char) is 1
sizeof (short) is 1
sizeof (int) is 1
sizeof (long) is 2
sizeof (long) long is 4
sizeof (void *) is 2

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Jack Klein]

1) ADSP-TS201 TigerSHARC Processor Programming Reference 1-11 cites
bytes as a processor data type. (8 bit bytes)

2) The "expand" instruction can use explicitly 8 bit values as
input. ADSP-TS201 TigerSHARC Processor Programming Reference 10-41

3) The Add instruction can add bytes in parallel, as documented in
ADSP-TS201 TigerSHARC Processor Programming Reference 3-18

4) data in the registers can be avccessed as 8 bit bytes.
<quote>
To select the operand size within a register file register, a register
name prefix selects a size that is equal or less than the size of the
register. These operand size prefixes for fixed-point data work as
follows.
• B – indicates byte (8-bit) word data. The data in a single 32-bit
register is treated as four 8-bit words. Example register names with
byte word operands are BR1, BR1:0, and BR3:0.
< end quote>

And you tell me that bytes are not recognized by that processor?

You're making a big deal because you looked at the data sheet for one
of Analog Device's DSP models, in the newest and most expensive
series? The one that's too expensive for most applications?

Try on this quote for size, for an AD DSP that's been in use for a few
years, an excerpt from a PDF data sheet currently on their web site:

"Accessing Short Word Memory In C
Last modified: July 20, 1999
Introduction
The ADSP-2106x SHARC family processors’ C runtime
environment natively processes 32-bit datatypes. The DSP
hardware can be configured to process 48, 40, 32, and 16-
bit data, although the C runtime environment only natively
deals with 32-bit data."

Not an 8-bit value in sight, and you need special hardware tricks to
get at the two halves of any of the (all 32-bit) integer types in
memory.

Jacob, no matter how much you may know about C on desktops, you don't
know what you are talking about when it comes to the complete range of
embedded systems. Or what it takes to get robust C code running on so
many of them.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[somenath]

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

is the test "scnlen_hi < 4)" valid ? it may always fail

 

[Old Wolf]

It doesn't much matter which case it is, if the integer value of the
unsigned type is not in the range of values representable by the
32-bit integer type to which you are assigning, then as far as I can
see the result is implementation-defined.

Of course it is. Navia is talking about his own
implementation as if it were the only one, again.

 

[Mark Bluemel]

is the test "scnlen_hi < 4)" valid ? it may always fail

See my corrections to this code. It is (or should be) fairly obvious
what's missing here.

 

[Army1987]

I do not see any. It works in linux/windows/Mac/and many others.
But heathfield sees something, I do not know what, he is the lawyer,
not me!

Even if int has 32 bits and no padding, 0xaaaaaaaa doesn't fit in
it, and will become a negative value. But the specifier %x is for
unsigned values.
This happens to work on two's complement machines where signed int
overflow silently wrap around (so essentially the only difference
between signed and unsigned is the *meaning*, not the behavior, of
representations with the most significant bit set). But as per the
Standard, signed integer overflow is UB. (This is easily fixed by
declaring hi and lo as unsigned, or better as unsigned long (and
using "%lx") which is required to have at least 32 bits.)

 

[jacob navia]

However, RH's code is much more likely to work on any machine than
JNs.

I am amazed at your powers.

Without ever seeing a line of code from me, you are able to
assert that my code is much more likely to work
in any machine than RH's

http://dictionary.reference.com/browse/prejudice

prejudice
Pronunciation[prej-uh-dis]
–noun
1. an unfavorable opinion or feeling formed beforehand or without
knowledge, thought, or reason.
2. any preconceived opinion or feeling, either favorable or unfavorable.

 

[Chris Torek]

I have been trying to stay out of this thread, but it may be time
to mention this...

The original code included the following fragment:

After lots of argument, much of it best ignored I think,

scnlen is an unsigned quantity. It can never be negative.

Indeed. However, "scnlen_hi" is *not* unsigned. It almost certainly
should be. (scnlen_lo, in the original code, *was* unsigned, and
its computation with the (unsuffixed) mask 0xffffffff should, I
think, be safe, but is probably better written as 0xffffffffU or
even 0xffffffffUL.)

Bit-manipulation (shifting and masking and so on) should usually
be done with unsigned integers, in C, since the action of a sign
bit tends to be implementation-defined or (in some obnoxious corner
cases) undefined. Stick with unsigned: it is better-behaved.