No, this is expected, since the pointer to the first element in the buffer is cast to an int32. For the record, this version works:

void main (string[] args) {
    uint8[] buffer = { 1, 0, 1, 0 };
    stdout.printf("%d\n", ((int32[]) buffer)[0]);
}

$ ./test
65537
$ ./test
65537

(In reply to comment #0)
> $ cat test.vala
> void main (string[] args) {
>     uint8[] buffer = { 1, 0, 0, 0};
>     stdout.printf("%d\n", (int32) buffer);
> }
> $ valac test.vala
> $ ./test
> 165187424
> $ ./test
> 155156320
> $ ./test
> 160784224
> 

Is it a cast of a pointer to array to int32?

> I don't believe this is intended behavior, and I do believe converting from
> uint8[] to int could be very useful.

And source of subtle little vs. bigger endian bugs...

Could you provide a few motivational examples if you find it useful?

I wanted to read an int32 from a binary file. Being new to Vala and with virtually no C background, a lot of stuff is not intuitive to me.

(In reply to comment #3)
> I wanted to read an int32 from a binary file. Being new to Vala and with
> virtually no C background, a lot of stuff is not intuitive to me.

You need to take care about endianness:
http://en.wikipedia.org/wiki/Endianness

Basicly if you have 4-digit decimal number 0123 you can store it:
 - In bigger-endian format: 0123
 - In little-endian format: 3210
 - In middle-endian: 1032

The bigger-endian is arguably more natural - however the casts may be more expensive (you need to shift the pointer instead of doing nothing). 

In any case you probably should use GLib.DataInputStream:

var file_input = file.read ();
var data_input = new DataInputStream(file_input);
data_input.byte_order = DataStreamByteOrder.BIGGER_ENDIAN; // Sane format[1]
var my_int = data_input.read_int32();

I would propose to close it as WONTFIX.

[1] It MUST match the specification of file format. However if you design the spec choose one that does not match the most popular platform (x86 is little-endian). The performance impact of conversion is negligible but it will help you avoid hard-to-track errors when you forgot to change it.

PS. Don't worry - many people with "C" background forget about this as well. However with growing ARM platform popularity (read - all mobile phones, tablets, ...) you should be aware of the portability issues.

I already took care of it, although not as elegantly as in comment #4. I'd like to use GLib.DataInputStream, but it doens't seem to allow me to seek arbitrary positions in the file. If casting from an array directly to a integer is not an option, than I guess this is reaaly WONTFIX.

Created attachment 210776 [details] [review]
Proof-of-concept implementation of GSeekable for GBufferedInputStream

(In reply to comment #5)
> I already took care of it, although not as elegantly as in comment #4. I'd like
> to use GLib.DataInputStream, but it doens't seem to allow me to seek arbitrary
> positions in the file.

I don't know 'why not' - probably because noone implemented it.
I have attached proof-of-concept implementation of GSeekable for GBufferedInputStream. I will try to contact glib devs today and check if they are interesting [the patch need a) testing/checking for off-by-one errors b) implementation of truncation - I need to check the exact behaviour and c) copy'n'paste into GBufferedOutputStream]. I should be able to finish today but I prefer to first check if they are interesting.

> If casting from an array directly to a integer is not an
> option, than I guess this is reaaly WONTFIX.

I have not said that - I am not developer of Vala. But I don't think it is a good solution.

I've filled bug #673034.

This bug report was opened because GLib.DataInputStream didn't implement the seek features from glib (comment #5), and my workaround didn't work because it was wrong (comment #1).

Now I have been corrected (comment #1) and GLib.DataInputStream does implement seek (bug #673034).

Thanks!

Closing as NOTABUG.