Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28037
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: arm-gcc: pointer to constant string |
| Date | 2018-09-16 22:06 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <pnmd4r$3h8$1@dont-email.me> (permalink) |
| References | (9 earlier) <_iUmD.204351$Os.171913@fx35.am4> <pnj4m9$ep8$1@dont-email.me> <3ranD.175206$_V.125892@fx32.am4> <pnlk5e$ntf$1@dont-email.me> <7ZsnD.408545$%L2.113927@fx15.am4> |
On 16/09/18 15:33, Tom Gardner wrote: > On 16/09/18 14:00, David Brown wrote: >> On 15/09/18 18:28, Tom Gardner wrote: >>> 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. >> >> It is no different than programming in Forth, Ada, Python, Fortran, or >> any other language. What makes you think C is special? >> >>> >>> >>>> (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. >> >> You haven't read the Misra rules, have you? I didn't mention that the >> remaining 10% of the rules go against the C standards and compiler >> norms by inventing their own non-standard type system. I suppose that >> /does/ mean it counts as another type of C, but it is certainly not a >> standard one. > > If the type system is a valid use of C, then it is no more > non-standard than libraries that aren't defined in the standard. > Unfortunately, MISRA's idea of "essential types" is not /quite/ compatible with actual C. I have forgotten the details (and they may vary between MISRA versions), but there are points in which the MISRA rules say code should do something that is different from what the C rules say. I have seen at least one case where a (massively expensive) compiler generated code regarding integer promotions that was "MISRA correct" but not "C standards correct". > > >>>> 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. >> >> I think you'll find it applies to /all/ programming languages. For >> some languages, there is enough consensus in these "subsets" and >> enough popularity of them that they are known popularly - like SPARK >> and MISRA. For others, they will be smaller. If company guidelines >> say that when programming Python you must use capital letters for >> class names and never write "from module import *", then you have a >> subset of the language just as surely as if they say "use MISRA for C". > > I think most people would look askance at that being an informative > definition of "subset" - and would instantly think to look at what's > being concealed. > > >>> 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!). >>> >> >> I know that is SPARK's objective. Most sets of guidelines or coding >> standards aim towards more reliable and less error-prone coding >> (though few aspire to claiming they can be provably correct). > > Agreed. > > Overall I'm not a fan of formal proofs except in a few very > niche applications. The proofs always have hard (in multiple > senses) boundaries which exclude important real-world problems. There are few cases where formal proofs are worth the time and costs involved. But I like - when possible - to write my code with a view that a formal proof /could/ be made if someone were to go to the effort. It is rare that you could prove a whole program - but not uncommon that you could (if you wanted to) prove many of the functions involved. Thinking in terms of pre-conditions, invariants, post-conditions, variants, specifications - that is all good stuff for writing solid code, even if you don't do so formally. > > >>>>>> 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)! >> >> I think I see what you are getting at now - you are saying there are >> things in C that are undefined (or implementation-defined) that many C >> programmers don't realise are a problem. Yes, I can agree with that - >> though I think the problem is often overrated. The great majority of >> undefined behaviour in C is obviously undefined because there is no >> sensible definition for it - and there is no way anyone could >> reasonably expect code to "work". That applies to things like buffer >> overruns, out of bounds pointers, etc. The most obvious category of >> undefined behaviours where people get things wrong are, I would say, >> accessing data through incompatible pointers and signed integer >> overflow. In the case of signed integer overflow, the code is almost >> certainly wrong regardless of any definition of the behaviour. >> >> The rest is just a matter of not knowing the language as well as they >> should, and thus getting things wrong. That happens in all languages. >> >> I am not in any way saying that C or C++ are perfect languages, or >> that their standards are ideal, or anything like that. I am merely >> saying they are not as bad as many people make out, and not different >> in principle from other languages. > > There are no perfect languages, and probably cannot be. > > However, some languages are significantly more/less > imperfect in practical use than others. > > Overall C has expanded until its rough edges have become > part of the problem rather than part of the solution. Once > it really was the best language for many purposes - but we > have learned Better Techniques in the past 40 years. Certainly I do not think C is the best choice of language for many of the types of use it is put to. I think most people who program in C would be more productive and write more correct code in other languages - and most programs that are written in C would be better written in other languages. > > Cs position is firm for the same reason than COBOL's position > is firm: history, familiarity and weight of existing code. Those are undoubtedly reasons for choosing C in many cases. But C is still the best choice for many purposes - and sometimes the only "choice".
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