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.

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) 

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

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.

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) 

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

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

Well, to me they do -- but I guess it's because I read "const" as
"read 
only".

In fact, if you take a look at the IO header files that are provided by 
your compiler then chanses are that all read-only IO ports are declared 
as "const volatile". (Well, if you're using our compiler then
they are.)

    -- Anders Lindgren, IAR Systems

-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Lou, 

> I guess I thought "const" meant it was a
constant, not that 
> it was read-only.

Const is a qualifier that prohibits the client from changing it.  THAT
DOES NOT MEAN THAT ITS VALUE DOES NOT CHANGE!  I wrote the caps and I
meant it.  It is a common misconception that something declared
"const"
in some way is non-changing.  This is NOT the case.  Consider:

void change_through_ptr(int *x)
{
  *x = 99;
}

void take_some_ptrs(int *x, const int *y)
{
  printf("*x = %d, *y = %d\n, *x, *y);
  change_through_ptr(x);
  printf("*x = %d, *y = %d\n, *x, *y);
}

void main(void)
{
  int q = 22;
  take_some_ptrs(&q, &q);
}

This will print:

22 22
99 99

Although y points to something that take_some_ptrs cannot change,
changing *x will also change *y.  This is valid C.  Thus something
"const" means "you can't write that here" not that
"you can never write
it and it'll never change".

>  Your definition makes it all clear now how 
> things work.  
> However, I can't help but say this use of const really is not 
> grammatically correct in the English language sense.  

It's inherited from C++ into ANSI C IIRC.  It's just over-use of
the
some new keyword, like the lexical element 0 is overworked in C.

> I mean 
> const implies constant and if something is a constant, it 
> cannot change.

ANSI C++ allows you to optimize out something declared "const" if
the
const is global and has an initializer as its value truly can never
change (modulo errors).

> It could have an initial value, but would 
> always maintain that value throughout execution of the program.  
> In that sense, a const value could literally be read from 
> program FLASH since it is always a constant.  The book from 
> which I learned C says, "const is used to inform the compiler 
> that the value of the variable that follows it may not be 
> changed except for an initialization."  

In some cases it's right.  In most cases that's wrong.

> So, a volatile const 
> would not make sense, hence my response.  So it looks like 
> "const volatile" 
> is really saying "read-only varying value".

The const is used as a qualifier that inadvertently stops you writing
somewhere.  It is no more than that.

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

Wait until you get on to C++ mutable and then figure out whether C++ in
all its forms is a neat language...

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

On Wed, 08 Jun 2005 12:21:31 -0500, Lou wrote:

>>Why ever do you think that it doesn't make
sense to have a const
>>volatile?  volatile means "you need to re-read this after sequence
>>points" and const means "you can't write to that". 
const volatile >>"this is a read-only thing that changes beyond the
compiler's view of
>>the world".  As you were reading P1IN, it makes absolute sense that
it
>>is const volatile underneath the hood.  sfrb and sfrw automatically
>>infer volatility, hence a const sfrb is a non-writable volatile object.
>>This is exactly what you need for P1IN (for instance).
>
>I guess I thought "const" meant it was a constant, not that it was

>read-only.  Your definition makes it all clear now how things work.  
>However, I can't help but say this use of const really is not
grammatically 
>correct in the English language sense.  I mean const implies constant and if

>something is a constant, it cannot change.  It could have an initial value, 
>but would always maintain that value throughout execution of the program.  
>In that sense, a const value could literally be read from program FLASH 
>since it is always a constant.

>  <above text remains for context>

>The book from which I learned C says,
>
>   "const is used to inform the compiler that the
>    value of the variable that follows it may not
>    be changed except for an initialization."
>
>So, a volatile const would not make sense, hence my response.

If you read Paul's comment and the above comment closely, you will
find them _possibly_ congruent.  The issue is that "the book" you
mention fails a little on completeness.  Perhaps it could have said:

>   "const is used to inform the compiler that
the
>    value of the variable that follows it may not
>    be changed __by compiler generated code where
>    this declaration is visible_ except for an
>    initialization."

That may have made it more pointed.

Jon

>Why ever do you think that it doesn't make sense to have a const
>volatile?  volatile means "you need to re-read
this after sequence
>points" and const means "you can't write to that". 
const volatile >"this is a read-only thing that changes beyond the
compiler's view of
>the world".  As you were reading P1IN, it makes absolute sense that it
>is const volatile underneath the hood.  sfrb and sfrw automatically
>infer volatility, hence a const sfrb is a non-writable volatile object.
>This is exactly what you need for P1IN (for instance).

I guess I thought "const" meant it was a constant, not that it was 
read-only.  Your definition makes it all clear now how things work.  
However, I can't help but say this use of const really is not grammatically

correct in the English language sense.  I mean const implies constant and if 
something is a constant, it cannot change.  It could have an initial value, 
but would always maintain that value throughout execution of the program.  
In that sense, a const value could literally be read from program FLASH 
since it is always a constant.  The book from which I learned C says,
"const 
is used to inform the compiler that the value of the variable that follows 
it may not be changed except for an initialization."  So, a volatile const 
would not make sense, hence my response.  So it looks like "const
volatile" 
is really saying "read-only varying value".

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.

Lou