P: n/a

Hi,
Could someone please explain what signextension means? If I have a hex
number 0x55, how does this get signextended? Can a signextended
counterpart be equal to 91? In a program I'm expecting 0x55 in return
from a function whereas I am getting 91 every time.. does this mean
anything? Thanks
Sona  
Share this Question
P: n/a

"Sona" <so**********@nospam.com> wrote in message
news:3f********@clarion.carno.net.au... Hi,
Could someone please explain what signextension means? If I have a hex number 0x55, how does this get signextended?
Try asking this question in comp.programming.
Can a signextended counterpart be equal to 91? In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything?
It means you are doing something wrong. Hard to tell without more
context. Gi'us some code. The bit pattern 0x55 is not negative in any
C integral type I can think of. Try reproducing the problem with as little
code as possible and post it here.

Thomas.  
P: n/a

Sona wrote: Hi,
Could someone please explain what signextension means?
Sign extension is usually a lowlevel (i.e. assembly) processor term.
In most applications using the C language, there is no concern about
sign extension as that is accounted for in the definition of the
language.
Basically, sign extension is extending the sign of a number (positive
or negative) from a single unit integer to a multiunit integer.
For example, if you have an integer representing 0x55 and wish to
use two integers (to extend the range), you would set up the second
integer to be zero, which is the sign for a positive number (not
true for all platforms). Negativity is a bit different.
Let us assume for example, that in a given system, 1 is represented
by all bits set to one. When using two integers, the combination
must represent 1. So, the second integer is set to all ones to
extend the sign of the first integer.
Search for these programming concepts:
Multiple Precision Arithmetic
One's Compliment
Two's Compliment
If I have a hex number 0x55, how does this get signextended?
See above.
Can a signextended counterpart be equal to 91?
I believe you are confusing signextension with signed representation
of a number.
In Twos Compliment notation, I am get 0xA5 as 91 (8bit unit).
Sign extending to 16bits results in 0xFFA5, to 32 bits: 0xFFFFFFA5.
In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything? Thanks
Sona
I have no idea. There may be an infinite number of relationships
between 91 and 0x55; Two's Complement negativity isn't one of them.
Have you tried single stepping through the function with a debugger?
Or even using printf statements within the function?

Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++faqlite
C Faq: http://www.eskimo.com/~scs/cfaq/top.html
alt.comp.lang.learn.cc++ faq: http://www.raos.demon.uk/acllcc++/faq.html
Other sites: http://www.josuttis.com  C++ STL Library book  
P: n/a

"Sona" <so**********@nospam.com> wrote in message
news:3f********@clarion.carno.net.au... Hi,
Could someone please explain what signextension means? If I have a hex number 0x55, how does this get signextended?
Try asking this question in comp.programming.
Can a signextended counterpart be equal to 91? In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything?
It means you are doing something wrong. Hard to tell without more
context. Gi'us some code. The bit pattern 0x55 is not negative in any
C integral type I can think of. Try reproducing the problem with as little
code as possible and post it here.

Thomas.  
P: n/a

Sona wrote: Hi,
Could someone please explain what signextension means?
Sign extension is usually a lowlevel (i.e. assembly) processor term.
In most applications using the C language, there is no concern about
sign extension as that is accounted for in the definition of the
language.
Basically, sign extension is extending the sign of a number (positive
or negative) from a single unit integer to a multiunit integer.
For example, if you have an integer representing 0x55 and wish to
use two integers (to extend the range), you would set up the second
integer to be zero, which is the sign for a positive number (not
true for all platforms). Negativity is a bit different.
Let us assume for example, that in a given system, 1 is represented
by all bits set to one. When using two integers, the combination
must represent 1. So, the second integer is set to all ones to
extend the sign of the first integer.
Search for these programming concepts:
Multiple Precision Arithmetic
One's Compliment
Two's Compliment
If I have a hex number 0x55, how does this get signextended?
See above.
Can a signextended counterpart be equal to 91?
I believe you are confusing signextension with signed representation
of a number.
In Twos Compliment notation, I am get 0xA5 as 91 (8bit unit).
Sign extending to 16bits results in 0xFFA5, to 32 bits: 0xFFFFFFA5.
In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything? Thanks
Sona
I have no idea. There may be an infinite number of relationships
between 91 and 0x55; Two's Complement negativity isn't one of them.
Have you tried single stepping through the function with a debugger?
Or even using printf statements within the function?

Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++faqlite
C Faq: http://www.eskimo.com/~scs/cfaq/top.html
alt.comp.lang.learn.cc++ faq: http://www.raos.demon.uk/acllcc++/faq.html
Other sites: http://www.josuttis.com  C++ STL Library book  
P: n/a

"Sona" <so**********@nospam.com> wrote in message
news:3f********@clarion.carno.net.au... Hi,
Could someone please explain what signextension means? If I have a hex number 0x55, how does this get signextended? Can a signextended counterpart be equal to 91? In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything? Thanks
You can't get 91 from 0x55 in C.
In a C implementation where char are signed, and twos complement, 91 would
be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8
bits for a char.
 glen  
P: n/a

In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes: "Sona" <so**********@nospam.com> wrote in message news:3f********@clarion.carno.net.au... Could someone please explain what signextension means? If I have a hex number 0x55, how does this get signextended? Can a signextended counterpart be equal to 91? In a program I'm expecting 0x55 in return from a function whereas I am getting 91 every time.. does this mean anything? Thanks
You can't get 91 from 0x55 in C.
In a C implementation where char are signed, and twos complement, 91 would be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8 bits for a char.
struct foo {
signed char foo: 7;
} foo;
int main(void) {
foo.foo = 0x55;
printf("%d\n", foo.foo);
}
But this will print 43, not 91 ;).
But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/  
P: n/a

"Dik T. Winter" <Di********@cwi.nl> writes: In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes: > "Sona" <so**********@nospam.com> wrote in message > news:3f********@clarion.carno.net.au... > > Could someone please explain what signextension means? If I have a hex > > number 0x55, how does this get signextended? Can a signextended > > counterpart be equal to 91? In a program I'm expecting 0x55 in return > > from a function whereas I am getting 91 every time.. does this mean > > anything? Thanks > > You can't get 91 from 0x55 in C. > > In a C implementation where char are signed, and twos complement, 91 would > be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8 > bits for a char.
struct foo { signed char foo: 7; } foo;
int main(void) { foo.foo = 0x55; printf("%d\n", foo.foo); }
But this will print 43, not 91 ;). But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.
....on your implementation. Signed char in a bitfield is a
constraint violation (§6.7.2.1#4). Other than that, converting
0x55 (which is a positive number) to an integer type which cannot
represent it will either yield an implementationdefined value
(could be anything), or will raise an implementationdefined
signal.
Micah  
P: n/a

"Micah Cowan" <mi***@cowan.name> wrote in message
news:m3************@localhost.localdomain... "Dik T. Winter" <Di********@cwi.nl> writes: In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt"
<ga*@ugcs.caltech.edu> writes: > "Sona" <so**********@nospam.com> wrote in message > news:3f********@clarion.carno.net.au... > > Could someone please explain what signextension means? If I have a
hex > > number 0x55, how does this get signextended? Can a signextended > > counterpart be equal to 91? In a program I'm expecting 0x55 in
return > > from a function whereas I am getting 91 every time.. does this
mean > > anything? Thanks > > You can't get 91 from 0x55 in C. > > In a C implementation where char are signed, and twos complement, 91
would > be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum
of 8 > bits for a char.
struct foo { signed char foo: 7; } foo;
int main(void) { foo.foo = 0x55; printf("%d\n", foo.foo); }
But this will print 43, not 91 ;). But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.
...on your implementation. Signed char in a bitfield is a constraint violation (§6.7.2.1#4).
It presumably doesn't voilate the constraint on that implementation.
"A bitfield shall have a type that is a qualified or unqualified version
of
_Bool, signed int, unsigned int, or some other implementationdefined
type."
I don't know if this constraint exists for C90. [I don't think so, BICBW]

Peter  
P: n/a

On Wed, 24 Sep 2003 17:08:12 GMT, Thomas Matthews
<Th**********************@sbcglobal.net> wrote:
<snip> Search for these programming concepts: Multiple Precision Arithmetic One's Compliment Two's Compliment
The correct spelling of this word is "complement"; searching for that
is more likely to find correct answers. There is also an argument that
the apostrophe should be moved in "ones' complement" (and more
generally in radixminusone complement) but that is not nearly as
good an indicator.
Also note that pretty much all machines/CPUs today are 2sC. It is
useful to understand the concepts of 1sC, and also the simpler ones
for SignandMagnitude, and how some features of the C standard
allow(ed) for them, but don't expect to encounter them in practice.
 David.Thompson1 at worldnet.att.net  
P: n/a

"Peter Nilsson" <ai***@acay.com.au> writes: ...on your implementation. Signed char in a bitfield is a constraint violation (§6.7.2.1#4). It presumably doesn't voilate the constraint on that implementation.
"A bitfield shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementationdefined type."
I read this to mean the other *type* must be an
implementationdefined type (ruling out signed char). Is that wrong?
I don't know if this constraint exists for C90. [I don't think so, BICBW]
According to my draft copy, it exists in a more strict form:
implementationdefined types are not excepted.
C89 §3.5.2.1 (don't have a para number):
A bitfield may have type int, unsigned int, or signed int.
Whether the highorder bit position of a ``plain'' int bitfield is
treated as a sign bit is implementationdefined. A bitfield is
interpreted as an integral type consisting of the specified number of
bits.
If his implementation is being invoked in ISOconformance mode,
then he should be getting a diagnostic.
Micah   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 16172
 replies: 10
 date asked: Nov 13 '05
