>I know, programming languages do not have to obey
English language rules.
>It is just taking me a while to get used to the variant meanings.
>
>
If I recally correctly, the initial suggestion was to add "readonly"
and
"writeonly" as keywords to the language. (This was way back in the
eighties, before the C89 standard was nailed down.) Someway along the
line "writeonly" was dropped and "readonly" was transformed
to "const".
At the time there was a big discussion about this, if I recall correctly
Dennis Richie (the originator of the language) was really upset.
Unfortunately I can't find any references to this debacle right now...
-- Anders
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
PC-Lint with CrossWorks
Started by ●June 7, 2005
Reply by ●June 9, 20052005-06-09
Reply by ●June 9, 20052005-06-09
You are thinking about "noalias must be dropped," and cannot be
reworded,
rephrased, re-introduced ... :-)
At 06:04 AM 6/9/2005, Anders Lindgren wrote:
>If I recally correctly, the initial suggestion was
to add "readonly" and
>"writeonly" as keywords to the language. (This was way back in the
>eighties, before the C89 standard was nailed down.) Someway along the
>line "writeonly" was dropped and "readonly" was
transformed to "const".
>
>At the time there was a big discussion about this, if I recall correctly
>Dennis Richie (the originator of the language) was really upset.
>Unfortunately I can't find any references to this debacle right now...
>
> -- Anders
// richard (This email is for mailing lists. To reach me directly, please
use richard at imagecraft.com)
Reply by ●June 9, 20052005-06-09
The const says it is read only.
The volatile says that every reference must actually be read and not optimized
out.
w..
Lou C wrote:
> Thanks Anders, that did the trick! Apparently,
the volatile keyword must
> override the const keyword since the combination of the two does not make
> sense.
Reply by ●June 9, 20052005-06-09
All, > You are thinking about "noalias must be dropped," and cannot > be reworded, rephrased, re-introduced ... :-) As all compiler implementers know, noalias would be an absolute nightmare for all compiler vendors. No, not that it couldn't be implemented, but because users will misuse it. Picture this in a typical software sweatshop: "Ahh, I can use noalias because it'll make my programs faster and smaller. In fact, if I use it everywhere, I get great code!" The scene a little later... "Shit, it's taken me five days to track this problem down, and it damn well looks like a compiler problem--the little bugger isn't reading what I've written through this pointer and it darn well should, let me tell <my-favorite-compiler-vendor> to get it fixed up". Ring Ring. "Hello? Yes. Ahh, problem. Noalias. Bad read. Corrupted data. Ok, I know what it is, it's your problem, you've told the compiler where a pointer won't point and it does point there. Fix up your program." Brrrr. At this point the customer is pissed at the compiler vendor because he obviously doesn't understand the compiler is broken. And the compiler vendor is pissed at the customer because he obviously doesn't know the implications of using noalias. No amount of conciliation will bring the two together, so you might as well just not implement it and avoid the problem altogether. noalias is just one of these problems. restrict is the same thing--a nightmare. Who said C is a simple, easy language? -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors > At 06:04 AM 6/9/2005, Anders Lindgren wrote: > > >If I recally correctly, the initial suggestion was to add "readonly" > >and "writeonly" as keywords to the language. (This was way > back in the > >eighties, before the C89 standard was nailed down.) Someway > along the > >line "writeonly" was dropped and "readonly" was transformed > to "const". > > > >At the time there was a big discussion about this, if I recall > >correctly Dennis Richie (the originator of the language) was > really upset. > >Unfortunately I can't find any references to this debacle > right now... > > > > -- Anders > > // richard (This email is for mailing lists. To reach me > directly, please use richard at imagecraft.com) > > > > . > > > Yahoo! Groups Links > > > > > > > >
Reply by ●June 9, 20052005-06-09
At 11:52 AM 6/9/2005, Paul Curtis wrote: >.... > >At this point the customer is pissed at the compiler vendor because he >obviously doesn't understand the compiler is broken. And the compiler >vendor is pissed at the customer because he obviously doesn't know the >implications of using noalias. No amount of conciliation will bring the >two together, so you might as well just not implement it and avoid the >problem altogether. Did you peek over my shoulders? I just have someone complaining that our compiler cannot handle array of structs, eventually come to that he has a #define that define the variable name to nothing, hence the syntax error.... >noalias is just one of these problems. restrict is the same thing--a >nightmare. Who said C is a simple, easy language? I do :-) One just needs to understand C :-) > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)
Reply by ●June 10, 20052005-06-10
Paul Curtis wrote:
>As all compiler implementers know, noalias would be
an absolute
>nightmare for all compiler vendors. No, not that it couldn't be
>implemented, but because users will misuse it.
>
>Picture this in a typical software sweatshop:
>
>"Ahh, I can use noalias because it'll make my programs faster and
>smaller. In fact, if I use it everywhere, I get great code!"
>
>The scene a little later...
>
>"Shit, it's taken me five days to track this problem down, and it
damn
>well looks like a compiler problem--the little bugger isn't reading
what
>I've written through this pointer and it darn well should, let me tell
><my-favorite-compiler-vendor> to get it fixed up".
>
>
Laughing right out! Those things really do happend -- a couple of years
ago one of our customers discovered our __task keyword. The keyword will
make the top-level function (e.g. main) smaller by not saving permanent
registers. This guy annotated every single function in his application
with it to make the entire application fit into ROM; when the
application didn't work he demanded that we should "fix" the
compiler...
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.