This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

this is non portable code ?


unsigned char buf[100]
.
.
.
unsigned int val;
.
.
.
val = *((unsigned int *)(&buf[1]));
.
.
.

comments?

Parents
  • No, a program using implementation-specific behaviours in C is not considered invalid.

    That's quite beside the point --- the code we're talking about is considerably worse than that. It doesn't just rely on implementation-defined behaviour, but rather causes undefined behaviour.

    To give an explicit example: 6.1.3.4 in the language standard notes that it is undefined behaviour to make a conversion from an integer data typ to a different data type that can't handle the full numeric range. Assigning an int to a char for example.

    That example is seriously flawed --- conversion from int to char is not covered by 6.1.3.4. Nor does it cause undefined behaviour. It's covered by 6.1.3.3, and the behaviour is at worst implementation-defined.

Reply
  • No, a program using implementation-specific behaviours in C is not considered invalid.

    That's quite beside the point --- the code we're talking about is considerably worse than that. It doesn't just rely on implementation-defined behaviour, but rather causes undefined behaviour.

    To give an explicit example: 6.1.3.4 in the language standard notes that it is undefined behaviour to make a conversion from an integer data typ to a different data type that can't handle the full numeric range. Assigning an int to a char for example.

    That example is seriously flawed --- conversion from int to char is not covered by 6.1.3.4. Nor does it cause undefined behaviour. It's covered by 6.1.3.3, and the behaviour is at worst implementation-defined.

Children
No data