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 1 of 4  [1] 2 3 4  Next page →

#27996 — arm-gcc: pointer to constant string

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

[toc] | [next] | [standalone]

#27997

On 14/09/18 09:50, pozz wrote:
> --- 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)?

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.

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

#28001

Il 14/09/2018 11:18, David Brown ha scritto:
> On 14/09/18 09:50, pozz wrote:
>> --- 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)?
> 
> 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.

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


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

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

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

#28002

On 14/09/18 13:05, pozz wrote:
> Il 14/09/2018 11:18, David Brown ha scritto:
>> On 14/09/18 09:50, pozz wrote:
>>> --- 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)?
>>
>> 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.
> 
> 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);
> }

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.

> 
> 
>> 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.
> 
> Again the solution should be to explicitly declare objects as static.

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.

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

#27998

pozz <pozzugno@gmail.com> wrote:
> --- 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()?

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

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


-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

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

#27999

On 14/09/18 11:47, Nils M Holm wrote:
> pozz <pozzugno@gmail.com> wrote:
>> --- 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()?
> 
> 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.  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.

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

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.


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

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

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

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

#28003

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"

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
creator received $4000 down ... and $3000 across.

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

#28004

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.

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

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

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

#28005

On 14/09/18 15:04, David Brown wrote:
> 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.
> 
>>
>> 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.
> 
> 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/>.

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.

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

#28006

On 14/09/18 16:48, Tom Gardner wrote:
> On 14/09/18 15:04, David Brown wrote:
>> 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.
>>
>>>
>>> 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.
>>
>> 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/>.
> 
> 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.
> 
> 

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.

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

#28008

On 14/09/18 16:02, David Brown wrote:
> On 14/09/18 16:48, Tom Gardner wrote:
>> On 14/09/18 15:04, David Brown wrote:
>>> 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.
>>>
>>>>
>>>> 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.
>>>
>>> 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/>.
>>
>> 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.
>>
>>
> 
> 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.

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



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

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.

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

#28010

On 14/09/18 19:45, Tom Gardner wrote:
> On 14/09/18 16:02, David Brown wrote:
>> On 14/09/18 16:48, Tom Gardner wrote:
>>> On 14/09/18 15:04, David Brown wrote:
>>>> 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.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> 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/>.
>>>
>>> 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.
>>>
>>>
>>
>> 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.
> 
> Don't forget the commercially important /subsets/! The need
> for subsets is a warning flag in itself.
> 

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.

> 
> 
>> 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.
> 
> That statement, while correct, skims over a significant problem:
> unfortunately too few people understand and can /predict/ what is
> valid and invalid.

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?

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

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

#28013

On 14/09/18 19:37, David Brown wrote:
> On 14/09/18 19:45, Tom Gardner wrote:
>> On 14/09/18 16:02, David Brown wrote:
>>> On 14/09/18 16:48, Tom Gardner wrote:
>>>> On 14/09/18 15:04, David Brown wrote:
>>>>> 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.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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/>.
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>> 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.
>>
>> Don't forget the commercially important /subsets/! The need
>> for subsets is a warning flag in itself.
>>
> 
> What need of "commercially important subsets" are you talking about?

MISRA-C, for example.


> 
> There /are/ compilers that implement subsets of C standards.  But I don't see a 
> /need/ for them.
> 
>>
>>
>>> 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.
>>
>> That statement, while correct, skims over a significant problem:
>> unfortunately too few people understand and can /predict/ what is
>> valid and invalid.
> 
> 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?

You miss my point.

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

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

#28020

On 14/09/18 21:51, Tom Gardner wrote:
> On 14/09/18 19:37, David Brown wrote:
>> On 14/09/18 19:45, Tom Gardner wrote:
>>> On 14/09/18 16:02, David Brown wrote:

<snip>

>>>> 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.
>>>
>>> Don't forget the commercially important /subsets/! The need
>>> for subsets is a warning flag in itself.
>>>
>>
>> What need of "commercially important subsets" are you talking about?
> 
> MISRA-C, for example.

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.

> 
> 
>>
>> There /are/ compilers that implement subsets of C standards.  But I 
>> don't see a /need/ for them.
>>
>>>
>>>
>>>> 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.
>>>
>>> That statement, while correct, skims over a significant problem:
>>> unfortunately too few people understand and can /predict/ what is
>>> valid and invalid.
>>
>> 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?
> 
> You miss my point.

Not unlikely!

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

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?

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

#28023

On 15/09/18 15:24, David Brown wrote:
> On 14/09/18 21:51, Tom Gardner wrote:
>> On 14/09/18 19:37, David Brown wrote:
>>> On 14/09/18 19:45, Tom Gardner wrote:
>>>> On 14/09/18 16:02, David Brown wrote:
> 
> <snip>
> 
>>>>> 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.
>>>>
>>>> Don't forget the commercially important /subsets/! The need
>>>> for subsets is a warning flag in itself.
>>>>
>>>
>>> What need of "commercially important subsets" are you talking about?
>>
>> MISRA-C, for example.
> 
> That is a set of rules for C, rather than a subset as such.  

That's hairsplitting, which obscures rather than illuminates.


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

Nonsense.


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

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



>>> There /are/ compilers that implement subsets of C standards.  But I don't see 
>>> a /need/ for them.
>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>> That statement, while correct, skims over a significant problem:
>>>> unfortunately too few people understand and can /predict/ what is
>>>> valid and invalid.
>>>
>>> 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?
>>
>> You miss my point.
> 
> Not unlikely!
> 
>>
>> I am not arguing about the /differences/ between, say C99 and C11,
>> but C of /any/ standard.
> 
> 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?

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.

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

#28027

On 16/09/18 02:28, Tom Gardner wrote:
> 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!).

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.

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

#28028

On 16/09/18 04:58, Clifford Heath wrote:
> On 16/09/18 02:28, Tom Gardner wrote:
>> 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!).
> 
> 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).

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?

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

#28029

On 16/09/18 08:42, Tom Gardner wrote:
> On 16/09/18 04:58, Clifford Heath wrote:
>> On 16/09/18 02:28, Tom Gardner wrote:
>>> 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!).
>>
>> 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).
> 
> 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?

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

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

#28030

On 16/09/18 17:42, Tom Gardner wrote:
> On 16/09/18 04:58, Clifford Heath wrote:
>> On 16/09/18 02:28, Tom Gardner wrote:
>>> 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!).
>>
>> 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).
> 
> 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?

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.

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

#28031

On 16/09/18 11:18, Clifford Heath wrote:
> On 16/09/18 17:42, Tom Gardner wrote:
>> On 16/09/18 04:58, Clifford Heath wrote:
>>> On 16/09/18 02:28, Tom Gardner wrote:
>>>> 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!).
>>>
>>> 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).
>>
>> 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?
> 
> It it too hard for you to type "sel4" into Google?

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


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

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.



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

Sorry, life's too short!


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

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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web