| ??? 01/09/07 15:02 Read: times |
#130508 - what helps is good (?) Responding to: ???'s previous message |
Erik Malund said:
In C, I consider myself an 'old hand' (started with C86) and you state, yourself, that in C you are a newbie Well, not exactly a newbie... I was forced on several ocassions to C on PC (even including ISRs... :-O ), review other's programs (and code :-) ) etc. I *am* new in C on '51 (and did no C on any other mcu or 8-bitter). And, definitively, C-hater... :-) Erik Malund said:
C, already is full of 'traps' many of them showing up by you 'believing' the compiler will tell you some thing that it is not supposed to, and thus rarely will. Such an 'option' would lead to many hours of debugging because the compiler - or you - forgot to flag one such case. Many "clerical errors" (e.g. '==' and '=') in C are caught by the compiler, but not on a constant basis and I almost would rather have no reports where the report is not infallible. Oh, I know. And I realized painfully now when did this SDCC-stuff, that SDCC (contrary to the other C-compilers I came accross) does not warn on these. Of course I try not to rely on warnings - and I don't believe anybody would - but as I Pascal considerably more on PC, the '==' vs '=' comes quite inevitably up too often so that even that "fallible" warning comes very handy. I realize that detecting "atomicity violation" falls in much more ways than the above - still I believe this might help to realize a potential problem to those who are unaware of it - hence I find it more useful than detrimental. Should come with carefully worded documentation, to avoid complaints at least of those who care to read documentation... (Unfortunately, I still didn't learn how to cope with the users who are too stupid to understand the inherent limitations of any product). Erik Malund said:
I can not count the number of cases where I have found someone else's bug buy removing his "warning suppression". I don't understand why did you mention this. I am proposing a new warning, not suppression of an existing warning. I said:
I believe automatic interrupt disable/enable (or any other mechanism) around manipulation of a variable flagged critical (manually, by the user) may be beneficial. Erik Malund said:
No, anything 'hidden' is very detrimental for two reasons:
1) you do not know it is there and thus, if it being there is a problem, you will spend ages hunting the problem. 2) you believe it is there and spend ages hunting the problem that, in this particular case, it is not. There is nothing hidden in doing this. The user has to flag the variable as "critical" (read: he has tio write down the "critical" keyword next to the variable declaration) to trigger this mechanism. This is very similar to flagging a variable "volatile" - except that "volatile" has apparently an already defined standard role (I don't know this for sure, did not read C99, just guess so from answers of other users (here plus on the other forum I mentioned)). I'd also suggest a mechanism for the "envelope" could be controlled by the user. Erik Malund said:
I do not recall anything 'political' in this thread Comparing anything to M$ products is flammable... :-) Jan Waclawek |
