java转换为C / C ++（硬件c / c ++）转换

Question

In Java :

value = 1122;

public static final byte[] intToByteArray(int value) {
        return new byte[] {
                (byte)(value >>> 24),
                (byte)(value >>> 16),
                (byte)(value >>> 8),
                (byte)value};
    }

  public static int byteArrayToInt(byte[] data) {
        return (int)(
                (int)(0xff & data[0]) << 24  |
                (int)(0xff & data[1]) << 16  |
                (int)(0xff & data[2]) << 8   |
                (int)(0xff & data[3]) << 0
        );
    }

here it'll return [0, 0, 4, 98] so in C:

char* intToByteArray(int value){
        char* temp = new char[4];
         temp[0] = value >> 24,
         temp[1] = value >> 16,
         temp[2] = value >> 8, 
         temp[3] = value;
         return temp;
} 

since there's no byte data type in c we can use char* instead of that but when i return temp value i am getting null so i checked values like this where = b\\x04 'b'= 98, x04 = 4 i am not able to get data which is zero so while converting back how should i manage remaining values??

         char* where = new char[10];
         where[0] = temp[3];
         where[1] = temp[2];
         where[2] = temp[1];
         where[3] = temp[0];
         where[4] = 0;

Answer 1

i am getting null

No you are not. You are getting a first byte which is a \\0 nul byte. When you print this as a text string it will terminate the string. But its not a string, its an array of bytes.

If you were getting a NULL, you would get a segmentation fault or the like.

Answer 2

While the above post is absolutely correct, you have one more serious problem with your porting effort. Your java produces

[ 0, 0, 4, 98 ]

while your C produces

[ 98, 4, 0, 0 ]

The code won't work when simply converted like that. Java is big-endian regardless of the hardware, but your C(++) unsurprisingly is low-endian. Worse still, you cannot be sure that it will be that way every time. With Carbide, i guess that you can perfectly stumble upon a big endian architecture (some ARMs? not an expert in this field). So you must either detect endian-ness of your Carbide platform or, replace the bitshift with an incremental modulo 256. Depends on how often you call the function. Modulo will take seriously more processor effort but doesn't care about endianness.