CODEWITHSUNDEEP
c
user3376293
user3376293

Reputation: 89

C String assignment backwards

I have some decompiled C source code and saw this strange string assignment.

char v1[21];
v1[0] = 0x75767778;
"tsrqponmlkjihgfedcba" = v1;

What is going on? How is this possible?

Upvotes: 3

Views: 123

Answers (1)

Keith Thompson
Keith Thompson

Reputation: 263547

char v1[21];

No problem so far; that defines v1 as an array of 21 char elements.

v1[0] = 0x75767778;

Legal, but incorrect. v1[0] is a char object. Unless CHAR_BIT >= 32 (which is unlikely), it cannot hold the value 0x75767778. If plain char is unsigned and CHAR_BIT==8, it would assign the value 0x78; if plain char is signed, it will probably do the same, but the value is implementation-defined.

It might be relevant that the bytes of 0x75767778 are the ASCII codes for the characters 'u', 'v', 'w', and 'x'.

"tsrqponmlkjihgfedcba" = v1;

This is simply illegal. A string literal cannot be the left hand side of an assignment and C does not support array assignment.

Apparently your "decompiler" (which you haven't identified) is generating something that more or less looks like C, but isn't.

This might be partly explained if the left and right sides of the assignments are being reversed. Even if that's the case, the output appears to be some sort of pseudo-code. (Did the code actually use = rather than, say, -> or =>?)

Seeing the source code from which this was "decompiled" would be helpful -- as would knowing what "decompiler" you're using and seeing its documentation.

My guess is that the source code had a string literal like "xwvutsrqponmlkjihgfedcba", and that generated code used an integer assignment to copy "xwvu" (represented as 0x75767778) and a separate operation for the remaining 20 characters, but that's only a guess. Or perhaps it was "abcdefghijklmnopqrstuvwx" and it was reversed due to byte ordering.

Upvotes: 6

Related Questions