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?
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.
Erik
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?
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.
I really do not give ahoot if it is ANSI C or not
if the toolmalker decides to hide behind ANSI C that is just too bad.
ANSI 'C', now ISO 'C', is the 'C' language. In a recent thread you demonstrated that you didn't even know how a 'for' statement worked, so I guess it should come as no surprise that you can't grasp that simple fact.
whatever does you snide reply have to do with the fact that I posted "I care about good tools" which you left out in your quote.
What I said, and you decided to overlook, was that if it is possible to put out a warning for risky code (in this case "risky on the particular platdoem") the tool should do so whether it has anything to do with the C standard or not
Your other snide remark re a for. For your information I actually posted that I knew how a for loop worked, just wanted to make sure of one particular fact where the text in the standard was slightly unclear.
Why do you not just go bask to the sardine can someboduy let you out of
Nothing at all. That's why I left it out of the quote. Why do you ask?
You should only rely on a compiler to behave as specified by the standard. It is unreasonable for you to expect a compiler writer to try and anticipate every mistake someone who refuses to read the standard might make and issue a warning. Think about it: if you rely on a non-standard warning issued by a compiler you will have to read the documentation of every compiler you use to determine whether your incorrect code will work, generate a warning or simply fail. Why not just read the standard to determine whether your code is guaranteed to work and be done with it?
For your information I actually posted that I knew how a for loop worked, just wanted to make sure of one particular fact
Either you know something or you don't know something. Why would you need to 'make sure' of something you know?
where the text in the standard was slightly unclear.
Please quote this 'unclear text' from the standard. By the way, I fully expect you to be unable to do so.
I'm sure you're ego would prefer that, but sorry, you're out of luck.
How very amazing. You babble about "the standard" and what we are discussing is "a warning if some architecthure created easy to detect mistake". I have never had alignment problems, be that from typecasting or something else, but have in, at least 5 cases solved somebody elses problem by fixing alignment issues. There are legions of people that believe that a REAL C person should NEVER have even an inkling about what the hardware does, and for such (I have met many) a warning when an easily detectable architecturally dependent mistake is made, what is your opposition to asking for a warning there.
Please quote this 'unclear text' from the standard. By the way, I fully expect you to be unable to do so. sorry not to meet your expectations. the 'description' of a for states "3 is done as long as 2 is valid".
There is nothing said about "updated 3 is written back whatever 2 is"
in addition re an excerpt from you babble above whether your incorrect code will work who on earth cares if incorect code will work, incorect code IS incorrect code.
Think about it: if you rely on a non-standard warning issued by a compiler you will have to read the documentation of every compiler you use to determine whether your incorrect code will work, generate a warning or simply fail.
The question isn't if people rely on warnings. Some people do. But rely or not: We do know that they catch a number of problems. Is a compiler that helps catching problems good or bad?
People don't buy lint programs just because they are stupid or lazy. They know that they make mistakes. They know that projects can have multiple developers, and one developer may make assumptions that are not consistent with the views of the rest of the team. Not too many developers likes to scan every line checked in by all other developers, just in case they have done something stupid.
I try not to rely on my car warning if a door isn't fully closed. However, I still like that extra information. If I chose to distrust everyone, then I would always have to take a full walk around the car whenever someone have touched a door or have thrown in some extra luggage.
How very amazing. You babble about "the standard" and what we are discussing is "a warning if some architecthure created easy to detect mistake".
You misunderstand. If you write code that is guaranteed by the standard to work then you don't have to worry about or rely on the compiler to issue a warning. Simple.
I have never had alignment problems,
Ok, ok. I'll pretend to believe that all these mistakes you seem to have encountered have been made by other people. I'm sure everyone else will as well. Let's face it, you demonstrate your exemplary knowledge from the very basics of 'C' all the way up to complicated concepts like a 'for' statement with refreshing regularity.
There are legions of people that believe that a REAL C person should NEVER have even an inkling about what the hardware does,
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.
a warning when an easily detectable architecturally dependent mistake is made, what is your opposition to asking for a warning there.
I have no objection to the warning, and the compiler is entitled to issue one if it wishes. What I object to is your reliance on such warnings, or complaints about lack of them, rather than just doing the sensible thing and actually reading the language documentation to find out whether the code is guaranteed to work.
sorry not to meet your expectations. the 'description' of a for states "3 is done as long as 2 is valid".
Please quote the paragraph number, I'm having trouble finding that particular bit of text.
who on earth cares if incorect code will work, incorect code IS incorrect code.
That is precisely my point. You need to write correct code rather than relying on your 'suck it and see' approach.
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.
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".
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."