Home/ Questions/Q 4625512
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T03:16:59+00:00

While attempting to read data from memory into an enum via the following code,

  • 0

While attempting to read data from memory into an enum via the following code, I got these weird results:

void read_memory (const unsigned, const unsigned, unsigned* const);

/* ... */

enum {DATA_0, DATA_1, DATA_2} data;
read_memory(base_addr, offset, &data);  //data = 0x0900
data >>= 8;  //data = 0x7e000000

I worked around this by introducing a temporary variable of unsigned type. But I’d like to be sure to understand why the previous method does not work.

First of all, I’m aware that the standard does not require a specific width for enum types, as long as all members can be represented. As a matter of fact, 6.7.2.2 states that:

Each enumerated type shall be compatible with char, a signed integer type, or an
unsigned integer type.

But since the raw data read from memory fits in a char, I think it should not be an issue.
Moreover, if I understand correctly, “compatible” means that you can use it as if it were of such a type. In particular, objects of enumerated type can be operands of bitwise shift operators.
I’m also aware that signedness may be a problem as we don’t know if enum are signed or not. But, as far as I can tell, 0x0900 does not appear to be signed.

So where does the problem lie ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    After testing the code outside the debugger, it turned out that it behaved correctly and it was the information displayed by gdb that was inaccurate.

    In fact, analyzing the disassembled machine code revealed that it did not match C source line numbers. As a result, the epilogue of the function was thought (by gdb) to be part of the data >>= 8; instruction.
    This issue remains strange to me since I compiled and linked all source and object files with -g -O0.

    Perhaps a bug in the compiler…

    Edit: Actually it had nothing to do with gdb, it was the debug symbols emitted by the compiler that were erroneous.

    • 0