Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28013
| Subject | Re: arm-gcc: pointer to constant string |
|---|---|
| Newsgroups | comp.arch.embedded |
| References | (4 earlier) <pngf4m$7rf$1@dont-email.me> <OSPmD.228814$fy.67599@fx26.am4> <pngiio$u9f$1@dont-email.me> <QsSmD.477867$zc1.1328@fx10.am4> <pngv64$i5b$1@dont-email.me> |
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
| Message-ID | <_iUmD.204351$Os.171913@fx35.am4> (permalink) |
| Organization | virginmedia.com |
| Date | 2018-09-14 20:51 +0100 |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web