arm-gcc: pointer to constant string

David Brown wrote:
> On 23/09/18 19:04, Les Cargill wrote:
>> David Brown wrote:
> 
>>> Let's take an example of where people get things wrong.  We have all
>>> seen code like this:
>>>
>>> // Make counter volatile so that it is atomic and safe for interrupts
>>> // even though we have a 16-bit cpu
>>> volatile uint32_t counter;
>>>
>>> void timerInterrupt(void) {
>>>     counter++;    // It's volatile - this is safe
>>> }
>>>
>>> uint32_t readCounterFromMainLoop(void) {
>>>     return counter;    // It's volatile - reading is atomic
>>> }
>>>
>>> Hopefully everyone reading this thread knows what the author's
>>> misunderstanding is here.  Yet we have all seen code written this way.
>>>
>>> How much testing do you need before you are likely to catch a problem 
>>> here?
>>>
>>> If the timer is run at 1000 Hz, you'll get a 16-bit overflow once per
>>> minute.  If you have something like a 10 MHz msp430 processor, you've
>>> got maybe a 0.2 microsecond window where there is a danger while reading
>>> the counter.  Perhaps you read 100 times a second.  That means you spend
>>> 1/50,000 of your time in the danger zone.  So every minute, you have a
>>> 1/50,0000 chance of a disaster.  If my sums are right, you'll have a 50%
>>> chance of trouble after about 35,000 minutes - or 24 days.  And that's
>>> assuming the problem is immediately obvious.
>>>
>>> You are /never/ going to catch this in any practical lab testing.  But
>>> if you sell 10,000 units, it /will/ occur in live installations.
>>>
>>
>> Excellent example. It's the sort of thing we would hope would be
>> covered in an undergraduate's section on semaphores.
>>
>>> So how close is your testing at showing the code is good?  Absolutely
>>> useless.
>>>
>>
>> Oh, I think either of us could devise a mechanism to test it :)
>>
> /How/ would you test for this occurring, in a way that does not imply 
> enough understanding to know how to write the code so that the problem 
> never occurs?
> 

Crank up a couple of high-frequency ISRs, plus a bit of boilerplate to
steer them by and detect the failure.

In the end, that specific case is one for design.

> There is no point in knowing how to test for a bug that you would never 
> have written in the first place.
> 
> 

Ah, but we're looking for unknown unknowns with testing.

-- 
Les Cargill