BUGFIX: TORTURE.C - Fixes to allow builds with Compaq C

[John Aldridge]

At 11:19 10/07/2001 -0400, Michael Sweet wrote:
>"John E. Malmberg" wrote:
> > ...
> > > First, a C compiler should not error out from passing a pointer of
> > > a different type - such strictness is reserved for C++ compilers... :)
> >
> > The difference is significant, and while it may be possible to tell
> > the C compiler to ignore the issue, I would think that most programmers
> > would want to realize that the what they asked for is obviously not
> > what they wanted.  This shows up when the pointer is passed to a routine.
>
>That's what "warnings" are for...

No... it's an error.  ANSI C says (under Assignment)

"One of the following shall hold... both operands are pointers to qualified 
or unqualified versions of compatible types, and the type pointed to by the 
left hand side has all the qualifiers of the type pointed to by the right."

and then defines argument passing to be "as if by assignment".

>Yes, but until recently C had no "volatile" keyword, and do be honest
>I'd rather have the compiler *not* decide if a pointer should be
>volatile on its own.

> > > Second, the volatile modifier is not supported by most compilers.
> > > It is fairly new so I wouldn't recommend using it until more compilers
> > > support it (and even then you should #define it away if the compiler
> > > doesn't support it)

Um, it's in ANSI C, which dates from 1989 (and was commonly supported 
before that).  That's not very recent.  I haven't seen a compiler which 
didn't support it for many years.

>The volatile keyword was added to allow the compiler to make
>optimizations
>that assume that temporary results of pointer dereferencing won't change
>when the pointer is passed to another function, or that two pointer
>variables might be pointing at the same general area of memory (e.g., an
>implementation of strcpy...)

Are you thinking of the C9X "restrict" qualifier?

> > This would be in any case where the same physical memory location can be
> > referenced by multiple threads or processes.  Failure to do so can result
> > in the compiler missing a change to the value.
>
>The volatile keyword isn't really meant for that; MP issues extend
>well beyond C, which is why you usually use OS mechanisms for
>semaphores, message queues, etc.  All volatile really buys you in
>this case is a mechanism for correctly (not) caching shared global
>variables.

ANSI C says "An object that has volatile-qualified type may be modified in 
ways unknown to the implementation or have other unknown side effects." , 
and, in a footnote, "The volatile declaration may be used to describe an 
object corresponding to a memory-mapped input/output port or an object 
accessed by an asynchronously interrupting function."


-- 
Cheers,
John