arm-gcc: pointer to constant string

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

Translate This Thread From English to

Threaded View
--- 1.c ---
void foo(void) {
   dummy("hello");
}

--- 2.c ---
static const char *s;

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



"hello" is a constant string declared inside function foo().  Is there a  
guarantee that his pointer (passed to dummy()) is valid after exiting  
foo()?  In other words, is the string on the stack (in this case it will  
not be valid after foo()) or in Flash (so it is permanent)?

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

It is not guaranteed by C, AFAIUI  - the literal is only valid during
its lifetime, which ends when the call to "dummy" returns.  However, gcc
always places such strings in flash and it will remain valid throughout
the program's lifetime.  I cannot see that changing in any future
version of gcc.

But note that the same does not apply to pointers to other objects that
might reasonably be put on the stack.  And it may not apply to targets
like the AVR where strings get copied from flash to ram before use.


Re: arm-gcc: pointer to constant string
Il 14/09/2018 11:18, David Brown ha scritto:
Quoted text here. Click to load it

If I was pedantic and I want to be sure the pointer to string is valid  
after dummy(), what should I do?  Do I declare the string static (even  
*in* the function)?

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


Quoted text here. Click to load it

Again the solution should be to explicitly declare objects as static.

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

It should, I think be fine to say:

void foo(void) {
    static const char* s = "hello";
    dummy(s);
}

I believe that will mean that the compiler is obliged to make the string
literal available for the lifetime of "s", which is program lifetime.

But I would be confident for arm-gcc to write it as you did, as the
compiler implements strings in a way that keeps them all for the
lifetime of the program.  (I assume you are not doing anything nasty and
undefined, like trying to change the values of strings somewhere.)

And it is also possible that I have this wrong, and that the compiler
/must/ keep the string literal around for the lifetime of the program.
comp.lang.c would be the newsgroup to look for extra opinions here.

Quoted text here. Click to load it

For the AVR, the solution is usually to use the macros and attributes
needed to access strings directly from flash to avoid wasting ram space.
 But it's a slightly awkward target.



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

Yes. K&R II (The C Programming Language, 2nd Ed), says that

(A2.6) "A string has type 'array of characters' and storage class 'static'."

and

(A4) "Static objects [...] retain their values across exit from and reentry
      to functions and blocks."

Quoted text here. Click to load it


--  

Re: arm-gcc: pointer to constant string
On 14/09/18 11:47, Nils M Holm wrote:
Quoted text here. Click to load it

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.  The standards copied most of the features and
rules given in K&R, but were not absolute about it.  Accurate draft
versions of the C standards are freely available on the net - the
current document of choice is N1570 for C11.

Quoted text here. Click to load it

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

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

Also, here the OP is asking about the practical lifetime of a string
literal, not a string.  Literals, like other constants (using the C
standards definition of "constant"), do not have lifetimes or scopes
like objects - the nearest you have is the period of validity of the
temporary pointer to the string literal.  And in the OP's code, that is
during the call to "dummy".

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);
}

That would - AFAIUI - be legal in C.  It is not the way gcc does it on
any targets I have seen (not even on the AVR, where the string must be
copied to ram in a case like this).  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.


Quoted text here. Click to load it

The current C definition of static objects' lifetime is given in
6.2.4p3, and is more accurate than the old K&R notes.  They are not
relevant here, however, since string literals are not objects.

(And if it is relevant to the OP, the rules for C++ are a bit more
complicated.  But C-string literals will be handled the same way by the
ARM gcc compiler.)

Quoted text here. Click to load it



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

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"

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

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

In 1914, the first crossword puzzle was printed in a newspaper.  The
We've slightly trimmed the long signature. Click to see the full one.
Re: arm-gcc: pointer to constant string
On 14/09/18 14:52, Stef wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

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.

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


Re: arm-gcc: pointer to constant string
On 14/09/18 15:04, David Brown wrote:
Quoted text here. Click to load it

Mine is the C++ FQA (sic): http://yosefk.com/c++fqa/

The FQA isn't completely up to date; but then the nice thing
about C "standards" is that there are so many to choose from.



Re: arm-gcc: pointer to constant string
On 14/09/18 16:48, Tom Gardner wrote:
Quoted text here. Click to load it

That is a page about C++, not C.  And it is widely ridiculed for being
repetitive, incorrect, outdated, wrong, exaggerated and basically
misunderstanding a huge number of issues about C++.  It certainly has
some valid points - C++ has plenty of faults, and the improvements to
the language that have come in recent standards shows there was plenty
that could be improved upon.  But the valid points in that "FQA" are
deeply hidden amongst the drivel.

With C, there are three standards to choose from - C90, C99 and C11.
(There is an upcoming C17, but it is basically a bug-fix and occasional
improved wording, so there is not much to be found there except nicer
typesetting.)

And there are also implementation-specific extensions - both compiler
specific and target-specific.

Generally, it is not hard to know which C version you are dealing with,
and there is very little code that is valid in one version that is not
equally valid in later versions.


Re: arm-gcc: pointer to constant string
On 14/09/18 16:02, David Brown wrote:
Quoted text here. Click to load it

Don't forget the commercially important /subsets/! The need
for subsets is a warning flag in itself.



Quoted text here. Click to load it

That statement, while correct, skims over a significant problem:
unfortunately too few people understand and can /predict/ what is
valid and invalid.

That's a problem with/for the tool, whether or not that is the
"tools" fault or the "users" fault.

Re: arm-gcc: pointer to constant string
On 14/09/18 19:45, Tom Gardner 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

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

What need of "commercially important subsets" are you talking about?

There /are/ compilers that implement subsets of C standards.  But I  
don't see a /need/ for them.

Quoted text here. Click to load it

Of course they can.  Very few people ever write code that is valid C90  
code and not valid C99 or C11 code.  There are /very/ few  
incompatibilities.  About the only one of significance I can think of is  
that functions no longer have implicit declarations.  What examples can  
you give of reasonable, valid C90 code that is not C99 compatible, or  
C99 code that is not C11 compatible?  Or C99 code that is not gnu99  
compatible?

Quoted text here. Click to load it


Re: arm-gcc: pointer to constant string
On 14/09/18 19:37, 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

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

MISRA-C, for example.


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 miss my point.

I am not arguing about the /differences/ between, say C99 and C11,
but C of /any/ standard.

Re: arm-gcc: pointer to constant string
On 14/09/18 21:51, Tom Gardner wrote:
Quoted text here. Click to load it

<snip>

Quoted text here. Click to load it

That is a set of rules for C, rather than a subset as such.  (And 90% of  
it could be replaced by three rules - 1. Learn the language properly and  
don't write invalid code.  2. Write in a readable fashion.  3. Get  
proper tools and learn how to use them.)

Of course if a specific task, project, employer or customer has rules  
for how you work, you need to know them and follow them.  But that is  
not "a subset of the language", or the fault of the language.

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

Not unlikely!

Quoted text here. Click to load it

I still don't get it.  Do you mean, say, the difference between C99 on  
gcc and C99 on IAR ?  Or the difference between C on an ARM and C on an AVR?


Re: arm-gcc: pointer to constant string
On 15/09/18 15:24, David Brown wrote:
Quoted text here. Click to load it

That's hairsplitting, which obscures rather than illuminates.


Quoted text here. Click to load it

Quoted text here. Click to load it

Nonsense.



Quoted text here. Click to load it

I know of three languages where subsetting is a practical
necessity: C, C++, and the SPARK subset of Ada. That's
significant.

However SPARK's objective and *ability* is something that
C/C++ cannot even dream of: provably correct implementation
for use in high integrity systems. To get that you would have
to subset /any/ language (except possible NewSpeak!).




Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it



No. Very, /very/ few - if any - developers understand
all the undefined and implementation defined behaviour
of any standard of C or C++, and how to reconcile different
parts of the same standard (or differing implementations
of the same standard)!

Statements from those that were involved in some of the
standardisation efforts lead me to believe that's also
the case for
  - commercial compiler writers, several of whom have had
    requested requested opinions about how standard clause
    X can be reconciled with standard clause Y
  - the committee itself, e.g. infamously with their refusal to
    believe C++ templates were Turing complete until somebody
    rubbed their faces in proof!

No, I can't quote chapter and verse. While watching the
shenanigans from the sidelines it became apparent to me
that C/C++ was becoming (early/mid 90s) part of the problem
as well as part of the solution.

Re: arm-gcc: pointer to constant string
On 16/09/18 02:28, Tom Gardner wrote:
Quoted text here. Click to load it

You must be unfamiliar with the *formally proven* C compiler
that was part of the sel4 (formally-proven microkernel) project.
I've met some of the people, who work here in Sydney.

They proved the operating system guarantees *down to the silicon*
for a specific ARM 9 chip (with MMU).

Clifford Heath.

Re: arm-gcc: pointer to constant string
On 16/09/18 04:58, Clifford Heath wrote:
Quoted text here. Click to load it

Reference please, and has the claim withstood knowledgeable
scrutiny?

How did they formally prove the compiler? That in itself is
"entertaining" for an incompletely defined language such as C.

Does "down to the silicon" include the silicon itself?

The A9s are complex devices with caches, interrupts etc.
How was the effect of those taken into account in the proof?

Re: arm-gcc: pointer to constant string
On 16/09/18 08:42, Tom Gardner wrote:
Quoted text here. Click to load it

Just noticed you claim the /compiler/ was formally proven;
too little coffee :(

What are the caveats/limits to that proof?

Was it a full standard C specification (which standard?)
or just a subset of C.

Basically I regard the claim of a formally specified C
compiler as "extraordinary", and hence it requires
"extraordinary proof".

Re: arm-gcc: pointer to constant string
On 16/09/18 17:42, Tom Gardner wrote:
Quoted text here. Click to load it

It it too hard for you to type "sel4" into Google?

The first hit is <https://sel4.systems , but there are
many resources for this, including the backgrounder
on L4 family microkernels on Wikipedia.

You can download all the code, all the specifications
(which are executable) and the compilers and provers,
and run them yourself.

This is the culmination of a massive multi-decade effort
by some of the world's smartest people. It's not some
maverick's hobby.

Re: arm-gcc: pointer to constant string
On 16/09/18 11:18, Clifford Heath wrote:
Quoted text here. Click to load it

Google orders results on what it thinks you are interested
in :( It is easy for you to provide a definitive link.


Quoted text here. Click to load it

The sel4 FAQ includes "The reduced proof assumptions mean
that we do not need to trust the compiler or linker, but
there may still be faults remaining in specific low-level
parts of the kernel (TLB, cache handling, handwritten
assembly, boot code). These parts are thoroughly manually
reviewed." and "From C code to binary code, we employ a
set of automated widely-used verification tools. These
are: SONOLAR, Z3, Isabelle/HOL, and HOL4."

That looks like the *compiler* isn't formally verified.
It also makes me ask the question as to whether C is
"merely" an intermediate language autogenerated from a
HOL spec.

Having said that, the commercial deployment is certainly
interesting and significant.



Quoted text here. Click to load it

Sorry, life's too short!


Quoted text here. Click to load it

I've seen many such activities since the early 80s, some
of them also based on LCF. They went nowhere.

Site Timeline