Last Comment Bug 278830 - base16-conversion is giving unexpectedly and unexpected negative values
: base16-conversion is giving unexpectedly and unexpected negative values
Status: RESOLVED FIXED
:
Product: Documentation
Classification: Graveyard
Component: Web Developer (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Web Developer Docs
:
:
Mentors:
http://devedge.netscape.com/library/m...
Depends on:
Blocks: 206366
  Show dependency treegraph
 
Reported: 2005-01-18 04:48 PST by Heinz Kohl
Modified: 2005-09-16 08:23 PDT (History)
2 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
example to show the effect (1.83 KB, text/html)
2005-01-18 04:50 PST, Heinz Kohl
no flags Details

Description Heinz Kohl 2005-01-18 04:48:58 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0

strange .toString(16) conversion together with sign handling , e.g.:
0xFFFFFF00: ffffff00
~0xFFFFFF00: ff
~(~0xFFFFFF00):-100  (expected: original value)
 ~0xfedcba .. -fedcbb  (a->b .. base complement, but here?!!)



Reproducible: Always

Steps to Reproduce:
1. a short html/javascript source will be given
2.
3.

Actual Results:  
1. unexpected "-" sign in a hexadecimal value
2. ~~x != x
3. unexpected '+1' in the textual representation of ~x hexadecimal value (to be
expected only on base complement machines), e.g. ~0xfedcba .. -fedcbb
(4. for the actual implementation I'm expecting a different textual
representation on 1-complement machines, e.g. ~0xfedcba .. -fedcba )

Expected Results:  
The results above are not really wrong (it's a mozilla extension), but more than
a bit surprising, and not that, what a C programmer is expecting (unsigned mask,
e.g. using ToUint32). 
I don't see a documentation of this behavior.


In a beginners course, I wanted to show, why the & 0xFFFFFF is necessary in
(~color) & 0xFFFFFF), and it wasn't easy to explain the results ...

(may be seen as minor bug, but may provoke hidden errors, and there is no really
easy way to invert 32-bit-masks)
Comment 1 Heinz Kohl 2005-01-18 04:50:28 PST
Created attachment 171627 [details]
example to show the effect
Comment 2 neil@parkwaycc.co.uk 2005-01-18 05:56:35 PST
>1. unexpected "-" sign in a hexadecimal value
Then what did you expect for (-256).toString(16)?

>2. ~~x != x
~ only returns a signed 32-bit integer. If x is not representable as a signed
32-bit integer then this is expected.

>3. unexpected '+1' in the textual representation of ~x hexadecimal value (to be
>expected only on base complement machines), e.g. ~0xfedcba .. -fedcbb
Actually this is completely expected, given 1. and 2.
Comment 3 Heinz Kohl 2005-01-18 08:22:32 PST
(In reply to comment #2)
> >1. unexpected "-" sign in a hexadecimal value
> Then what did you expect for (-256).toString(16)?

I don't think about negative hexadecimal values, the operation "-" should be
thaught as being undefined on bit masks.
But ~x should have 1-bits, where x is having 0-bits in one of the both usual
internal representations of x, 2-complement or 1-complement.

comment: of course, there is no "perfect" solution. But in the 35 years I'm
working in the software business, I was very often working with hexadecimal
values, but beside teaching and basic I/O software like toString I'm remembering
no other usages as for masking purposes. And these masks were very very often
including the "sign bit".

256 = 100(16), ~256 = "all bits inverted" - in a 32bit word, this is of course
FFFFFEFF(16), the value of this number as negative number is, I think, of minor
interest. 
E.g.: the inverse color value to 00FFFF is definitely FF0000 and not -FFFF or,
even worse, -10000(16)

depending to the internal representation, "-256" would then have one of the
values "FFFFFF00" or "FFFFFEFF" - but a programmer making his masks using
negative numbers .. ?!? 

actual state in Mozilla: 
   0xffffffff.toString .. ffffffff (as I expected)
  ~0xffffffff.toString .. 0 (as I expected)
  "0x"+0xefdcba.toString(16) ...    0xefdcba (as I expected)
but..
  "0x"+ (~0xefdcba).toString(16) .. 0x-efdcbb (and perhaps 0x-efdcba on a
1-complement computer)
I think, it should give 0xff102345, representing a 32bit mask, for 2- and
1-complement computers)


> 
> >2. ~~x != x
> ~ only returns a signed 32-bit integer. If x is not representable as a signed
> 32-bit integer then this is expected.

Yes, but 0xffffffff is the canonical hexadecimal representation of -1 on a
2-complement and -0 on a 1-complement computer with 32-bit words. This and only
this representation is also used in any computer science course for beginners.


Comment 4 Heinz Kohl 2005-01-19 04:39:40 PST
After study of ECMA262-3 I'm seeing that I'm in error.
But the user doc should be altered.

It is not enough to show the syntax of numbers. 
It would be valuable information to show the number concept, which is based on
ECMA 64 bit-reals, where the 32bit operations are a simulation of 32bit
2-complement integers based on a subset of this format, embedded in a 'best
possible' way into this 64bit environment. 

Unluckily "~" is defined by ECMA to work on signed 32bit integers. This should
be documented in an end users documentation.
In all cases "~" is therefore changing the sign:
- the description "the bit values are inverted" will say not enough about the
resulting value without "2-complement" (a user on a 1-complement computer would
expect ~x == -x, and in fact, the bit values are only thaught to be inverted)
- an output of such a value using an over 32bit concept (e.g. using
.toString(16)) will give a surprising effect and may cause ugly programming errors
- especially users of .toString(16) should be informed, what they are really
getting (e.g. ~0 .. -1, not 0xffffffff as expected)

(a bit inverting operation on unsigned 32-bit integers would make less troubles
with bit masks; alternatively an output operation like toStringU32(16), and both
could be able to help documenting the situation)
Comment 5 Bob Clary [:bc:] 2005-03-06 11:17:49 PST
per comments, marking invalid. I will see about adding a comment about this to
the js references when they become available from devedge.
Comment 6 Bob Clary [:bc:] 2005-03-31 08:51:16 PST
The section on Bitwise Operators needs more exposition on the effects of the
32bit conversion, negative numbers etc.
Comment 7 Bob Clary [:bc:] 2005-03-31 08:56:08 PST
sorry for the spam.
Comment 8 Yuh-Ruey Chen 2005-09-16 08:11:05 PDT
Fixed (but I can't close bugs)
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Bitwise_Operators
Comment 9 Nickolay_Ponomarev 2005-09-16 08:23:33 PDT
marking as fixed.

Note You need to log in before you can comment on or make changes to this bug.