Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
01/09/07 15:10
Read: times


 
#130509 - The warning you propose would be 'wrong' in some c
Responding to: ???'s previous message
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.

The warning you propose would be 'wrong' in some cases, i.e. you have a large piece of code that run with interrupts disabled (YES, I have seen that being correct, albeit rarely) and the 'automatic' feature disables once more and even worse, may enable after the critical is done. In such a case, you would not react to the warning and thus, in the final compile have a warning, that, in my book, is a NoNo.


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.

Oh, yes there is. You will not ever know when the compiler (fail to) disable and reenable the interrupts.

Erik

List of 32 messages in thread
TopicAuthorDate
atomicity, multibyte variables, C and my comfort            01/01/70 00:00      
   No way            01/01/70 00:00      
      Well, theoretically ...            01/01/70 00:00      
   Yes sdcc at least            01/01/70 00:00      
      Keil            01/01/70 00:00      
   Does it matter?            01/01/70 00:00      
      sort of...            01/01/70 00:00      
         Lack of this feature ...            01/01/70 00:00      
            really?            01/01/70 00:00      
   talking out of both sides of the mouth            01/01/70 00:00      
      :-)            01/01/70 00:00      
         the simple solution            01/01/70 00:00      
            The question was not how to fix it...            01/01/70 00:00      
   Don't disable            01/01/70 00:00      
      C extensions            01/01/70 00:00      
         ring buffer, atomicity and C            01/01/70 00:00      
            OK that was a stupid example...            01/01/70 00:00      
      Hardware solution called for            01/01/70 00:00      
         isn't HLL supposed to hide the low level details?            01/01/70 00:00      
            the skinny            01/01/70 00:00      
               Word length & Atomicity            01/01/70 00:00      
            Side effects            01/01/70 00:00      
               questions and answers            01/01/70 00:00      
                  Embedded Specific            01/01/70 00:00      
                     Neil, you GOT it            01/01/70 00:00      
                        waitaminute...            01/01/70 00:00      
                           from an old hand to a newbie            01/01/70 00:00      
                              what helps is good (?)            01/01/70 00:00      
                                 The warning you propose would be 'wrong' in some c            01/01/70 00:00      
                                    wrong warnings            01/01/70 00:00      
                                       Read-Modify-Write            01/01/70 00:00      
                                          OK then not simple            01/01/70 00:00      

Back to Subject List