One for luck ?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Only semi-serious, so I did toy with posting this in the 'Other' forum. Please move if appropriate).

 

When working with arrays, C strings, etc, does anyone else catch themselves making things maybe one or two bytes longer, just in case ? ;)

 

Part of me thinks I should have more confidence in my arithmetic; another part thinks this is 'defensive programming' and I can afford a few extra bytes here and there :p

 

I do tend to use snprintf() rather than sprintf(), etc, and calculate max offsets using sizeof(), but years of debugging other people's out-by-one and buffer overrun errors has clearly had a traumatic effect !

 

In the 'slightly bigger than an AVR but not quite a real computer' space, ESP32 and ESP8266 (Xtensa cores, gcc) implement stack smashing guards and helpful stack traces, but I imagine at the cost of some runtime overhead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not me.  I'm more worried (but not very) about running out of stack space.  In the past I have filled the stack area with a fixed value and then looked at that memory after running the program to see how far down the stack ate into the allocated space.

 

There is Ada for AVR and for ARM.  The way it can catch runtime errors is amazing, and when you're confident you can compile without the error-catching code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
... but years of debugging other people's out-by-one and buffer overrun errors has clearly had a traumatic effect !
re buffer overrun, there are linters of excellent value which detect some instances of that.

Eventually Checked C will make it to AVR.

obdevel wrote:
In the 'slightly bigger than an AVR but ...  and helpful stack traces, ...
likewise for PIC24/dsPIC which also have hardware detection of stack overflow and underflow; stack testing is limited on AVR though can be done when the debugger is attached.

 


ARR30-C. Do not form or use out-of-bounds pointers or array subscripts - SEI CERT C Coding Standard - Confluence

It’s Time to Use a Safer C | Electronic Design leads to Checked C - Microsoft Research

MDB Reference: backtrace - Developer Help

Stack Overflow Detection Using Data Breakpoint | Atmel Studio 7

 

MSC11-C. Incorporate diagnostic tests using assertions - SEI CERT C Coding Standard - Confluence

 

edit : one of maybe a few or several in Visual Studio's linter

C6029 | Microsoft Docs

...

warning C6029: possible buffer overrun in call to <function>: use of unchecked value

...

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Sep 24, 2020 - 06:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never!  But this can be carried over to allocating stack space of tasks, a few more bytes won't hurt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
... and when you're confident ...
I'm confidence-challenged by

  • operators
  • probability
  • nature
  • CRS

wink

My C textbook is somewhat well worn.

 

CRS - Idioms by The Free Dictionary

 


I didn't know you could get Ada for AVR | AVR Freaks

Ada GPL '20 | AVR Freaks (Arm, RISC-V)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:

Never!  But this can be carried over to allocating stack space of tasks, a few more bytes won't hurt.

 

Have you been reading my ESP32 FreeRTOS code ? ;) I really should implement some high-water-mark checking.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

C can automatically size arrays to fit strings.

The compiler usually knows what the string functions do.

It can issue warnings in many cases.

The string functions with n in their names will prevent

array overflow if one knows the size of the target.

It might result in a truncated string.

The string format for sprintf and its ilk allows specifying maximum field width.

 

Often you will not need to do much assembly:

Just call printf with at most a single format specifier.

 

My suggestion is to do the math right and document it.

Include assumptions, e.g. year<=9999.

 

Another possibility is to do whatever testing is necessary to

inspire confidence that a string will fit where you want it.

String processing generally does not need to be fast.

 

Moderation in all things. -- ancient proverb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been known to do the same.

 

One thing you could do is over allocate then fill the "extra" with a known "guard band" value then after running for a while check that the guards are intact. If so it's safe t reduce the allocation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
does anyone else catch themselves making things maybe one or two bytes longer, just in case ? ;

On X86, ARM & PIC32  - absolutely. In many cases the extra bytes (to next multiple of 4) are free. Plus I'm never going to run out of RAM here.

On PIC24 - absolutely. Even here I've still got heaps of SRAM.

On AVR - It's been a while now since my last proper AVR project; but yes I usually went to the next even number. (For no real reason apart from that it looked better)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

kk6gm wrote:
... and when you're confident ...
I'm confidence-challenged by

  • operators
  • probability
  • nature
  • CRS

wink

My C textbook is somewhat well worn.

 

CRS - Idioms by The Free Dictionary

 


I didn't know you could get Ada for AVR | AVR Freaks

Ada GPL '20 | AVR Freaks (Arm, RISC-V)

 

I will admit that I was not clear there.  I meant when you are confident that you've worked out the sizable majority of bugs in the particular software, then remove (if you think you need the extra performance) the runtime checks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

always, but that is because there have been times that I forgot that I needed space for CR+LF and \0 and that gave me a couple of free and rather large debug sessions as things turned bad at points were I would not expect it.... like a simple display update causing ADC readings to go out of control (ADC runs on its own interrupt and the display buffer seemed to be right next to the ADC results buffer.... that was a fun one as it also only happened during certain display stages that accidentally also used the entire display.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On systems with LOTSoRam, that is fine, but on small embedded mpu's with limited ram, it can cause problems, so I guess it "depends" on the application and mpu at the time, and if you feel you have ram to spare.

 

JIm

 

 

FF = PI > S.E.T