how to read 4 consecutive bytes as an integer

[*DEAD*]

lol in assembler this is easy, but i dont know how to do it in c.

ive got a pointer to an array of bytes, but i want to read 4 of those bytes as an integer. Whats the best way to do this.

also, once i have that integer, im going to want to read it sooner or later as 4 bytes again.

[Mario F.]

> ve got a pointer to an array of bytes

I assume you then have an array of chars (8 bits = 1 byte).

> but i want to read 4 of those bytes as an integer.

A long integer perhaps? (4 x 8 = 32 bits = 4 bytes). Or really a 16 bit integer (2 bytes), meaning the bits would be truncated?

Anyways, check on the binary operators. Do you have some code already?

[*DEAD*]

lol yea its a long int. heres the code, but i haven't figured this bit out yet.

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

BYTE* loadPicture(void)
{
    HANDLE hBitMap = LoadImage(0, "img.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE);
    
    BITMAP bitmap;
    GetObject(hBitMap,sizeof(BITMAP),&bitmap);
    int size = bitmap.bmHeight*bitmap.bmWidth*bitmap.bmBitsPixel/8;
       
    printf("%d %d %d %d \n", bitmap.bmHeight, bitmap.bmWidth, bitmap.bmBitsPixel, size);
     
    BYTE *lpBits = malloc(size);
         
    GetBitmapBits((HBITMAP)hBitMap,size,lpBits );
    return lpBits;
}

long int getPixel(int x, int y, BYTE* lpBits)
{

}

int main(int argc, char *argv[])
{

    BYTE *lpBits;
    lpBits = loadPicture();
    int i;
    int pixel[4];
    
    for(i = 0; i < 160; i = i + 4) {
            printf("%d %d %d %d \n", lpBits[i], lpBits[i + 1], lpBits[i + 2], lpBits[i + 3]);        
    }


    system("PAUSE");	
    return 0;
}

lpBits is a pointer to an array of BYTEs, which is just the components of each color in a bitmap. What i need now is a getPixel function which returns an long integer representing the four bytes which make up the color of a particular pixel. Then when i want to compare it to something else (not in the code yet), ill want to read it as 4 bytes again. I figured this way would be simpler to manage, but perhaps not.

[Wraithan]

If they should form an int, just take an array of the 4 bytes, cast to void* then cast to int, or perhaps you can just cast the array directly to an int.

[vart]

char bytes[] = {0x01, 0x02, 0x03, 0x04}
int* pInt = (int*)bytes;
printf("%d - %x\n", *pInt, *pInt);

use ntos if needed reordering

[Salem]

> int* pInt = (int*)bytes;
This is neither safe against alignment exceptions, nor safe against endian problems.

char bytes[] = {0x01, 0x02, 0x03, 0x04};
int Int = bytes[0] | ( (int)bytes[1] << 8 ) | ( (int)bytes[2] << 16 ) | ( (int)bytes[3] << 24 );

Use CHAR_BIT in place on 8, 16, 24 for extra pedantry.

Of course you need to look at the file format for your multi byte integer to work out whether byte[0] is the LSB or MSB, and adjust the shifts accordingly.

[vart]

> int* pInt = (int*)bytes;
This is neither safe against alignment exceptions, nor safe against endian problems.

I agree that this can be an issue when we are talking about convrting some members of the structure...

But when we are working with some file format... In most cases there are 4 bytes written in the manner
fwrite(&i,sizeof(int),1,f)

so when this buffer is read into char buffer as
fread(buffer, sizeof(int),1,f)
the casting pointer to the correct type will assure that the result will be tha same as originally wrote value

[Salem]

Yes, the bytes in the char array will be in the same order.

But to say that the numeric value of a pointer cast int pointer will be the same isn't true at all as that assumes endian equality between the machine doing the writing and the machine doing the reading.

[Wraithan]

I hadn't thought about endianness when I suggested casting, nice save Salem, and of course Salem is right about this, you can't just cast since it is unsafe.

If you are going to be doing conversion between bytes/binary (bool arrays) a lot, you may want to just make a function to convert back and forth. (Ignorant suggestion coming:) if C has the inline keyword, between that and compiler optimizations, it shouldn't be any slower than typing it.