• State Not Answered
  • Locked Locked
  • Replies 44 replies
  • Subscribers 21 subscribers
  • Views 15167 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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 ?

safron sperl 


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

comments?

Parents
  • 0 in reply to safron sperl

    My view is that it is obvious non-portable code; but since the coder wrote it explicitly, it is intentional and is not wrong.

    Intention doesn't imply correctness. You're missing the possibility that the coder may just as easily not have the slightest idea what he was doing.

    Code like the OP, particularly without a comment clearly stating the assumptions it relies on and why those assumptions should hold in the case at hand, is wrong.

Reply
  • 0 in reply to safron sperl

    My view is that it is obvious non-portable code; but since the coder wrote it explicitly, it is intentional and is not wrong.

    Intention doesn't imply correctness. You're missing the possibility that the coder may just as easily not have the slightest idea what he was doing.

    Code like the OP, particularly without a comment clearly stating the assumptions it relies on and why those assumptions should hold in the case at hand, is wrong.

Children
  • 0 in reply to HansBernhard Broeker

    "You're missing the possibility that the coder may just as easily not have the slightest idea what he was doing."

    There again, you're missing the possibility that I (as the coder) had a very good idea what I was doing!

    The reason I started this thread is that a number of projects I have previously worked on had lines of code very similar to the one I posted; and they relied on the action I expected (on a number of 8 bit and 16 bit processors). Apart from a quirk on an 80x86 core going beyond the 64K boundary, this has been an assumption that served me well.

    Now, however, I am porting the code to an ARM platform and the case of alignment has to be faced. I'm glad to see that the Keil compiler makes specific allowances for this type of situation (re: __packed) thus making my initial job of porting more predictable - At least using the same assumptions I have faced before.

    "Code like the OP, particularly without a comment clearly stating the assumptions it relies on and why those assumptions should hold in the case at hand, is wrong."

    I eliminated the comments from the original code precisely because I wanted to guage the thoughts others would have of the code.

    For those comments, I thank you all; and I appologise to Erik and Jack for re-igniting their (please insert the most appropriate term).

    My conclusion is that I believe that I have followed a pragmatic approach and that I am prepared to accept the fact that I am not a C purist.

  • 0 in reply to safron sperl

    I'm glad to see that the Keil compiler makes specific allowances for this type of situation (re: __packed)
    do that at your own risk, Jack Sprat (whoever it is that is hiing behind that monniker) will come down on you hard for going outside standard C

    Erik