Convert 32 bit unsigned int to 16 bit signed int.

[Triple-DES]

Except if u is an even multiple of 65536.

Hmm...that's interesting. Did I make a grammatical error, or isn't
that exactly what I wrote?

 

[Thomas J. Gritzan]

Hmm...that's interesting. Did I make a grammatical error, or isn't
that exactly what I wrote?

That's exactly what you wrote except the word "even".

But odd multiples do as well:
(65536 & 32768) is 0, and (65536 % 32768) is also 0.

 

[James Kanze]

Triple-DES schrieb:

That's exactly what you wrote except the word "even".

But odd multiples do as well:
(65536 & 32768) is 0, and (65536 % 32768) is also 0.

Yep. I was thinking of even multiples of 32768. (Of course,
all multiples of 65536 are even multiples of 32768.)

 

[James Kanze]

Okay, if I use 32767 as a value instead or or'ing 1<<i, there should be
no problem.

More or less. A value is a value, no matter how you arrive at
it.

But in that case 11111111000000001111111111111111 would be
2^24-1.

No. 0xFF00FFFF is *always* 4278255615. That's the definition
of hexadecimal.

The only time byte order can play a role is if you're type
punning, and you should almost never do that.

But would

unsigned long two_to_the_24th_minus_1()
{
unsigned long i(0);
for (int j=0;j<24;++j)
i|=(1<<j);
return i;
}

return 16777215 on such a machine?

Of course. What else could it return? You're doing
straightforward arithmetic. No bytes are involved, and
certainly no byte order.

As I am only a mathematician and not a logician, I am more
familiar with modulo arithmetics than with logical and'ing;

In general, it's probably better to use modulo arithmetic unless
you're actually manipulating bits. It's generally a lot
clearer. In this case, however, I believe that the original
specification said something about bit 15: if that's the case,
an expression like (u & (1<<15)), or even (u & 0x8000) certainly
expresses more clearly the intent to test bit 15 than does
modulo arithmetic.

 

[James Kanze]

As long as u is either an unsigned type or a signed type with
a non-negative value.

In the code (cut several postings up in the thread), u was
defined as a 32 bit unsigned.

 

[James Kanze]

I think the OP may be confusing external storage and internal,
where endianess typically doesn't matter. In other words,
there may be confusion that registers always hold a literal
copy of ram storage.

They generally do (modulo various optimizations). Even in RAM,
endianness is only relevant when you start playing funny games
with type punning. An int is an int, and except for type
punning, there are no "bytes" in it to be ordered.

 

[James Kanze]

...assuming int is at least 25 bits to avoid i<<j from
overflowing.

The size of int is irrelevant here, given that we're shifting an
unsigned long (which is guaranteed to be at least 32 bits).

 

[James Kanze]

<[email protected]>, James
On Sep 16, 12:16 pm, Ralf Goertz
[...]
But would
unsigned long two_to_the_24th_minus_1()
{
unsigned long i(0);
for (int j=0;j<24;++j)
i|=(1<<j);
return i;
}
return 16777215 on such a machine?
Of course. What else could it return? You're doing
straightforward arithmetic. No bytes are involved, and
certainly no byte order.
...assuming int is at least 25 bits to avoid i<<j from
overflowing.

The size of int is irrelevant here, given that we're shifting an
unsigned long (which is guaranteed to be at least 32 bits).

In the loop, it's shifting the literal 1, which is of type int
(I erroneously referred to that expression as i<<j, when it
was really 1<<j).

Oops. Good point. In the loop, that should be (1UL << j), and
not just (1 << j). And the error will go unobserved unless you
have a machine with ints smaller that 24 bits (which used to be
quite common).

 

[James Kanze]

<562eed65-f944-4f91-a3de-4b4c709e4...@y38g2000hsy.googlegroups.com>, James

[...]

Good point. In the loop, that should be (1UL << j), and not
just (1 << j). And the error will go unobserved unless you
have a machine with ints smaller that 24 bits (which used to
be quite common).

On this tangent, these days it's difficult to write programs
which work with 16-bit ints, since there's little to test on.
One can easily unintentionally rely on more than 16 bits in
int in many unexpected places that are hard to search for. And
using long, or something verbose like int_least_32_t,
everywhere hurts readability. In most of my own code meant to
run on decently powerful machines, I now just put a
preprocessor check that INT_MAX >= 0x7FFFFFFF and use int
almost everywhere.

That's really a valid option for a lot of things. I mostly
develope large servers, and there's absolutely no chance of
their running on a 16 bit machine, so there's no point in my
trying to be portable to such. In the past, however...

BTW, add a space after the "--" before your signature and
newsreaders will automatically remove it from the quoted text
when replying.

There is a space after it when the text is inserted into the
Google Post buffer. After that... I'm afraid I have little
control over what happens.

 

[Rashad]

try using bitwise operations

unsigned int a:15;