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.
unsigned char buf[100] . . . unsigned int val; . . . val = *((unsigned int *)(&buf[1])); . . .
comments?
Ok, ok. I'll pretend to believe that all these mistakes you seem to have encountered have been made by other people. Of course not. This is in response to your snide remark about "all the mistakes I have made"
A real 'C' person writes code that is guaranteed to work by the standard ie *code that will work on all architectures* wherever possible. Unnecessary use of knowledge of the architecture makes code non-portable, and depending on precisely what non-standard behaviour you are relying on potentially unreliable. The point you are totally missing is that using 'nonstandard features' e.g. DATA, XDATA is a requirement for writing efficient code, which YOU quite clearly is incapable of since to adhere to the standard and the satndard only you are forced into the LARGE memory model. I am quite certain that Keil added these things just to annoy you.
I have no objection to the warning, Then why all the words about it?
What I object to is your reliance on such warnings, or complaints about lack of them You state that I, personally rely on such warnings after I have posted that I have never had alignment problems (I know what alignment is) but have found them in other code.
sorry not to meet your expectations. the 'description' of a for states "3 is done as long as 2 is valid".
I'm having trouble finding that particular bit of text. look for 'for' in the index, if you can not u8nderstand what I wrote, you do not know about it.
That is precisely my point. You need to write correct code rather than relying on your 'suck it and see' approach Mr preacher, you are preaching to the choir, nothing is farther from my coding than "it and see".
Erik
"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
Control Data Corporation's "Cyber" machines used 6-bit characters and a 60-bit word. The OS had a special "ASCII" mode that translated files with special multi-byte escape sequences to represent both upper and lower case. Writing character values in octal actually made sense for this machine.
Ok, I'm going to try a different method of getting sense out of you. We'll deal with your points one at a time in separate posts:
I'm having trouble finding that particular bit of text.
look for 'for' in the index, if you can not u8nderstand what I wrote, you do not know about it.
You originally stated that there was some text in the standard that was unclear. I asked you to quote the text in question, your response was some text that does not appear in the standard. You now suggest I look up 'for' in the index - well, that takes me to the section describing the for statement, but not to any unclear text. Now please, quote the actual text that you felt was unclear and provide the paragraph number that will allow me to find it.
I may have abbreviated a bit too much, but thought that you with your self proclaimed brilliance coud figure out the abbreviateion of expression_2 to '2' etc.
One place for reference would be section 8.5 in ANSI C language summary in Kochan: "programming in ANSI C", the reference to expression_3 speak of 'evaluation'. Thus reading this with a very suspicious eye you could get that it would be within the standard to 'evaluate' expression_3 vs expression_2 without updating the content of expression_3.
Now, of course, you are going to refer to K&R, but every comparison I have made between the "ANSI C LAnguage Summary" in Kochans book has shown them the same and thus I refeer to one book instead of running sround in the library to find more sources.
Most of us refer directly to the standard, instead of any books, since this world is full of authors that only "thinks" that they know what they are writing about, and that want to rewrite the information in a more clear way - while at the same time missing a number of important details of the original, unabreviated, language.
Section from 6.8.5.3, #1: "The expression expression-3 is evaluated as a void expression after each execution of the loop body."
Since void, it never returns a value to be used. Hence, I must expect that the sole goal of evaluating expression-3 is to produce some form of side effect, sinch as updating zero or more loop variables.
6.8.6.2 shows what happens when you have a (non-nested) continue within the loop body - i.e. the loop body will be considered processed, so evaluation of expression-3 will follow.
6.8.6.3 shows what happens when you have a (non-nested) break within the loop body, i.e. the loop body will not be finished and expression-3 will not be evaluated.
does 'evaluated' mean that the result is 'permanent' even if the 'evaluation' result in that the 'evaluated' entity is not to be used any more.
I am not a compiler writer, but as I read the text the resulting code of "for (x=0; x !=8 ; x++)" could 'legally' be e.g. either of these enter ..... loop: ....... inc x cjne x,#8,loop sjmp out
or
enter: mov r4,x ........ loop: mov x,r4 ..... inc r4 cjne r4,#8,loop sjmp out
In the first case x would be 8 when the for exits, in the second case x would be 7 when the for exits.
This, Mr Smoked Sardine, is not about understanding C but about understanding English in the K&R usage.
With Keil C51 x is 8 when the for exits and I am relying on Keil not to change that, but since this is about portability, the discussion should be "could this be different in another compiler"
The result of the evaluation is always thrown avay, since it is evaluated as a void expression.
However, whenever evaluated, any side effects will always be permanent.
Speculative evaluation are outside the scope of any language specification. It is part of compiler optimizations or (more commonly) internal processor optimizations. Speculative evaluation may then be done to process several branches at the same time - but with the requirement that only the side effects of the actually taken branch should be visible to an end user.
In short: Unless you add a break or return statement in the body of the loop, your expr3 side effects will always - for any C/C++ compiler - result in expr3 side effects (the loop variable being updated) until expr2 doesn't allow any furter iterations.
Too thick fingers, or to dim mind...
"your expr3 side effects will always - for any C/C++ compiler - result in expr3 side effects (the loop variable being updated) until expr2 doesn't allow any furter iterations."
Should say "your expr3 evaluations will always - for any C/C++ compiler - result in expr3 side effects (the loop variable being updated) until expr2 doesn't allow any furter iterations."
I am not a compiler writer, but as I read the text the resulting code of "for (x=0; x !=8 ; x++)" could 'legally' be e.g. either of these
No, it couldn't.
No, it isn't.
I'm glad to see that you've finally come clean about the supposed 'unclear text' in the standard - you didn't actually read the standard at all.
When will you realise that what you happen to believe based on your 'experience' is, with monotonous regularity, wrong?
Yes, it is, mr smoked sardine. It really is a question about understanding the english.
He specifically wrote "but as I read the text the resulting code of "for (x=0; x !=8 ; x++)" could 'legally' be e.g. either of these..."
It really is a question of language since 100% of the world population are not native english speakers. The people who are not, may have a lot harder to figure out the exact meaning of a sentence with the razor-sharp precision needed to get all the intricacies of a programming language. That is something you really have to accept - if not, it is time for us to start ridiculing you for being more than a little stupid.
If you want to continue discussing for loops, long/small/high/low/... whatever, you will get more respect (whatever alias you choose to use) if you concentrate on the "why" instead of always optimizing your answers for maximum ridicule.
Please return with a full linquistic analysis of the sentences of the for-loop description of the IEC/ANSI stanard. That would be a way better method of getting someone to see the point than slamming down a "No, it couldn't" - especially since you didn't manage to pick up the full meaning of Erik's sentence. You specifically failed to detect the "as I read it", which completely changes the meaning of that sentence.
And yes, I know I'm now open for ridicule too, since I'm not a native english speaker and you will be able to find a number of errors in this message. Fine - shoot. I'm sure everyone will be impressed, and we all love a long bloody battle on this forum.
I disagree. If he had familiarised himself with the concepts of variable scope and postfix operator side-effects there would have been no room for this uncertainty in the first place. If he really, truly doesn't know what 'evaluate' means after 20 years of 'C' programming then I despair.
I assume that the 'text' referred to is your quotations from the standard? Please bear in mind the fact that he hadn't read the standard when his question first arose, so the exact terminology used in those quotes is unlikely to be the problem.
It really is a question of language since 100% of the world population are not native english speakers. The people who are not, may have a lot harder to figure out the exact meaning of a sentence with the razor-sharp precision needed to get all the intricacies of a programming language.
I find that non-technical native english speakers have great difficulty reading technical documents. I find that I cannot make head nor tail of a legal document. Marketing speak flies over my head. As an engineer, though, I can read and understand technical documents. I would expect that any engineer whose english is as good as Erik's and with such lengthy experience to be able to read and understand english technical documents. As I understand it, english is the 'default' language used for international technical documents.
And yes, Erik's english is good, when he makes an effort. His posts are often difficult to understand however for the following reasons: a) He doesn't take enough time to read and understand what he is replying to. b) He doesn't take the time to type properly at the keyboard c) He doesn't take the time to think properly about what he's going to write.
I don't concentrate on 'why' because he should be capable of reading the documentation to find out for himself. In particular, he often criticises newbies for not reading documentation, so I really don't see why he cannot follow his own advice. If I ridicule him it is a response to his arrogance.
Please return with a full linquistic analysis of the sentences of the for-loop description of the IEC/ANSI stanard.
No, I won't attempt that, as linguistics is not my field. In any case, the for statement description is not sufficient on its own to answer his dilemma, as I have already pointed out.
That would be a way better method of getting someone to see the point than slamming down a "No, it couldn't" - especially since you didn't manage to pick up the full meaning of Erik's sentence. You specifically failed to detect the "as I read it", which completely changes the meaning of that sentence.
I think I've already answered these points.
And yes, I know I'm now open for ridicule too, since I'm not a native english speaker and you will be able to find a number of errors in this message.
Not at all. In general I find your posts to be well thought out and informative. You make fewer errors in your english than many (most?) native speakers.
I'm sure everyone will be impressed, and we all love a long bloody battle on this forum.
I have no interest in any sort of battle with you. However, I take exception to Erik's hypocritical and unfounded arrogance, so I will point out his errors. If he chooses not to accept that he is wrong I will keep going in the hope that his massive ego will deflate enough to actually accept that he is. Usually this moment comes after endless fabrication and mangling of quotations, desparate attempts to change the subject being debated to something else, childish name calling etc but culminates in the repeated posting of something describing me as a 'blabbering idiot'. That's when I realise that even he has given up on the idea that he can continue trying to brazen his way out of an untenable position.
Please, will everyone here accept my profound appologies for (re-)starting the Erik versus Jack discussion.