arm-gcc: pointer to constant string - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: arm-gcc: pointer to constant string
On 23/09/18 16:56, snipped-for-privacy@diegidio.name wrote:
Quoted text here. Click to load it

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?


Quoted text here. Click to load it

Main technical problem in uninteresting jobs :)


Quoted text here. Click to load it


Re: arm-gcc: pointer to constant string
David Brown wrote:
Quoted text here. Click to load it

Excellent example. It's the sort of thing we would hope would be
covered in an undergraduate's section on semaphores.

Quoted text here. Click to load it

Oh, I think either of us could devise a mechanism to test it :)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Very much so.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

--  
Les Cargill


Re: arm-gcc: pointer to constant string
On 23/09/18 18:04, Les Cargill wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it




Quoted text here. Click to load it

Quoted text here. Click to load it

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.



Quoted text here. Click to load 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 :(





Quoted text here. Click to load it

Quoted text here. Click to load it

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

Re: arm-gcc: pointer to constant string
On 23/09/18 19:04, Les Cargill wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it




Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load 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.



Re: arm-gcc: pointer to constant string
David Brown wrote:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: arm-gcc: pointer to constant string
On 24/09/18 12:53, Jacob Sparre Andersen wrote:
Quoted text here. Click to load it

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.




Re: arm-gcc: pointer to constant string
David Brown wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it




Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

--  
Les Cargill


Re: arm-gcc: pointer to constant string
On 18/09/18 03:24, Les Cargill wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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

Re: arm-gcc: pointer to constant string
On 18/09/18 09:32, Tom Gardner wrote:
Quoted text here. Click to load 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...).

Quoted text here. Click to load it

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



Re: arm-gcc: pointer to constant string
Tom Gardner wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

--  
Les Cargill

Re: arm-gcc: pointer to constant string
On 2018-09-14 David Brown wrote in comp.arch.embedded:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

'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.

Quoted text here. Click to load it

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.

Re: arm-gcc: pointer to constant string
On 14/09/18 18:30, Stef wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: arm-gcc: pointer to constant string
Am 14.09.2018 um 12:26 schrieb David Brown:
Quoted text here. Click to load it

That is the library definition of "string". The language definition of a


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

Quoted text here. Click to load it

Sure, because the library does not care.

Quoted text here. Click to load it

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

Re: arm-gcc: pointer to constant string
On 14/09/18 19:57, Stefan Reuther wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

No, I am not.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Can you back that up with references to the standard?

Quoted text here. Click to load it

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.


Re: arm-gcc: pointer to constant string
Am 14.09.2018 um 20:56 schrieb David Brown:
Quoted text here. Click to load it

Quoted text here. Click to load it

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


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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

See above.


  Stefan

Re: arm-gcc: pointer to constant string
On 15/09/18 18:32, Stefan Reuther wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Agreed (now that I have seen the light).

Quoted text here. Click to load it

Thank you.




Re: arm-gcc: pointer to constant string
On 9/14/18 6:26 AM, David Brown wrote:
Quoted text here. Click to load it

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.

Re: arm-gcc: pointer to constant string
On 15/09/18 01:59, Richard Damon wrote:
Quoted text here. Click to load it

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.


Re: arm-gcc: pointer to constant string
On 14.9.18 10:50, pozz wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it


You can look up it yourself, just add -Wa,-adhlms=myfile.lst to your
command line (this for myfile.c).

Here is your example, slightly changed to prevent the optimizer from
make the code totally disappear:

static const char *s;

void dummy(const char *ss)
    {
    s = ss;
    }


const char *foo(void)
    {
    dummy("hello");
    return s;      /* added to keep the code */
    }

And the compiled code for Cortex-M3 (somewhat shortened):

    1                      .cpu cortex-m3
   11                      .file    "pozz.c"
   12                  .section .text.dummy,"ax",%progbits
   13                      .align    1
   14                      .global    dummy
   15                      .syntax unified
   16                      .thumb
   17                      .thumb_func
   18                      .fpu softvfp
   20                  dummy:
   21                      @ args = 0, pretend = 0, frame = 0
   22                      @ frame_needed = 0, uses_anonymous_args = 0
   23                      @ link register save eliminated.
   24 0000 7047             bx    lr
   26                      .section    .text.foo,"ax",%progbits
   27                      .align    1
   28                      .global    foo
   29                      .syntax unified
   30                      .thumb
   31                      .thumb_func
   32                      .fpu softvfp
   34                  foo:
   35                      @ args = 0, pretend = 0, frame = 0
   36                      @ frame_needed = 0, uses_anonymous_args = 0
   37                      @ link register save eliminated.
   38 0000 0048             ldr    r0, .L3
   39 0002 7047             bx    lr
   40                  .L4:
   41                      .align    2
   42                  .L3:
   43 0004 00000000         .word    .LC0
   45                         .section.rodata.str1.1,"aMS",%progbits,1
   46                  .LC0:
   47 0000 68656C6C         .ascii    "hello0"
   47      6F00
   48             .ident    "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620"

---

The string constant goes to an own section (.rodata) which is then
located as the linker script commands (often to ROM/ Flash).

--  

-TV


Site Timeline