C Assign rows back

char v1[21];

      

        
        
        
      

    

No problem yet; which defines v1

as an array of 21 char

elements.

v1[0] = 0x75767778;

      

        
        
        
      

    

Legal, but flawed. v1[0]

- object char

. If CHAR_BIT >= 32

(which is unlikely), it cannot hold the value 0x75767778

. If plain char

is unsigned and CHAR_BIT==8

, it assigns a value 0x78

; if plain is char

signed it will probably do the same, but the meaning is implementation-defined.

It may be that the bytes 0x75767778

are the ASCII codes for the characters 'u'

, 'v'

, 'w'

and 'x'

.

"tsrqponmlkjihgfedcba" = v1;

      

        
        
        
      

    

It's just illegal. A string literal cannot be the left side of an assignment, and C does not support array assignment.

Apparently your "decompiler" (which you haven't identified) generates something more or less similar to C, but it doesn't.

This can be partially explained if the left and right sides of the assignments are reversed. Even if this is the case, the output seems to be a kind of pseudocode. (Did the code actually use =

, and not, say, ->

or =>

?)

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

I'm assuming the original code had a string literal, for example "xwvutsrqponmlkjihgfedcba"

, and that generated code used an integer assignment for copying "xwvu"

(represented as 0x75767778

) and a separate operation for the remaining 20 characters, but that's just a guess. Or perhaps it did "abcdefghijklmnopqrstuvwx"

, and it got canceled due to byte ordering.