C 'desktop' programmer needs advice on how to code embedded C on a micro controller.

On Apr 10, 1:28 pm, David Kelly <n...@Yahoo.com> wrote:
> Back to my original statement, that tail is never used in IRQ.
>
> Wrote earlier in this thread that it is interesting to know when one has
> overflowed a buffer but that there isn't much one can do to recover in
> the field. Being a circular buffer an entire buffer full of data is lost
> but its not the same sort of thing as a buffer overflow security violation.

How important a buffer overflow is and what you can do about it are
entirely application dependant.  In one application you might not want
to use valuable CPU time to check the buffer, in another it may be
critical to know if the buffer is corrupt or even to prevent it by
dropping data and telling the app that it happened.


> If one does not notice the data loss from an overflowed buffer then one
> might claim their application is robust and error tolerant. If the
> overflow causes your device to barf then one doesn't need debugging
> flags to indicate something isn't working.
"Flags might help find it."

BINGO!!!  Even if buffer checking is not appropriate for your app in
the field, it can be a valuable resource for debugging.


> Have seen others to go much effort to calculate the length of data in
> the buffer. Beyond debugging I have seen little need. If there is data
> waiting it needs to be processed no matter how much is waiting.

Not sure what that means, but the important thing is to know if data
has been lost so that something can be done about it even if that is
to not trust the results produced from the data or turning on a red
light and shutting down!