Can overflow occur when reading unsigned int32 ?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. bitmatch this: 
{ im: 32: littleendian } 

Works fine for some values and not for others

What is the expected output? What do you see instead?
An unsigned int32 is expected But a signed int32 is given.
I also tried putting the attribute unsigned, but it didn't change anything

What version of the product are you using? On what operating system?
I'm using version 2.0.3 on Ubuntu 12.04

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 7 Jun 2012 at 3:06

[GoogleCodeExporter]

For which values does/doesn't it work?  Please provide a small example program 
demonstrating the problem.

Original comment by [email protected] on 7 Jun 2012 at 3:13

[GoogleCodeExporter]

I'm working on elf file parsing. Here is a portion of the code:
      (bitmatch in_bits with 
    | { im: 32: littleendian} -> 
      Assign (BinOp (Add, Im (big_int_of_int32 im), Context.eax), 40), 
      dropbits 32 in_bits
    | { _ } -> raise Reading_failed)

And here is a portion of the programs output:
mov ($0x804a014), %eax
mov $0x8049f20, %ebx
sub $0x8049f1c, %ebx
sar %ebx, $0x02
sub $0x-161, %ebx
cmp %ebx, %eax

and the same portion desassembled with 'objdump -d'
mov    0x804a014,%eax
mov    $0x8049f20,%ebx
sub    $0x8049f1c,%ebx
sar    %ebx,$0x2
sub    $0x1,%ebx
cmp    %ebx,%eax

Another example:

xor %ebp, %ebp
pop %esi
mov %esp, %ecx
and $0x-10, %esp

And the output with objdump:
xor    %ebp,%ebp
pop    %esi
mov    %esp,%ecx
and    $0xfffffff0,%esp

And its shown in the example, there are times the output are the same and some 
not.

Original comment by [email protected] on 7 Jun 2012 at 7:01

[GoogleCodeExporter]

This explanation still makes no sense.  Can you post a small, self-contained 
program which precisely demonstrates the problem you are having.

Original comment by [email protected] on 7 Jun 2012 at 7:18

[GoogleCodeExporter]

My program is a huge pattern matching just like the one above. Maybe i'm not 
asking the right question..
I took a look at the Int32 ocaml module and check the return value of 
Int32.max_int and its less than 2^32 -1. What happens when the 32 bits read are 
greater than Int32.max_int?

I've attached the parsing file, because I can't figure out what is 
"self-contained" in it. Its basically the same thing concerning the bitmatch 
aspect

Original comment by [email protected] on 7 Jun 2012 at 8:46

Attachments:

• decode.ml

[GoogleCodeExporter]

Bitstring will return the unsigned int32 bits, encoded in an Int32, as you can 
see:

    $ cat test.ml 
    open Bitstring
    open Printf
    let () =
      let bits = ones_bitstring 32 in
      let n =
        bitmatch bits with
        | { n : 32 : littleendian, unsigned } -> n
        | { _ } -> assert false in
      printf "%lx\n" n
    $ ./test
    ffffffff

Original comment by [email protected] on 7 Jun 2012 at 9:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tested the example you provided, but added one instruction:
printf "%s\n" (Int32.to_string n)

And here is the output:

ffffffff
-18048440

I'm sorry if I'm troubling, that's not my aim, I just want to understand

Original comment by [email protected] on 8 Jun 2012 at 8:00

[GoogleCodeExporter]

For me, the program prints out:

ffffffff
-1

In any case, the bits stored in the Int32 are correct.  Int32.to_string doesn't 
know how to print those bits out as an unsigned decimal number, that's all that 
is happening.  Write your own unsigned int printer, or grab one of several 
OCaml libraries that can handle unsigned numbers.

Original comment by [email protected] on 8 Jun 2012 at 10:16

[GoogleCodeExporter]

Ok, thanks for your help.

Original comment by [email protected] on 8 Jun 2012 at 11:14

[GoogleCodeExporter]

Found a solution to my problem, with some help :-).
Instead of using prinft, I used sprintf "%lu" to store the return value in a 
string. 

Original comment by [email protected] on 8 Jun 2012 at 2:27