unsigned char buf[100] . . . unsigned int val; . . . val = *((unsigned int *)(&buf[1])); . . .
comments?
Yes, it is non-portable code. I can cause an alignment fault on some platforms.
been there, done that, and, even worse
Some compilers for 'multibyte word' processors that require alignment will not declare a fault but access the previous byte and the pointed byte instead of the pointed byte and the next. (I.e. a 16 bit processor that ignore LSB of the address for word fetch). When I complained about it to one compiler maker, I was informed "there is nothing in ANSI C about this". I never checked, what good does it do to state "there is something in ANSI C about this", if your program does not work because of such.
Then, of course, there are the endianness which, if the array is accessed both as char and int, will make a real pow-wow.
Erik (sorry abuot "multibyte word" what else would you call it)
That comes as no surprise.
When I complained about it to one compiler maker, I was informed "there is nothing in ANSI C about this". I never checked,
Neither does that.
what good does it do to state "there is something in ANSI C about this", if your program does not work because of such.
Well, you see, the standard defines the 'C' language. If you write code that makes assumptions that are not guaranteed by the standard then you cannot reasonably expect your program to work.
I know this will fall on deaf ears, but I'll say it again anyway: if you want to become proficient with a tool you really do need to read and understand the manual.
"It may rely on assumptions"
some of the longest debugging sessions ... have been a result of relying on assumptions.
Erik
Mr smoked sardine,
the references to ANSI C had absolutely nothing to do with the point
Let me try to translate my statement to something a smoked sardine can understand: "it makes no sense to discontinue development because of a bug (perceived or real makes no difference) in the tools if there is a workaround"
Word alignment is NOT a C issue but an architecture issue.
Yes, but life isn't expected to be simple. Anything non-trivial has to be based on a number of assumptions.
We can't avoid assumptions. Just try to make good ones, and to qualify them. We can made risk assesments for a project - what if our assumptions about used hardware, used tools, available time, stability of customer requirements etc are wrong. We can document our code, specifying what assumptions we have made (or rat least realizes that we have made). We can - if the hhardware permits - perform checked builds, that contains extra integrity-testing code. We can make use of the preprocessor. We can use regression testing...
While our job is to produce working - and economical - solutions, we can't ignore assumptions. If we think that there are no assumptions involved, then we have just made a very big, and very wrong assumption.
In short: it is almost impossible to write any non-trivial applications that are guaranteed to work on any existing platform that has an ANSI/ISO-conformant compiler.
It is nice that you see that I have a lot of experience.
If, on the other hand, you were trying to belittle me, you must have missed "BTW the 'error' was not mine, it occurred ... in my post.
Er5ik
Unfortunately, it may rely upon false assumptions - and it might only work by pure luck!
True - But someone who builds up experience of such things can learn to more reliably determine the risk.
Just to follow on from my previous - Through experience I have determined that I don't have to put on my wellington boots before getting out of bed.
I would prefer to consider it a calculated risk.
I would not consider it wrong - I might, possibly, change my mind if I were to get my feet wet one morning ;)
True - But someone who builds up experience of such things can learn to more reliably determine the risk. there is nothing wrong with experience, if therte was, I would be up the creek re the '51 :)
Of course, were I to 'verify' my assumption that a char is 8 bits every time I type char, I would never get anywhere.
I can state my point in another way, which may be better: "when you see a bug, before anything else, verify the correctness of your assumptions"
The references to ANSI C had absolutely everything to do with my point, however.
No, that isn't a translation of what you said. It may be what you wish you had said, but it certainly doesn't reflect what you did say.
Word alignment is NOT a C issue
So, why did you complain to the compiler vendor about your problem?
Sadly you do seem to have a lot of experience of bugs which you should never have introduced into the code in the first place. Your assumption when something doesn't work as you expect is that the problem lies with the tools - this is quite typical of those who (as you admit openly, in fact you seem proud of it) haven't read the appropriate documentation.
Note that in this case the 'tool' is the 'C' language, and the 'appropriate documentation' is the definition of the language.
you must have missed "BTW the 'error' was not mine, it occurred ... in my post.
Yes, I noticed you try to salvage some credibility in a followup post.
In reality, you have to. But you don't have to do it exactly when you write the 'char' keyword. But you - at least - have to verify it when you select a new processor or a new compiler. I don't expect one of my existing compilers to change that behaviour - at least not without adding a very visible note in the release notes :)
Luckily, no chip manufacturer dares to step away från n*8-sized integer data types, because of the very bad feedback they would get from all the people who made the incorrect assumption that their programs will not fail if run on a machine with a 7-bit or 9-bit char data type. If they do add unusual data types, they add them as complements to more standard data types.
One of the first things you should do when looking for a new compiler, is to get your hands on the documentation about their take on the implementation-specific parts of the standard. You want to know if there are significant limits in # of nested if statements, number of case statements in a switch, if you will be able to nest multiple include files, if they have the usual include files (complete with expected contents) etc.
In the same way, you have to make sure if a selected processor has a general stack implementation, or if it may have a hard-coded return stack with a limited # of return etnries. You want to know if it can index data - and to what degree. You want to know if it will glow like Chernobyl or if it has reasonable power-save modes. Some details you will look up. Some details you will forget to look up. Some details you will assume to be ok, and will ignore checking up on. Checking up on everything requires perfect documentation, perfect memory and almost infinite amounts of time.
Why do you not read it all When I complained about it to one compiler maker, I was informed "there is nothing in ANSI C about this". I never checked, what good does it do to state "there is something in ANSI C about this", if your program does not work because of such.
I would claim that ANY multiword byte compiler should, at least, warn when a memory location is "typecasted up" I really do not give ahoot if it is ANSI C or not, it is dead easy for a compiler to 'see' that "a memory location is "typecasted up" and an (optional) warning would make the tool much more useful.
I care about good tools, if the toolmalker decides to hide behind ANSI C that is just too bad.
Sadly you do seem to have a lot of experience of bugs which you should never have introduced into the code in the first place. When being a member of groups, I have most often been "the debugger" thus your uttely stupid assumption that bugs I have seen were those I "have introduced into the code in the first place" is completely false.
Your assumption when something doesn't work as you expect is that the problem lies with the tools Where on earth did you get that impression? Of course in a toolmakers forum tools are the main subject of discussion, it evidently takes a smoked sardine to ASS U ME that limiting a discussion to the subject means that there are no other subjects.
But you - at least - have to verify it when you select a new processor or a new compiler. Of, course; however, I wrote "every time"
Luckily, no chip manufacturer dares to step away från n*8-sized integer data types, because of the very bad feedback they would get from all the people who made the incorrect assumption that their programs will not fail if run on a machine with a 7-bit or 9-bit char data type. If they do add unusual data types, they add them as complements to more standard data types. I would not know about chips, but Univac and (some) DEC machines use 6 bit bytes.
PS "från" slipped into your post, do you write in Swedish first or did a word just slip in ?
No two-step translation involved. However, I sometimes gets parity bit errors - especially when someone comes in and wants to talk to me in the middle of writing :)
Sw: från = Eng: from. They start the same, the same number of letters and similar pronounciation.
IBM had 36-bit big iron, so they impplemented 4x 9-bit characters or 5x 7-bit characters.
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.
"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.
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
View all questions in Keil forum