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.
arm-gcc: pointer to constant string
Started by ●September 14, 2018
Reply by ●September 14, 20182018-09-14
Reply by ●September 14, 20182018-09-14
On 2018-09-14 David Brown wrote in comp.arch.embedded:> On 14/09/18 14:52, Stef wrote: >> On 2018-09-14 David Brown wrote in comp.arch.embedded: >>> On 14/09/18 11:47, Nils M Holm wrote: >>>> >>>> Yes. K&R II (The C Programming Language, 2nd Ed), says that >>> >>> K&R does not define the C language. It was an approximation to a >>> definition until ANSI (then ISO) made the standard, and has not been >>> relevant for decades. >> >> You must be talking about K&R, Nils Specifically said K&R II. >> That edition has printed "ANSI C" in large capitals on the cover. >> A quote from the preface: >> "This second edition of 'The C Programming Language' describes C >> as defined by the ANSI standard" > > Exactly - it /describes/ the C language defined by the standard. It > does not define the language, or the standard, or give a complete or > accurate set of rules for it. That is what the /standard/ is for. K&R > (all editions) are /tutorials/, not standards or language definitions. > (Equally, the standards are not tutorials, and say as much in their > forewords.) K&R was updated for the second edition to contain much of > what is often incorrectly termed "ANSI C", but it was never expected to > be exact.K&R II is only partly a tutorial, the book itself puts that label only on chapter 1. Appendix A is defenitely meant as a reference manual. But it is presented as a more readable (but less concise) text than the standard (which is "intended foremost for compiler writers" :-) ).>> >> That standard is almost identical to C90 IIRC. And that standard is, >> however old, still relevant. The Keil ARM compiler for instance defaults >> to C90 and you have to specifically enable C99. (and nothing newer if you >> don't want to set it to C++ 2003) >> >> So don't throw out your K&R II just yet! >> I have my copy within an arms reach. ;-) >> > > K&R is considered a "classic" in terms of quality technical writing. It > is not a good book for learning modern C. It is not a good book for > learning embedded programming. It is not a good book to use as a > reference for the details of the C language. It is better than many > others, but it is badly outdated, contains some horrible advice and > examples, is strongly oriented towards command-line Unix software from > the 80's and 90's, which is completely inappropriate for embedded > development, and C is almost always a poor choice for modern day > programming of the sort of tasks targeted in the book.Indeed, if you are new to C (or programming), don't start with K&R II. But if you (must) program in C90, it is a handy reference to have at hand. Much more readable than any standard. But indeed do not expect it to provide all the details.> It is true that many compilers default to C90. That is not an excuse > for using C90 - if you are serious about C development, you should be > using /your/ choice of C standard, not the default from the compiler. > It is an unfortunate reality that some people still have to use > compilers that don't support C99 - that is, obviously, a good reason for > using C90. Other than that, /you/ should choose your version of the > language - and you should choose at least C99 because it lets you write > higher quality software. And if your tool vendor does not support C11 > by now, complain to them. > > The year is 2018. Why anyone would think that a 30 year old tutorial > book is a better choice of reference than the current official standards > is beyond my comprehension. > > So K&R (I or II) is an interesting read, and interesting history - but I > would not consider it a way to learn good embedded C programming, nor > would I consider it a useful reference.'Better' is not the word here. 'better read'?. If you (must) program in C90, K&R II is nice to have at hand, it can answer >90% of your questions. (and >85% for C99 ?) And mostly quicker than going on-line. So still useful in my opinion, but not a definitive and complete reference.> And if you want more readable references then there are plenty available > online. My recommendation (for C and C++) is ><https://en.cppreference.com/>.For the other 10-15% ;-) -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) You've been leading a dog's life. Stay off the furniture.
Reply by ●September 14, 20182018-09-14
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.
Reply by ●September 14, 20182018-09-14
Am 14.09.2018 um 12:26 schrieb David Brown:> On 14/09/18 11:47, Nils M Holm wrote: >> (A2.6) "A string has type 'array of characters' and storage class 'static'." > > No, it is not - not for decades. In C, "string" is defined in 7.1.1 of > the current standard as "A string is a contiguous sequence of characters > terminated by and including the first null character."That is the library definition of "string". The language definition of a string literal is in §6.4.5 which says: # In translation phase 7, a byte or code of value zero is appended to # each multibyte character sequence that results from a string literal # or literals. The multibyte character sequence is then used to # initialize an array of static storage duration and length just # sufficient to contain the sequence. [...] (paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)> In particular, there is /no/ mention of storage class, and strings are > independent of the storage class.Sure, because the library does not care.> A C compiler /can/ implement the call function "foo" in this manner : > > void foo(void) { > char s[STRING_LIT_LENGTH_HELLO]; // On stack > copy_string_literal_from_compressed_storage(&s, > STRING_LIT_IDENTIFIER_HELLO, STRING_LIT_LENGTH_HELLO); > dummy(s); > }No, it can not. The literal in OP's code needs to have static storage duration. Maybe you're confusing it with void foo(void) { char s[] = "hello"; dummy(s); } This will be implemented exactly as you've sketched, but here the programmer explicitly said they wanted an array with automatic storage duration. TL;DR: OP's code is safe, language-wise. Of course, this is comp.arch.embedded, and people do strange things with their silicon and their compilers, so I wouldn't be too surprised if there were a compiler that needed special measures. But ARM has a nice flat address space, so no problem here. Stefan
Reply by ●September 14, 20182018-09-14
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.
Reply by ●September 14, 20182018-09-14
On 14/09/18 18:30, Stef wrote:> On 2018-09-14 David Brown wrote in comp.arch.embedded: >> On 14/09/18 14:52, Stef wrote: >>> On 2018-09-14 David Brown wrote in comp.arch.embedded: >>>> On 14/09/18 11:47, Nils M Holm wrote: >>>>> >>>>> Yes. K&R II (The C Programming Language, 2nd Ed), says that >>>> >>>> K&R does not define the C language. It was an approximation to a >>>> definition until ANSI (then ISO) made the standard, and has not been >>>> relevant for decades. >>> >>> You must be talking about K&R, Nils Specifically said K&R II. >>> That edition has printed "ANSI C" in large capitals on the cover. >>> A quote from the preface: >>> "This second edition of 'The C Programming Language' describes C >>> as defined by the ANSI standard" >> >> Exactly - it /describes/ the C language defined by the standard. It >> does not define the language, or the standard, or give a complete or >> accurate set of rules for it. That is what the /standard/ is for. K&R >> (all editions) are /tutorials/, not standards or language definitions. >> (Equally, the standards are not tutorials, and say as much in their >> forewords.) K&R was updated for the second edition to contain much of >> what is often incorrectly termed "ANSI C", but it was never expected to >> be exact. > > K&R II is only partly a tutorial, the book itself puts that label only > on chapter 1. Appendix A is defenitely meant as a reference manual. But > it is presented as a more readable (but less concise) text than the > standard (which is "intended foremost for compiler writers" :-) ). >When K&R was originally written, there was no C reference document - the nearest was a manual for a Unix C compiler. K&R II was, IIRC, published slightly before ANSI C. I suppose there are really two meanings of the word "reference" here. K&R had a C "reference" in the sense of a list of rules that you could look up things when you want some details about the language - the standards are "references" in the sense that they say how the language is defined. If K&R says one thing, and the C standards say another, then the C standards are - by definition - correct for the C language. (I agree that the C standards are not particularly readable. I have got quite familiar with them over the years, but I still get caught out occasionally.)>>> >>> That standard is almost identical to C90 IIRC. And that standard is, >>> however old, still relevant. The Keil ARM compiler for instance defaults >>> to C90 and you have to specifically enable C99. (and nothing newer if you >>> don't want to set it to C++ 2003) >>> >>> So don't throw out your K&R II just yet! >>> I have my copy within an arms reach. ;-) >>> >> >> K&R is considered a "classic" in terms of quality technical writing. It >> is not a good book for learning modern C. It is not a good book for >> learning embedded programming. It is not a good book to use as a >> reference for the details of the C language. It is better than many >> others, but it is badly outdated, contains some horrible advice and >> examples, is strongly oriented towards command-line Unix software from >> the 80's and 90's, which is completely inappropriate for embedded >> development, and C is almost always a poor choice for modern day >> programming of the sort of tasks targeted in the book. > > Indeed, if you are new to C (or programming), don't start with K&R II. > But if you (must) program in C90, it is a handy reference to have at > hand. Much more readable than any standard. But indeed do not expect > it to provide all the details. >Again, I agree the standards are not readable - they are more for specialists, pedants, nerds and compiler writers (I think there is a fair overlap between these groups - with myself in the middle). To be honest, I don't know what books would make a good starter or a good reference (in the readable sense) for modern C programmers. I haven't needed a book on the C language - not since I read K&R some three decades ago.> >> It is true that many compilers default to C90. That is not an excuse >> for using C90 - if you are serious about C development, you should be >> using /your/ choice of C standard, not the default from the compiler. >> It is an unfortunate reality that some people still have to use >> compilers that don't support C99 - that is, obviously, a good reason for >> using C90. Other than that, /you/ should choose your version of the >> language - and you should choose at least C99 because it lets you write >> higher quality software. And if your tool vendor does not support C11 >> by now, complain to them. >> >> The year is 2018. Why anyone would think that a 30 year old tutorial >> book is a better choice of reference than the current official standards >> is beyond my comprehension. >> >> So K&R (I or II) is an interesting read, and interesting history - but I >> would not consider it a way to learn good embedded C programming, nor >> would I consider it a useful reference. > > 'Better' is not the word here. 'better read'?. If you (must) program in > C90, K&R II is nice to have at hand, it can answer >90% of your questions. > (and >85% for C99 ?) And mostly quicker than going on-line. So still useful > in my opinion, but not a definitive and complete reference. > >> And if you want more readable references then there are plenty available >> online. My recommendation (for C and C++) is >> <https://en.cppreference.com/>. > > For the other 10-15% ;-) > >
Reply by ●September 14, 20182018-09-14
On 14/09/18 19:57, Stefan Reuther wrote:> Am 14.09.2018 um 12:26 schrieb David Brown: >> On 14/09/18 11:47, Nils M Holm wrote: >>> (A2.6) "A string has type 'array of characters' and storage class 'static'." >> >> No, it is not - not for decades. In C, "string" is defined in 7.1.1 of >> the current standard as "A string is a contiguous sequence of characters >> terminated by and including the first null character." > > That is the library definition of "string". The language definition of a > string literal is in §6.4.5 which says: > > # In translation phase 7, a byte or code of value zero is appended to > # each multibyte character sequence that results from a string literal > # or literals. The multibyte character sequence is then used to > # initialize an array of static storage duration and length just > # sufficient to contain the sequence. [...] > > (paragraph 5 in ISO 9899:1999, paragraph 6 in n1548)Yes, I know the difference between a string and a string literal - I said that in a bit you snipped. And the library definition of a "string" /is/ the C definition of "string". The term is italicised in 7.1.1, denoting that it is defined in that paragraph.> >> In particular, there is /no/ mention of storage class, and strings are >> independent of the storage class. > > Sure, because the library does not care. > >> A C compiler /can/ implement the call function "foo" in this manner : >> >> void foo(void) { >> char s[STRING_LIT_LENGTH_HELLO]; // On stack >> copy_string_literal_from_compressed_storage(&s, >> STRING_LIT_IDENTIFIER_HELLO, STRING_LIT_LENGTH_HELLO); >> dummy(s); >> } > > No, it can not. The literal in OP's code needs to have static storage > duration. >I know that's what the OP's code needs in order to be correct - the question is if the C standards guarantee that his code does what he wants.> Maybe you're confusing it with > > void foo(void) { > char s[] = "hello"; > dummy(s); > } >No, I am not.> This will be implemented exactly as you've sketched, but here the > programmer explicitly said they wanted an array with automatic storage > duration.I know what the programmer wants, and I know what the programmer wrote. I know that with the compiler the programmer is using, the code he wrote does what he wants. The question is if that behaviour is guaranteed by the C standards, or is merely the most practical implementation in most cases. I cannot say for sure, but I believe the C standards do not guarantee the desired behaviour - I believe an implementation would be allowed to give the kind of implementation I described.> > > TL;DR: OP's code is safe, language-wise.Can you back that up with references to the standard?> > Of course, this is comp.arch.embedded, and people do strange things with > their silicon and their compilers, so I wouldn't be too surprised if > there were a compiler that needed special measures. But ARM has a nice > flat address space, so no problem here. >I would be surprised to see an implementation - especially on an ARM - which did not work the way the OP wants. A quick check with gcc on the AVR (where the string data would have to be copied from flash to ram) shows it works there too. Perhaps someone would like to check it on other AVR C compilers, or more awkward processors.
Reply by ●September 14, 20182018-09-14
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.
Reply by ●September 14, 20182018-09-14
On 9/14/18 6:26 AM, David Brown wrote:> In particular, for the ARM it would > be very strange for a compiler to do anything that would not involve > having the string literal at a fixed place in read-only flash.I can easily think of cases where the string would not be accessed from Read-Only flash on the ARM, the simplest is a system where the program was stored in a non-execute-in-place media, and was copied by some from of loader into RAM. The string would then exist in RAM, not flash, and while it may not be enforced 'Read Only' the program (unless it has performed UB) is not going to invalidate the string.
Reply by ●September 15, 20182018-09-15
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?