EmbeddedRelated.com
Forums

PC-Lint with CrossWorks

Started by Lou C June 7, 2005
>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.


Beginning Microcontrollers with the MSP430

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) 


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.





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

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) 


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.