Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27996 > unrolled thread

arm-gcc: pointer to constant string

Back to article view | Back to comp.arch.embedded

Contents

  arm-gcc: pointer to constant string pozz <pozzugno@gmail.com> - 2018-09-14 09:50 +0200
    Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 11:18 +0200
      Re: arm-gcc: pointer to constant string pozz <pozzugno@gmail.com> - 2018-09-14 13:05 +0200
        Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 13:25 +0200
    Re: arm-gcc: pointer to constant string Nils M Holm <nmh@ananda.local> - 2018-09-14 09:47 +0000
      Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 12:26 +0200
        Re: arm-gcc: pointer to constant string Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-09-14 14:52 +0200
          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 16:04 +0200
            Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-14 15:48 +0100
              Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 17:02 +0200
                Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-14 18:45 +0100
                  Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 20:37 +0200
                    Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-14 20:51 +0100
                      Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-15 16:24 +0200
                        Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-15 17:28 +0100
                          Re: arm-gcc: pointer to constant string Clifford Heath <no.spam@please.net> - 2018-09-16 13:58 +1000
                            Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-16 08:42 +0100
                              Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-16 08:47 +0100
                              Re: arm-gcc: pointer to constant string Clifford Heath <no.spam@please.net> - 2018-09-16 20:18 +1000
                                Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-16 12:25 +0100
                                  Re: arm-gcc: pointer to constant string Clifford Heath <no.spam@please.net> - 2018-09-16 22:22 +1000
                          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-16 15:00 +0200
                            Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-16 14:33 +0100
                              Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-16 22:06 +0200
                                Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-16 21:42 +0100
                                Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-17 21:24 -0500
                                  Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-18 08:49 +0200
                                    Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-21 22:15 -0500
                                      Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-22 11:53 +0200
                                        Testing (Was: arm-gcc: pointer to constant string) Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-09-22 12:16 +0200
                                          Re: Testing (Was: arm-gcc: pointer to constant string) David Brown <david.brown@hesbynett.no> - 2018-09-22 13:31 +0200
                                            Re: Testing (Was: arm-gcc: pointer to constant string) Clifford Heath <no.spam@please.net> - 2018-09-23 09:26 +1000
                                        Re: arm-gcc: pointer to constant string Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-09-22 20:06 +0300
                                          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-23 14:39 +0200
                                        Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-22 13:50 -0500
                                          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-23 15:21 +0200
                                            Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-23 16:06 +0100
                                              Re: arm-gcc: pointer to constant string julio@diegidio.name - 2018-09-23 08:41 -0700
                                                Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-23 16:49 +0100
                                                  Re: arm-gcc: pointer to constant string julio@diegidio.name - 2018-09-23 08:56 -0700
                                                    Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-23 18:20 +0100
                                                      Re: arm-gcc: pointer to constant string julio@diegidio.name - 2018-09-23 12:05 -0700
                                                        Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-23 20:50 +0100
                                            Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-23 12:04 -0500
                                              Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-23 18:27 +0100
                                              Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-23 19:37 +0200
                                                Re: arm-gcc: pointer to constant string Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-09-24 12:53 +0200
                                                  Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-24 13:49 +0200
                                                Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-28 20:17 -0500
                                  Re: arm-gcc: pointer to constant string Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-09-18 08:32 +0100
                                    Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-18 10:02 +0200
                                    Re: arm-gcc: pointer to constant string Les Cargill <lcargill99@comcast.com> - 2018-09-21 22:17 -0500
            Re: arm-gcc: pointer to constant string Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-09-14 18:30 +0200
              Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 20:46 +0200
        Re: arm-gcc: pointer to constant string Stefan Reuther <stefan.news@arcor.de> - 2018-09-14 19:57 +0200
          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-14 20:56 +0200
            Re: arm-gcc: pointer to constant string Stefan Reuther <stefan.news@arcor.de> - 2018-09-15 18:32 +0200
              Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-16 15:06 +0200
        Re: arm-gcc: pointer to constant string Richard Damon <Richard@Damon-Family.org> - 2018-09-14 19:59 -0400
          Re: arm-gcc: pointer to constant string David Brown <david.brown@hesbynett.no> - 2018-09-15 16:25 +0200
    Re: arm-gcc: pointer to constant string Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-09-14 13:49 +0300

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#28118

On 23/09/18 16:56, julio@diegidio.name wrote:
> On Sunday, 23 September 2018 17:49:17 UTC+2, Tom Gardner  wrote:
>> On 23/09/18 16:41, julio@diegidio.name wrote:
>>> On Sunday, 23 September 2018 17:06:44 UTC+2, Tom Gardner  wrote:
>>>
>>>> It is hard enough to get developers to write tests that
>>>> adequately test "happy days" (?daze?) normal operation.
>>>> Getting them to develop good tests for fault conditions
>>>> is more difficult.
>>>
>>> And beside the point anyway, while a (good) spec is supposed to cover all
>>> relevant cases to begin with: replied the developer.
>>
>> Good luck getting the customer to specify all the relevant
>> fault conditions!
> 
> That's just not the customer's job! It's rather called (good) analysis:
> replied again the developer, though conscious of the decades of relentless
> demolition campaigns of analysis to begin with... i.e. of the very premise
> for doing any job properly (and for taking responsibility for results).

Ah. Someone that hasn't experienced the religious
varieties of XP/Agile methodology!

There the customer is king, and they define what's
"good enough" even when they can't understand the
consequences and won't take responsibility :(

Apart from the religious zealots, is /anyone/ surprised
that XP/Agile has some disadvantages?


>> I've seen too many bad and inadequate tests.
> 
> If that's your main problem, you haven't seen nearly enough...

Main technical problem in uninteresting jobs :)


> 
> HTH (and EOD),
> 
> Julio
> 

[toc] | [prev] | [next] | [standalone]

#28121

On Sunday, 23 September 2018 19:20:35 UTC+2, Tom Gardner  wrote:
> On 23/09/18 16:56, julio@diegidio.name wrote:
> > On Sunday, 23 September 2018 17:49:17 UTC+2, Tom Gardner  wrote:
> >> On 23/09/18 16:41, julio@diegidio.name wrote:
> >>> On Sunday, 23 September 2018 17:06:44 UTC+2, Tom Gardner  wrote:
> >>>
> >>>> It is hard enough to get developers to write tests that
> >>>> adequately test "happy days" (?daze?) normal operation.
> >>>> Getting them to develop good tests for fault conditions
> >>>> is more difficult.
> >>>
> >>> And beside the point anyway, while a (good) spec is supposed to cover all
> >>> relevant cases to begin with: replied the developer.
> >>
> >> Good luck getting the customer to specify all the relevant
> >> fault conditions!
> > 
> > That's just not the customer's job! It's rather called (good) analysis:
> > replied again the developer, though conscious of the decades of relentless
> > demolition campaigns of analysis to begin with... i.e. of the very premise
> > for doing any job properly (and for taking responsibility for results).
> 
> Ah. Someone that hasn't experienced the religious
> varieties of XP/Agile methodology!

I hope you are kidding, or the one who is still not doing the proverbial
two plus two is just you.

> Apart from the religious zealots, is /anyone/ surprised
> that XP/Agile has some disadvantages?

That's too weak even as an euphemism.

The so called democratisation of programming, when suddenly from being few
top notch professionals we were flooded by hordes of clueless bullshitters,
was immediately followed by the vendors and then the consultancies and then
the self-appointed gurus launching their band-wagons: initially as pure tool
based development, later as the nonsense that they have dared call agile (true
agility is a good thing but it is just something else).  And these speculations
have not just been selling broken solutions to an entire industry for decades
now, these speculations have systematically denied and lied about the very state
of the art since day one, because only by defaming and lying about the state of
the art they could ever get away with so much unmitigated crap!  Indeed, sorry
for all this nonsense: I am a "just" a developer...  Yet people keep buying
into it, because so is the human race nowadays: demented.

> Main technical problem in uninteresting jobs :) 

You choose your job...  The gigantic technical and social and economic costs
are in the complete fuck up of the entire software industry.  And we all pay.

Julio

[toc] | [prev] | [next] | [standalone]

#28122

On 23/09/18 20:05, julio@diegidio.name wrote:
> On Sunday, 23 September 2018 19:20:35 UTC+2, Tom Gardner  wrote:
>> On 23/09/18 16:56, julio@diegidio.name wrote:
>>> On Sunday, 23 September 2018 17:49:17 UTC+2, Tom Gardner  wrote:
>>>> On 23/09/18 16:41, julio@diegidio.name wrote:
>>>>> On Sunday, 23 September 2018 17:06:44 UTC+2, Tom Gardner  wrote:
>>>>>
>>>>>> It is hard enough to get developers to write tests that
>>>>>> adequately test "happy days" (?daze?) normal operation.
>>>>>> Getting them to develop good tests for fault conditions
>>>>>> is more difficult.
>>>>>
>>>>> And beside the point anyway, while a (good) spec is supposed to cover all
>>>>> relevant cases to begin with: replied the developer.
>>>>
>>>> Good luck getting the customer to specify all the relevant
>>>> fault conditions!
>>>
>>> That's just not the customer's job! It's rather called (good) analysis:
>>> replied again the developer, though conscious of the decades of relentless
>>> demolition campaigns of analysis to begin with... i.e. of the very premise
>>> for doing any job properly (and for taking responsibility for results).
>>
>> Ah. Someone that hasn't experienced the religious
>> varieties of XP/Agile methodology!
> 
> I hope you are kidding, or the one who is still not doing the proverbial
> two plus two is just you.

Regrettably I'm not kidding, but the emphasis in
my statement is on "religious".

Agile/XP - when applied correctly and sensibly - does
have some advantages and can work.


>> Apart from the religious zealots, is /anyone/ surprised
>> that XP/Agile has some disadvantages?
> 
> That's too weak even as an euphemism.
> 
> The so called democratisation of programming, 

Democratisation isn't the word I would use. I would
probably use "downskilling".

The problem is that there is a limited supply of people
that are skilled and can think and have experience. And
aren't too expensive.


> when suddenly from being few
> top notch professionals we were flooded by hordes of clueless bullshitters,
> was immediately followed by the vendors and then the consultancies and then
> the self-appointed gurus launching their band-wagons: 

Exactly. Full stop.

Those are the <expletive deleteds> that push the religion,
so they can say "oh no wonder it failed, you only did 11
of the 12 necessary things".

That isn't limited to programming. Politicians are adept
at it (e.g. excuses for Brexit being a clusterfuck), and
town planners (e.g. "share spaced" "reduced demarcation"
zones).


> initially as pure tool
> based development, later as the nonsense that they have dared call agile (true
> agility is a good thing but it is just something else).  And these speculations
> have not just been selling broken solutions to an entire industry for decades
> now, these speculations have systematically denied and lied about the very state
> of the art since day one, because only by defaming and lying about the state of
> the art they could ever get away with so much unmitigated crap!  Indeed, sorry
> for all this nonsense: I am a "just" a developer...  Yet people keep buying
> into it, because so is the human race nowadays: demented.

Yes.


>> Main technical problem in uninteresting jobs :)
> 
> You choose your job...  The gigantic technical and social and economic costs
> are in the complete fuck up of the entire software industry.  And we all pay.

All but one of my jobs were very interesting; somehow I managed
to make some luck for myself :)

[toc] | [prev] | [next] | [standalone]

#28117

David Brown wrote:
> On 22/09/18 20:50, Les Cargill wrote:
>> David Brown wrote:
>>> On 22/09/18 05:15, Les Cargill wrote:
>>>> David Brown wrote:
>>>>> On 18/09/18 04:24, Les Cargill wrote:
>>>>>> David Brown wrote:
>>>>>>> On 16/09/18 15:33, Tom Gardner wrote:
>>>>>>>> On 16/09/18 14:00, David Brown wrote:
>>>>>> <snip>
> 
>>>> So what you can to is find the meat of what is possible and do that.
>>>>
>>>> I must say - I am rather tired of this old warhorse; an appeal to
>>>> Godel in the form of an economics question. All I would say is
>>>> that you should test as well as you can. You should use a dragon to
>>>> fight the dragon.
>>>
>>> No one will argue against the benefits of testing as well as you
>>> reasonably can.  Testing is often good enough to reach the level of
>>> confidence you want for code.
>>>
>>> But you are simply /wrong/ to think that non-exhaustive testing can
>>> somehow "prove" that code works.
>>>
>>
>>
>> "Proof" isn't that interesting outside of certain contexts. By "proof"
>> I mean fully formal verification that it's 100% known to be correct.
>>
>> We want to find a break-even variation on that. We want the cost and
>> the risk to be commensurate.
>>
> 
> Agreed.
> 
>> Turns out, just measuring the risk is pretty hard.
>>
> 
> Agreed.
> 
>>> And there are some classes of problem for which testing is extremely
>>> unlikely to identify the problem.  In particular, for anything
>>> involving race conditions or timing, you cannot /test/ your way to
>>> working code.
>>
>> Not in harness, but you can prove out the approach being used as a
>> demonstration and reasoning tool. And it depend on the problem - you
>> might be able to generate test vectors that get darned close.
>>
>> You point is probably "yes, but how close?" :) And it's a good one.
>>
> 
> Exactly, yes.
> 
> 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 :)

> This is not an unrealistic example.  And you don't even need something
> this unlikely.  Boeing made engine controllers that failed if they ran
> for something like 600 days without a restart - no one could spot that
> problem in testing.  Microsoft's Win 95 crashed reliably after 49 days
> when a 32-bit millisecond counter overran - it took /ten years/ to spot
> the problem, despite the huge numbers of systems in use.
> 
> 

I attribute those to "the fog of war". If anyone had been afforded the 
time to think about them properly, they would have found them ( by 
inspection ) but the phone rings, you have meetings, yadda yadd.

> There are things in code that you simply have to get right - you
> /cannot/ test that they are cocrect.  (As others have said, you might
> catch them with static analysis tools.)
> 
>> As an example, I had a "one producer/one consumer" buffer. I wasn't
>> 100% sure if it needed semaphores - one producer, one consumer, right?
>>
>> I thought about it a bit , built a driver loop
>> and was able to prove that I did indeed need semaphores. To be fair,
>> I was leaning that way anyway.
>>
> 
> Simplification of your structures and interactions can make it vastly
> easier to figure out what is correct and what is not.
> 

Very much so.

>>> You have to write the code correctly in the first place, because the
>>> chances of spotting the microsecond window of disaster in your lab
>>> testing is tiny.  (I am not saying you need to formally prove the code
>>> - again, this is all about appropriate balances of time and effort -
>>> but testing does not help.)
>>>
>>
>> Maybe it's bias from seeing stuff online, but I get the feeling
>> that many people ( and I'm pretty sure you, David, are not one of them )
>> just sort of despair of the whole thing.
> 
> I am certainly not in despair!  I am merely concerned when people
> apparently think that good testing is all they need to be sure their
> code works correctly.
> 

Oh, I didn't consider you to be in despair. Others, however, seem to be.

>>
>>>
>>>>
>>>> And so if your system is adept at rejecting inputs it cannot expect,
>>>> then what?
>>>>
>>>> It's all about the ability to enforce constraints. Sort your
>>>> constraints by the ability to do damage.
>>>>
>>>>> A functional programming language like Haskell gives you a much better
>>>>> chance of actually proving the correctness of your code than an
>>>>> imperative language like C - that is one of the reasons for the
>>>>> existence of functional programming languages (it is the lack of state
>>>>> and side-effects that help).  But if you want to prove the correctness
>>>>> of your Haskell program, you do it by an analysis of the code, or by
>>>>> deriving correct code in the first place - you don't do it by testing.
>>>>>
>>>>
>>>> That's because we'd like to pretend that "analysis" is some
>>>> process that's not automatable. Or, at least, not somehow aided by
>>>> automation.
>>>
>>> Analysis is much easier when you have restrictions on what can happen.
>>
>> You said it man. :)
>>
>>> In a pure functional programming language, your function takes some
>>> input and works solely on that input, and the only effect of the code
>>> is to generate the output.  That means you can analyse it in
>>> isolation.  In general C code, your function might use or change
>>> global state - it all quickly becomes a lot more complicated.
>>>
>>
>> But the thing you must learn with C is how to constrain the
>> use of global state.
>>
>> And for functional - in C.A.R. Tony Hoare's lecture on "The Billion
>> Dollar Mistake", a guy stands up at the end with the message "Haskell is
>> all fun and games until you invoke the I/O monad" :)
>>
> 
> That is the challenge with functional programming languages - for real
> life code, you usually need some state!
> 
>>> <snip>
>>>
>>>> For what it is worth, If I knew what I was trying to way, I'd say it :)
>>>>
>>>
>>> OK.  If you figure it out, we can take it up again - otherwise I think
>>> any replies I'd make would add to the confusion (mine, yours, or
>>> everyone else's).
>>>
>>
>>
>> It would be - in my opinion, we're obligated to do everything within our
>> power to get things as close to correct as possible. And, for some
>> reason, there isn't that much taught about how to do this, so we're
>> probably on our own. But the fact remains that we must do this.
>>
> 
> Agreed.
> 
>> This begins with design to provide information to
>> help determine that things work as expected. It continues with spending
>> time on frameworks, whether built or bought, to help check things.
>>
> 
> These points are true in themselves - but miss 90% of the more important
> issues.  If you leave the paragraph so unfinished, it gives entirely the
> wrong impression.
> 

I expect that anything beyond those quite general statements would
require more domain-specific information.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#28119

On 23/09/18 18:04, Les Cargill wrote:
> David Brown wrote:
>> On 22/09/18 20:50, Les Cargill wrote:
>>> David Brown wrote:
>>>> On 22/09/18 05:15, Les Cargill wrote:
>>>>> David Brown wrote:
>>>>>> On 18/09/18 04:24, Les Cargill wrote:
>>>>>>> David Brown wrote:
>>>>>>>> On 16/09/18 15:33, Tom Gardner wrote:
>>>>>>>>> On 16/09/18 14:00, David Brown wrote:
>>>>>>> <snip>
>>
>>>>> So what you can to is find the meat of what is possible and do that.
>>>>>
>>>>> I must say - I am rather tired of this old warhorse; an appeal to
>>>>> Godel in the form of an economics question. All I would say is
>>>>> that you should test as well as you can. You should use a dragon to
>>>>> fight the dragon.
>>>>
>>>> No one will argue against the benefits of testing as well as you
>>>> reasonably can.  Testing is often good enough to reach the level of
>>>> confidence you want for code.
>>>>
>>>> But you are simply /wrong/ to think that non-exhaustive testing can
>>>> somehow "prove" that code works.
>>>>
>>>
>>>
>>> "Proof" isn't that interesting outside of certain contexts. By "proof"
>>> I mean fully formal verification that it's 100% known to be correct.
>>>
>>> We want to find a break-even variation on that. We want the cost and
>>> the risk to be commensurate.
>>>
>>
>> Agreed.
>>
>>> Turns out, just measuring the risk is pretty hard.
>>>
>>
>> Agreed.
>>
>>>> And there are some classes of problem for which testing is extremely
>>>> unlikely to identify the problem.  In particular, for anything
>>>> involving race conditions or timing, you cannot /test/ your way to
>>>> working code.
>>>
>>> Not in harness, but you can prove out the approach being used as a
>>> demonstration and reasoning tool. And it depend on the problem - you
>>> might be able to generate test vectors that get darned close.
>>>
>>> You point is probably "yes, but how close?" :) And it's a good one.
>>>
>>
>> Exactly, yes.
>>
>> 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.

Yes, one would /hope/ that. Expect it, even.

Unfortunately in the real world... I've been unpleasantly
surprised by some of the people that were hired before my
time.


>> 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 :)

Indeed, but that presumes the possibility is understood. And
that's becoming more difficult where people "design" via
stackexchange+cut'n'paste for the framework du jour (and du project).

And if the tests show a "green light", that is taken as proving
it is working. Seriously :(



>> This is not an unrealistic example.  And you don't even need something
>> this unlikely.  Boeing made engine controllers that failed if they ran
>> for something like 600 days without a restart - no one could spot that
>> problem in testing.  Microsoft's Win 95 crashed reliably after 49 days
>> when a 32-bit millisecond counter overran - it took /ten years/ to spot
>> the problem, despite the huge numbers of systems in use.
>>
>>
> 
> I attribute those to "the fog of war". If anyone had been afforded the time to 
> think about them properly, they would have found them ( by inspection ) but the 
> phone rings, you have meetings, yadda yadd.

XP/Agile leaves it up to the customer to decide whether
there is time. Guess what happens next?

[toc] | [prev] | [next] | [standalone]

#28120

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?

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

[toc] | [prev] | [next] | [standalone]

#28123

David Brown wrote:

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

Well.  We are human, so we may occassionally make mistakes.  (I have
enough experience to know that I can make errors I never really would
make.)  There is also the matter of protecting the construct against
later (incorrect) modification.

Greetings,

Jacob
-- 
"make it easy for folks to make changes that remain consistent
 with the documentation and discourage them from those changes
 that would result in the comments being invalidated"

[toc] | [prev] | [next] | [standalone]

#28124

On 24/09/18 12:53, Jacob Sparre Andersen wrote:
> David Brown wrote:
> 
>> There is no point in knowing how to test for a bug that you would
>> never have written in the first place.
> 
> Well.  We are human, so we may occassionally make mistakes.  (I have
> enough experience to know that I can make errors I never really would
> make.)  There is also the matter of protecting the construct against
> later (incorrect) modification.
> 

Oh, we can all make mistakes.  But some mistakes are easier to avoid
than others.

I can appreciate that some programmers don't realise that "volatile"
does not mean "atomic", and will - as in my example - not realise that
reading a 32-bit value on a 16-bit cpu is not atomic.  (Even on a 32-bit
cpu, changing the value is unlikely to be atomic - but in the example,
the change was safe.)

And people can make mistakes even when they /do/ know about such things
- perhaps code was ported from a 32-bit system to a 16-bit system, or
the type was originally 16-bit and later changed to 32-bit.

However, I find it hard to believe that someone would know a good way to
test for such mistakes in the code without also knowing how to avoid
them - or that someone would think that this variable needs a test,
without also thinking that this variable needs to be read more carefully.

[toc] | [prev] | [next] | [standalone]

#28132

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

[toc] | [prev] | [next] | [standalone]

#28045

On 18/09/18 03:24, Les Cargill wrote:
> David Brown wrote:
>> On 16/09/18 15:33, Tom Gardner wrote:
>>> On 16/09/18 14:00, David Brown wrote:
> <snip>
>>
>> There are few cases where formal proofs are worth the time and costs 
>> involved.  But I like - when possible - to write my code with a view that a 
>> formal proof /could/ be made if someone were to go to the effort.   It is rare 
>> that you could prove a whole program - but not uncommon that you could (if you 
>> wanted to) prove many of the functions involved. Thinking in terms of 
>> pre-conditions, invariants, post-conditions, variants, specifications - that 
>> is all good stuff for writing solid code, even if you don't do so formally.
>>
> 
> If you stick to something akin to the Haskell Actor model and everything is an 
> event, it's not too onerous to use combinators to generate a significant subset 
> of all messages. With the proper level of introspection, you can "prove" the 
> program works to a limit
> enumerated by the test vectors and that it continues to do so as
> changes are made to the code base.
> 
> The test vectors and captured output can be controlled and
> compared to. And if you want to go as far as model
> checking or partial model checking, you have the stuff in place to enforce that 
> now.

That's nothing to do with formal proofs, of course.

It is equivalent to "inspecting quality into a product".

Yes, it is better than nothing/eyeballs - both of which
I've witnessed :(


> Obviously, there are domains where you just can't get close enough to this 
> ideal. So you gamble.
> 
> <snip>
> 
>>
>> Certainly I do not think C is the best choice of language for many of the 
>> types of use it is put to.  I think most people who program in C would be more 
>> productive and write more correct code in other languages - and most programs 
>> that are written in C would be better written in other languages.
>>
> 
> Possibly. But what C offers is the ability to build nonstandard, hybrid 
> "furniture" to support the development effort that can not be
> forseen by language and library designers. This is especially pronounced in 
> serialization and the ability to dynamically configure a program  ( which are 
> two sides of the same coin ).
> 
> C also supports event-driven-ness in a way that few other languages do.

Er, no.

Event-driven programming is used at all levels of the application
protocol stack. Frequently events/messages are layered on top of
events/messages at other levels without the implementers even
realising it.

For examples, start by looking at telecoms and fintech
applications - which are often written in Java :) (Including
high frequency trading where they spend billions (literally)
to shave ms off comms latency, and encode business rules
in FPGA hardware!)

[toc] | [prev] | [next] | [standalone]

#28046

On 18/09/18 09:32, Tom Gardner wrote:
> On 18/09/18 03:24, Les Cargill wrote:
>> David Brown wrote:
>>> On 16/09/18 15:33, Tom Gardner wrote:
>>>> On 16/09/18 14:00, David Brown wrote:
>> <snip>
>>>
>>> There are few cases where formal proofs are worth the time and costs
>>> involved.  But I like - when possible - to write my code with a view
>>> that a formal proof /could/ be made if someone were to go to the
>>> effort.   It is rare that you could prove a whole program - but not
>>> uncommon that you could (if you wanted to) prove many of the
>>> functions involved. Thinking in terms of pre-conditions, invariants,
>>> post-conditions, variants, specifications - that is all good stuff
>>> for writing solid code, even if you don't do so formally.
>>>
>>
>> If you stick to something akin to the Haskell Actor model and
>> everything is an event, it's not too onerous to use combinators to
>> generate a significant subset of all messages. With the proper level
>> of introspection, you can "prove" the program works to a limit
>> enumerated by the test vectors and that it continues to do so as
>> changes are made to the code base.
>>
>> The test vectors and captured output can be controlled and
>> compared to. And if you want to go as far as model
>> checking or partial model checking, you have the stuff in place to
>> enforce that now.
> 
> That's nothing to do with formal proofs, of course.
> 
> It is equivalent to "inspecting quality into a product".
> 
> Yes, it is better than nothing/eyeballs - both of which
> I've witnessed :(
> 
> 
>> Obviously, there are domains where you just can't get close enough to
>> this ideal. So you gamble.
>>
>> <snip>
>>
>>>
>>> Certainly I do not think C is the best choice of language for many of
>>> the types of use it is put to.  I think most people who program in C
>>> would be more productive and write more correct code in other
>>> languages - and most programs that are written in C would be better
>>> written in other languages.
>>>
>>
>> Possibly. But what C offers is the ability to build nonstandard,
>> hybrid "furniture" to support the development effort that can not be
>> forseen by language and library designers. This is especially
>> pronounced in serialization and the ability to dynamically configure a
>> program  ( which are two sides of the same coin ).
>>
>> C also supports event-driven-ness in a way that few other languages do.
> 
> Er, no.
> 
> Event-driven programming is used at all levels of the application
> protocol stack. Frequently events/messages are layered on top of
> events/messages at other levels without the implementers even
> realising it.
> 

Windows gui apps are often written as event-driven code, and no one sane
writes them in C - they use C++, Python, Delphi, Java, C#, VB, or many
other languages.  None of these are particularly specialised for events
or messages, but they all work at least as well or better than C for it.

Go is perhaps a good choice for event-driven code (I base that on
absolutely zero experience with Go...).

> For examples, start by looking at telecoms and fintech
> applications - which are often written in Java :) (Including
> high frequency trading where they spend billions (literally)
> to shave ms off comms latency, and encode business rules
> in FPGA hardware!)

And if they want code that works reliably (and can prove it), they use
Erlang rather than Java.

[toc] | [prev] | [next] | [standalone]

#28083

Tom Gardner wrote:
> On 18/09/18 03:24, Les Cargill wrote:
>> David Brown wrote:
>>> On 16/09/18 15:33, Tom Gardner wrote:
>>>> On 16/09/18 14:00, David Brown wrote:
>> <snip>
>>>
>>> There are few cases where formal proofs are worth the time and costs 
>>> involved.  But I like - when possible - to write my code with a view 
>>> that a formal proof /could/ be made if someone were to go to the 
>>> effort.   It is rare that you could prove a whole program - but not 
>>> uncommon that you could (if you wanted to) prove many of the 
>>> functions involved. Thinking in terms of pre-conditions, invariants, 
>>> post-conditions, variants, specifications - that is all good stuff 
>>> for writing solid code, even if you don't do so formally.
>>>
>>
>> If you stick to something akin to the Haskell Actor model and 
>> everything is an event, it's not too onerous to use combinators to 
>> generate a significant subset of all messages. With the proper level 
>> of introspection, you can "prove" the program works to a limit
>> enumerated by the test vectors and that it continues to do so as
>> changes are made to the code base.
>>
>> The test vectors and captured output can be controlled and
>> compared to. And if you want to go as far as model
>> checking or partial model checking, you have the stuff in place to 
>> enforce that now.
> 
> That's nothing to do with formal proofs, of course.
> 

Yes. Of course. It is, as all good engineering is, about the retirement
of risk.

> It is equivalent to "inspecting quality into a product".
> 

Oh heck no. Try "introspecting quality into a product".

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#28007

On 2018-09-14 David Brown wrote in comp.arch.embedded:
> On 14/09/18 14:52, Stef wrote:
>> On 2018-09-14 David Brown wrote in comp.arch.embedded:
>>> On 14/09/18 11:47, Nils M Holm wrote:
>>>>
>>>> Yes. K&R II (The C Programming Language, 2nd Ed), says that
>>>
>>> K&R does not define the C language.  It was an approximation to a
>>> definition until ANSI (then ISO) made the standard, and has not been
>>> relevant for decades.
>> 
>> You must be talking about K&R, Nils Specifically said K&R II.
>> That edition has printed "ANSI C" in large capitals on the cover.
>> A quote from the preface:
>>   "This second edition of 'The C Programming Language' describes C
>>    as defined by the ANSI standard"
>
> Exactly - it /describes/ the C language defined by the standard.  It
> does not define the language, or the standard, or give a complete or
> accurate set of rules for it.  That is what the /standard/ is for.  K&R
> (all editions) are /tutorials/, not standards or language definitions.
> (Equally, the standards are not tutorials, and say as much in their
> forewords.)  K&R was updated for the second edition to contain much of
> what is often incorrectly termed "ANSI C", but it was never expected to
> be exact.

K&R II is only partly a tutorial, the book itself puts that label only
on chapter 1. Appendix A is defenitely meant as a reference manual. But
it is presented as a more readable (but less concise) text than the
standard (which is "intended foremost for compiler writers" :-) ).

>> 
>> That standard is almost identical to C90 IIRC. And that standard is,
>> however old, still relevant. The Keil ARM compiler for instance defaults
>> to C90 and you have to specifically enable C99. (and nothing newer if you
>> don't want to set it to C++ 2003)
>> 
>> So don't throw out your K&R II just yet!
>> I have my copy within an arms reach. ;-)
>> 
>
> K&R is considered a "classic" in terms of quality technical writing.  It
> is not a good book for learning modern C.  It is not a good book for
> learning embedded programming.  It is not a good book to use as a
> reference for the details of the C language.  It is better than many
> others, but it is badly outdated, contains some horrible advice and
> examples, is strongly oriented towards command-line Unix software from
> the 80's and 90's, which is completely inappropriate for embedded
> development, and C is almost always a poor choice for modern day
> programming of the sort of tasks targeted in the book.

Indeed, if you are new to C (or programming), don't start with K&R II.
But if you (must) program in C90, it is a handy reference to have at
hand. Much more readable than any standard. But indeed do not expect
it to provide all the details.


> It is true that many compilers default to C90.  That is not an excuse
> for using C90 - if you are serious about C development, you should be
> using /your/ choice of C standard, not the default from the compiler.
> It is an unfortunate reality that some people still have to use
> compilers that don't support C99 - that is, obviously, a good reason for
> using C90.  Other than that, /you/ should choose your version of the
> language - and you should choose at least C99 because it lets you write
> higher quality software.  And if your tool vendor does not support C11
> by now, complain to them.
>
> The year is 2018.  Why anyone would think that a 30 year old tutorial
> book is a better choice of reference than the current official standards
> is beyond my comprehension.
>
> So K&R (I or II) is an interesting read, and interesting history - but I
> would not consider it a way to learn good embedded C programming, nor
> would I consider it a useful reference.

'Better' is not the word here. 'better read'?. If you (must) program in
C90, K&R II is nice to have at hand, it can answer >90% of your questions.
(and >85% for C99 ?) And mostly quicker than going on-line. So still useful
in my opinion, but not a definitive and complete reference.

> And if you want more readable references then there are plenty available
> online.  My recommendation (for C and C++) is
><https://en.cppreference.com/>.

For the other 10-15% ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

You've been leading a dog's life.  Stay off the furniture.

[toc] | [prev] | [next] | [standalone]

#28011

On 14/09/18 18:30, Stef wrote:
> On 2018-09-14 David Brown wrote in comp.arch.embedded:
>> On 14/09/18 14:52, Stef wrote:
>>> On 2018-09-14 David Brown wrote in comp.arch.embedded:
>>>> On 14/09/18 11:47, Nils M Holm wrote:
>>>>>
>>>>> Yes. K&R II (The C Programming Language, 2nd Ed), says that
>>>>
>>>> K&R does not define the C language.  It was an approximation to a
>>>> definition until ANSI (then ISO) made the standard, and has not been
>>>> relevant for decades.
>>>
>>> You must be talking about K&R, Nils Specifically said K&R II.
>>> That edition has printed "ANSI C" in large capitals on the cover.
>>> A quote from the preface:
>>>    "This second edition of 'The C Programming Language' describes C
>>>     as defined by the ANSI standard"
>>
>> Exactly - it /describes/ the C language defined by the standard.  It
>> does not define the language, or the standard, or give a complete or
>> accurate set of rules for it.  That is what the /standard/ is for.  K&R
>> (all editions) are /tutorials/, not standards or language definitions.
>> (Equally, the standards are not tutorials, and say as much in their
>> forewords.)  K&R was updated for the second edition to contain much of
>> what is often incorrectly termed "ANSI C", but it was never expected to
>> be exact.
> 
> K&R II is only partly a tutorial, the book itself puts that label only
> on chapter 1. Appendix A is defenitely meant as a reference manual. But
> it is presented as a more readable (but less concise) text than the
> standard (which is "intended foremost for compiler writers" :-) ).
> 

When K&R was originally written, there was no C reference document - the 
nearest was a manual for a Unix C compiler.  K&R II was, IIRC, published 
slightly before ANSI C.  I suppose there are really two meanings of the 
word "reference" here.  K&R had a C "reference" in the sense of a list 
of rules that you could look up things when you want some details about 
the language - the standards are "references" in the sense that they say 
how the language is defined.  If K&R says one thing, and the C standards 
say another, then the C standards are - by definition - correct for the 
C language.

(I agree that the C standards are not particularly readable.  I have got 
quite familiar with them over the years, but I still get caught out 
occasionally.)

>>>
>>> That standard is almost identical to C90 IIRC. And that standard is,
>>> however old, still relevant. The Keil ARM compiler for instance defaults
>>> to C90 and you have to specifically enable C99. (and nothing newer if you
>>> don't want to set it to C++ 2003)
>>>
>>> So don't throw out your K&R II just yet!
>>> I have my copy within an arms reach. ;-)
>>>
>>
>> K&R is considered a "classic" in terms of quality technical writing.  It
>> is not a good book for learning modern C.  It is not a good book for
>> learning embedded programming.  It is not a good book to use as a
>> reference for the details of the C language.  It is better than many
>> others, but it is badly outdated, contains some horrible advice and
>> examples, is strongly oriented towards command-line Unix software from
>> the 80's and 90's, which is completely inappropriate for embedded
>> development, and C is almost always a poor choice for modern day
>> programming of the sort of tasks targeted in the book.
> 
> Indeed, if you are new to C (or programming), don't start with K&R II.
> But if you (must) program in C90, it is a handy reference to have at
> hand. Much more readable than any standard. But indeed do not expect
> it to provide all the details.
> 

Again, I agree the standards are not readable - they are more for 
specialists, pedants, nerds and compiler writers (I think there is a 
fair overlap between these groups - with myself in the middle).  To be 
honest, I don't know what books would make a good starter or a good 
reference (in the readable sense) for modern C programmers.  I haven't 
needed a book on the C language - not since I read K&R some three 
decades ago.

> 
>> It is true that many compilers default to C90.  That is not an excuse
>> for using C90 - if you are serious about C development, you should be
>> using /your/ choice of C standard, not the default from the compiler.
>> It is an unfortunate reality that some people still have to use
>> compilers that don't support C99 - that is, obviously, a good reason for
>> using C90.  Other than that, /you/ should choose your version of the
>> language - and you should choose at least C99 because it lets you write
>> higher quality software.  And if your tool vendor does not support C11
>> by now, complain to them.
>>
>> The year is 2018.  Why anyone would think that a 30 year old tutorial
>> book is a better choice of reference than the current official standards
>> is beyond my comprehension.
>>
>> So K&R (I or II) is an interesting read, and interesting history - but I
>> would not consider it a way to learn good embedded C programming, nor
>> would I consider it a useful reference.
> 
> 'Better' is not the word here. 'better read'?. If you (must) program in
> C90, K&R II is nice to have at hand, it can answer >90% of your questions.
> (and >85% for C99 ?) And mostly quicker than going on-line. So still useful
> in my opinion, but not a definitive and complete reference.
> 
>> And if you want more readable references then there are plenty available
>> online.  My recommendation (for C and C++) is
>> <https://en.cppreference.com/>.
> 
> For the other 10-15% ;-)
> 
> 

[toc] | [prev] | [next] | [standalone]

#28009

Am 14.09.2018 um 12:26 schrieb David Brown:
> On 14/09/18 11:47, Nils M Holm wrote:
>> (A2.6) "A string has type 'array of characters' and storage class 'static'."
> 
> No, it is not - not for decades.  In C, "string" is defined in 7.1.1 of
> the current standard as "A string is a contiguous sequence of characters
> terminated by and including the first null character."

That is the library definition of "string". The language definition of a
string literal is in §6.4.5 which says:

# In translation phase 7, a byte or code of value zero is appended to
# each multibyte character sequence that results from a string literal
# or literals. The multibyte character sequence is then used to
# initialize an array of static storage duration and length just
# sufficient to contain the sequence. [...]

(paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)

> In particular, there is /no/ mention of storage class, and strings are
> independent of the storage class.

Sure, because the library does not care.

> A C compiler /can/ implement the call function "foo" in this manner :
> 
> void foo(void) {
> 	char s[STRING_LIT_LENGTH_HELLO];	// On stack
> 	copy_string_literal_from_compressed_storage(&s,
> 		STRING_LIT_IDENTIFIER_HELLO, STRING_LIT_LENGTH_HELLO);
> 	dummy(s);
> }

No, it can not. The literal in OP's code needs to have static storage
duration.

Maybe you're confusing it with

   void foo(void) {
       char s[] = "hello";
       dummy(s);
   }

This will be implemented exactly as you've sketched, but here the
programmer explicitly said they wanted an array with automatic storage
duration.


TL;DR: OP's code is safe, language-wise.

Of course, this is comp.arch.embedded, and people do strange things with
their silicon and their compilers, so I wouldn't be too surprised if
there were a compiler that needed special measures. But ARM has a nice
flat address space, so no problem here.


  Stefan

[toc] | [prev] | [next] | [standalone]

#28012

On 14/09/18 19:57, Stefan Reuther wrote:
> Am 14.09.2018 um 12:26 schrieb David Brown:
>> On 14/09/18 11:47, Nils M Holm wrote:
>>> (A2.6) "A string has type 'array of characters' and storage class 'static'."
>>
>> No, it is not - not for decades.  In C, "string" is defined in 7.1.1 of
>> the current standard as "A string is a contiguous sequence of characters
>> terminated by and including the first null character."
> 
> That is the library definition of "string". The language definition of a
> string literal is in §6.4.5 which says:
> 
> # In translation phase 7, a byte or code of value zero is appended to
> # each multibyte character sequence that results from a string literal
> # or literals. The multibyte character sequence is then used to
> # initialize an array of static storage duration and length just
> # sufficient to contain the sequence. [...]
> 
> (paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)

Yes, I know the difference between a string and a string literal - I 
said that in a bit you snipped.

And the library definition of a "string" /is/ the C definition of 
"string".  The term is italicised in 7.1.1, denoting that it is defined 
in that paragraph.

> 
>> In particular, there is /no/ mention of storage class, and strings are
>> independent of the storage class.
> 
> Sure, because the library does not care.
> 
>> A C compiler /can/ implement the call function "foo" in this manner :
>>
>> void foo(void) {
>> 	char s[STRING_LIT_LENGTH_HELLO];	// On stack
>> 	copy_string_literal_from_compressed_storage(&s,
>> 		STRING_LIT_IDENTIFIER_HELLO, STRING_LIT_LENGTH_HELLO);
>> 	dummy(s);
>> }
> 
> No, it can not. The literal in OP's code needs to have static storage
> duration.
> 

I know that's what the OP's code needs in order to be correct - the 
question is if the C standards guarantee that his code does what he wants.

> Maybe you're confusing it with
> 
>     void foo(void) {
>         char s[] = "hello";
>         dummy(s);
>     }
> 

No, I am not.

> This will be implemented exactly as you've sketched, but here the
> programmer explicitly said they wanted an array with automatic storage
> duration.

I know what the programmer wants, and I know what the programmer wrote. 
I know that with the compiler the programmer is using, the code he wrote 
does what he wants.  The question is if that behaviour is guaranteed by 
the C standards, or is merely the most practical implementation in most 
cases.  I cannot say for sure, but I believe the C standards do not 
guarantee the desired behaviour - I believe an implementation would be 
allowed to give the kind of implementation I described.

> 
> 
> TL;DR: OP's code is safe, language-wise.

Can you back that up with references to the standard?

> 
> Of course, this is comp.arch.embedded, and people do strange things with
> their silicon and their compilers, so I wouldn't be too surprised if
> there were a compiler that needed special measures. But ARM has a nice
> flat address space, so no problem here.
> 

I would be surprised to see an implementation - especially on an ARM - 
which did not work the way the OP wants.  A quick check with gcc on the 
AVR (where the string data would have to be copied from flash to ram) 
shows it works there too.  Perhaps someone would like to check it on 
other AVR C compilers, or more awkward processors.

[toc] | [prev] | [next] | [standalone]

#28024

Am 14.09.2018 um 20:56 schrieb David Brown:
> On 14/09/18 19:57, Stefan Reuther wrote:
>> Am 14.09.2018 um 12:26 schrieb David Brown:
>>> No, it is not - not for decades.  In C, "string" is defined in 7.1.1 of
>>> the current standard as "A string is a contiguous sequence of characters
>>> terminated by and including the first null character."
>>
>> That is the library definition of "string". The language definition of a
>> string literal is in §6.4.5 which says:
>>
>> # In translation phase 7, a byte or code of value zero is appended to
>> # each multibyte character sequence that results from a string literal
>> # or literals. The multibyte character sequence is then used to
>> # initialize an array of static storage duration and length just
>> # sufficient to contain the sequence. [...]
>>
>> (paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)
> 
> Yes, I know the difference between a string and a string literal - I
> said that in a bit you snipped.
> 
> And the library definition of a "string" /is/ the C definition of
> "string".  The term is italicised in 7.1.1, denoting that it is defined
> in that paragraph.

The library makes no mention of storage classes, meaning: it does not
care about storage classes.

The language defines what happens with a string literal in §6.4.5p5/6,
namely: construction of an array of static storage duration, with
content that - lo and behold - fulfils the library's requirements of a
string, by being a zero-terminated array of characters.

> I know that's what the OP's code needs in order to be correct - the
> question is if the C standards guarantee that his code does what he wants.

The question was: is a string literal's address and content valid after
the function containing it exits? The answer is: yes.

>> TL;DR: OP's code is safe, language-wise.
> 
> Can you back that up with references to the standard?

See above.


  Stefan

[toc] | [prev] | [next] | [standalone]

#28035

On 15/09/18 18:32, Stefan Reuther wrote:
> Am 14.09.2018 um 20:56 schrieb David Brown:
>> On 14/09/18 19:57, Stefan Reuther wrote:
>>> Am 14.09.2018 um 12:26 schrieb David Brown:
>>>> No, it is not - not for decades.  In C, "string" is defined in 7.1.1 of
>>>> the current standard as "A string is a contiguous sequence of characters
>>>> terminated by and including the first null character."
>>>
>>> That is the library definition of "string". The language definition of a
>>> string literal is in §6.4.5 which says:
>>>
>>> # In translation phase 7, a byte or code of value zero is appended to
>>> # each multibyte character sequence that results from a string literal
>>> # or literals. The multibyte character sequence is then used to
>>> # initialize an array of static storage duration and length just
>>> # sufficient to contain the sequence. [...]
>>>
>>> (paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)
>>
>> Yes, I know the difference between a string and a string literal - I
>> said that in a bit you snipped.
>>
>> And the library definition of a "string" /is/ the C definition of
>> "string".  The term is italicised in 7.1.1, denoting that it is defined
>> in that paragraph.
> 
> The library makes no mention of storage classes, meaning: it does not
> care about storage classes.
> 
> The language defines what happens with a string literal in §6.4.5p5/6,
> namely: construction of an array of static storage duration, with
> content that - lo and behold - fulfils the library's requirements of a
> string, by being a zero-terminated array of characters.

Ah - 6.4.5p6, second sentence: "The multibyte character sequence is then 
used to initialize an array of static storage duration and length just 
sufficient to contain the sequence."

Key here is that that the standards specifically say that this array has 
"static storage duration".  So yes, the OP's code is fine according to 
the C standard.

Thank you for leading me to this point.

> 
>> I know that's what the OP's code needs in order to be correct - the
>> question is if the C standards guarantee that his code does what he wants.
> 
> The question was: is a string literal's address and content valid after
> the function containing it exits? The answer is: yes.
> 

Agreed (now that I have seen the light).

>>> TL;DR: OP's code is safe, language-wise.
>>
>> Can you back that up with references to the standard?
> 
> See above.
> 

Thank you.


> 
>    Stefan
> 

[toc] | [prev] | [next] | [standalone]

#28014

On 9/14/18 6:26 AM, David Brown wrote:
>  In particular, for the ARM it would
> be very strange for a compiler to do anything that would not involve
> having the string literal at a fixed place in read-only flash.

I can easily think of cases where the string would not be accessed from
Read-Only flash on the ARM, the simplest is a system where the program
was stored in a non-execute-in-place media, and was copied by some from
of loader into RAM. The string would then exist in RAM, not flash, and
while it may not be enforced 'Read Only' the program (unless it has
performed UB) is not going to invalidate the string.

[toc] | [prev] | [next] | [standalone]

#28021

On 15/09/18 01:59, Richard Damon wrote:
> On 9/14/18 6:26 AM, David Brown wrote:
>>   In particular, for the ARM it would
>> be very strange for a compiler to do anything that would not involve
>> having the string literal at a fixed place in read-only flash.
> 
> I can easily think of cases where the string would not be accessed from
> Read-Only flash on the ARM, the simplest is a system where the program
> was stored in a non-execute-in-place media, and was copied by some from
> of loader into RAM. The string would then exist in RAM, not flash, and
> while it may not be enforced 'Read Only' the program (unless it has
> performed UB) is not going to invalidate the string.
> 

Fair enough - there is no need for the string to be in flash or 
read-only memory.  But it is likely that it would, at least logically, 
be at a fixed address in the memory map somewhere.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web