What is the meaning of this warning, and how do I get rid of it?

[James H. Newman]

I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

the compiler issues the following warning:

warning: passing arg 1 of `f' discards qualifiers from pointer target type

What does this exactly mean? How do I change my code so that the
compiler is happy about it?

[Mark McIntyre]

James H. Newman wrote:

I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

the compiler issues the following warning:

warning: passing arg 1 of `f' discards qualifiers from pointer target type

What does this exactly mean?

It means you're discarding the "volatile" qualifier.

How do I change my code so that the

compiler is happy about it?

don't use volatile?

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Walter Roberson]

In article <g5**********@registered.motzarella.org>,
James H. Newman <Ne******@exicite.comwrote:

I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

>When I do

unsigned int z = f(&x) ;

>the compiler issues the following warning:

>warning: passing arg 1 of `f' discards qualifiers from pointer target type

What does this exactly mean?

x is volatile, so &x is a pointer to a volatile variable. However,
the receiving function is prototyped for non-volatile and so is not
going to know to preserve volatile semantics.

How do I change my code so that the
compiler is happy about it?

You could prototype f with y being volatile. Or you could create a
new non-volatile variable, initialize that with x's current value,
send that to f and store the modified result after f into x. However,
if x happens to be a memory-mapped I/O register or the like, or happens
to be set by a signal processing routine, then that probably won't
give you are result you want.
--
Current spam load: 750-800 messages per day (March 4, 2008)

[santosh]

James H. Newman wrote:

I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

the compiler issues the following warning:

warning: passing arg 1 of `f' discards qualifiers from pointer target
type

It means what it says. Since 'f' is prototyped as taking an unsigned
char *, the volatile qualifier of 'x' is discarded when it is passed
to 'f'. Also note that the expression &x is actually of type volatile
unsigned char ** - not the type that you want to be passing to 'f'.

What does this exactly mean? How do I change my code so that
the compiler is happy about it?

Prototype and define 'f' as:

unsigned int f(volatile unsigned char *y) { /* ... */ }

If 'f' needs to change the caller's copy of it's argument then you
probably want:

unsigned int f(volatile unsigned char **y) { /* ... */ }

[Raymond Martineau]

On Sat, 12 Jul 2008 03:45:17 +0530, santosh <sa*********@gmail.com>
wrote:

>James H. Newman wrote:

> I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

[...]

>
If 'f' needs to change the caller's copy of it's argument then you
probably want:

unsigned int f(volatile unsigned char **y) { /* ... */ }

That would require x to be a pointer. Currently, it's simply an
unsigned char.

[Barry Schwarz]

On Sat, 12 Jul 2008 03:45:17 +0530, santosh <sa*********@gmail.com>
wrote:

>James H. Newman wrote:

> I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

the compiler issues the following warning:

warning: passing arg 1 of `f' discards qualifiers from pointer target
type

It means what it says. Since 'f' is prototyped as taking an unsigned
char *, the volatile qualifier of 'x' is discarded when it is passed
to 'f'. Also note that the expression &x is actually of type volatile
unsigned char ** - not the type that you want to be passing to 'f'.

Where did the double asterisks come from? There is only one & and x
is not a pointer.
Remove del for email

[Ron Ford]

On Fri, 11 Jul 2008 22:15:12 +0000 (UTC), Walter Roberson posted:

In article <g5**********@registered.motzarella.org>,
James H. Newman <Ne******@exicite.comwrote:

> I have a portion of code along the following
lines:

> volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

>>When I do

> unsigned int z = f(&x) ;

>>the compiler issues the following warning:

>>warning: passing arg 1 of `f' discards qualifiers from pointer target type

> What does this exactly mean?

x is volatile, so &x is a pointer to a volatile variable. However,
the receiving function is prototyped for non-volatile and so is not
going to know to preserve volatile semantics.

>How do I change my code so that the
compiler is happy about it?

You could prototype f with y being volatile. Or you could create a
new non-volatile variable, initialize that with x's current value,
send that to f and store the modified result after f into x. However,
if x happens to be a memory-mapped I/O register or the like, or happens
to be set by a signal processing routine, then that probably won't
give you are result you want.

A question for you, Walter.

Since C is completely safe, why does one use the 'volatile' function
specifier?
--
Temptation is a woman's weapon and man's excuse.
H. L. Mencken

[Ian Collins]

Ron Ford wrote:

>
Since C is completely safe, why does one use the 'volatile' function
specifier?

Who says C is completely safe?

volatile is a variable qualifier. It can not be applied to a function.

volatile tells the compiler not to optimise access to a variable. The
value of a volatile variable may be changed by an external source (a
hardware register for example).

--
Ian Collins.

[santosh]

Raymond Martineau wrote:

On Sat, 12 Jul 2008 03:45:17 +0530, santosh <sa*********@gmail.com>
wrote:

>>James H. Newman wrote:

>> I have a portion of code along the following
lines:

volatile unsigned char x ;
unsigned int f(unsigned char *y) ;

When I do

unsigned int z = f(&x) ;

[...]

>>
If 'f' needs to change the caller's copy of it's argument then you
probably want:

unsigned int f(volatile unsigned char **y) { /* ... */ }

That would require x to be a pointer. Currently, it's simply an
unsigned char.

Sorry, I made a mistake. I deserve it for posting at 03:45!

[Walter Roberson]

In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

>A question for you, Walter.

>Since C is completely safe, why does one use the 'volatile' function
specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".
--
"Product of a myriad various minds and contending tongues, compact of
obscure and minute association, a language has its own abundant and
often recondite laws, in the habitual and summary recognition of
which scholarship consists." -- Walter Pater

[Ron Ford]

On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:

In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

>>A question for you, Walter.

>>Since C is completely safe, why does one use the 'volatile' function
specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is "volatile" to be
opposed to that which is "safe." I've never used this qualifier in my own
code.

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
..... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

I'm not really any closer than a half hour ago. What is the difference
between type specifiers and type qualifiers?
--
Time stays, we go.
H. L. Mencken

[rahul]

On Jul 14, 10:27*am, Ron Ford <[e-mail]:

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." *

Generally volatile is used in embedded system programming. Just a
hypothetical code:

#define READY 0x01
volatile char *mem = 0x1234; /*reading from some memory-mapped device.
When device is ready, it writes READY here
*assume initially it is not READY. */
/* some code */

while (READY != *mem) {
continue; /* busy waiting */
}

If it is not declared as volatile, the compiler may read the value
only once and the while loop becomes an infinite loop.

[Keith Thompson]

Ron Ford <ro*@nowhere.netwrites:

On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:

>In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

>>>A question for you, Walter.

>>>Since C is completely safe, why does one use the 'volatile' function
specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is
"volatile" to be opposed to that which is "safe." I've never used
this qualifier in my own code.

The English meaning of the term doesn't tell you much about what it
means in C. "volatile" is not the opposite of "safe" in this context.

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

The same applies to writes as well as reads.

I'm not really any closer than a half hour ago. What is the difference
between type specifiers and type qualifiers?

The latest draft of the standard is at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
It defines both terms, in 6.7.2 and 6.7.3, respectively.

The type specifiers are void, char, short, int, long, and so forth.

The type qualifiers are const, restrict, and volatile (restrict is new
in C99).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Nick Keighley]

On 14 Jul, 08:46, Keith Thompson <[e-mail]:

Ron Ford <[e-mail]:

On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:

In article <x367lnt93ys$[e-mail]>,
Ron Ford <[e-mail]:

>>A question for you, Walter.

>>Since C is completely safe, why does one use the 'volatile' function
specifier?

since when has C been "completely safe". What does it mean?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole.

I think you need a new dictionary. You seem to be using non-standard
meanings for "safe", "volatile" and "hyperbole"

I think of that which is
"volatile" to be opposed to that which is "safe."

why do you think this?

I've never used this qualifier in my own code.

nor me

The English meaning of the term doesn't tell you much about what it
means in C. "volatile" is not the opposite of "safe" in this context.

"volatile" isn't the opposite of "safe" in English either!

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

if you wanted to know what volatile meant in C why didn't
you just ask that?

<snip>

--
Nick Keighley

"Resistance is futile. Read the C-faq."
-- James Hu (c.l.c.)

[CBFalconer]

Keith Thompson wrote:

Ron Ford <ro*@nowhere.netwrites:

.... snip ...

>

>So I spent some time with K&R, thinking I would there find the
reason to use the "volatile." Instaed I find §A8.2 in the
footnote: "the const and volatile properties are new with the
ANSI standard. The purpose of const .... The purpose of
volatile is to force an implementation to suppress optimization
that could otherwise occur...."

If a program reads the value of a variable, and the compiler is
able to determine what its current value happens to be, it can
generate code that doesn't actually load the variable's value.
For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have
been. If x were qualified with "volatile", it would not be
permitted to perform that optimization.

However this doesn't explain the necessity for volatile. If, for
example, that memory location holds the 'ready' status for data on
a peripheral, code is going to have to wait for the signal to
become true. Without the volatile it would read the signal once,
and then just remain in the testing loop, because it knows the
answer. With volatile, the system is forced to reread the ready
status on each pass through the loop.

Volatile means "something other than this code can alter this
value".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[santosh]

CBFalconer wrote:

Keith Thompson wrote:

>Ron Ford <ro*@nowhere.netwrites:

... snip ...

>>

>>So I spent some time with K&R, thinking I would there find the
reason to use the "volatile." Instaed I find §A8.2 in the
footnote: "the const and volatile properties are new with the
ANSI standard. The purpose of const .... The purpose of
volatile is to force an implementation to suppress optimization
that could otherwise occur...."

If a program reads the value of a variable, and the compiler is
able to determine what its current value happens to be, it can
generate code that doesn't actually load the variable's value.
For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have
been. If x were qualified with "volatile", it would not be
permitted to perform that optimization.

However this doesn't explain the necessity for volatile. If, for
example, that memory location holds the 'ready' status for data on
a peripheral, code is going to have to wait for the signal to
become true. Without the volatile it would read the signal once,
and then just remain in the testing loop, because it knows the
answer. With volatile, the system is forced to reread the ready
status on each pass through the loop.

Volatile means "something other than this code can alter this
value".

I remember a long thread on the exact semantics of volatile in
comp.std.c and there were some interesting discussions.

<http://groups.google.com/group/comp.std.c/browse_frm/thread/a1fc78b30424f8c5/35480a3974c5e831>
<http://groups.google.com/group/comp.std.c/browse_frm/thread/d0ab34c579b23a32/24cfd852741d242a>

[vippstar]

On Jul 14, 8:27 am, Ron Ford <[e-mail]:

On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:

In article <x367lnt93ys$[e-mail]>,
Ron Ford <[e-mail]:

>A question for you, Walter.

>Since C is completely safe, why does one use the 'volatile' function
specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is "volatile" to be
opposed to that which is "safe." I've never used this qualifier in my own
code.

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

<snip>
Here's a "real world" example, though not valid C.

volatile unsigned char *memory = (void *)0xDEADBEEFUL;
*memory = 'H';
*memory 'I';

The compiler could optimize this to *memory = 'I' if 'volatile' was
not present.

[Ron Ford]

On Mon, 14 Jul 2008 14:43:05 +0530, santosh posted:

CBFalconer wrote:

>Keith Thompson wrote:

>>Ron Ford <ro*@nowhere.netwrites:

... snip ...

>>>
So I spent some time with K&R, thinking I would there find the
reason to use the "volatile." Instaed I find §A8.2 in the
footnote: "the const and volatile properties are new with the
ANSI standard. The purpose of const .... The purpose of
volatile is to force an implementation to suppress optimization
that could otherwise occur...."

If a program reads the value of a variable, and the compiler is
able to determine what its current value happens to be, it can
generate code that doesn't actually load the variable's value.
For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have
been. If x were qualified with "volatile", it would not be
permitted to perform that optimization.

However this doesn't explain the necessity for volatile. If, for
example, that memory location holds the 'ready' status for data on
a peripheral, code is going to have to wait for the signal to
become true. Without the volatile it would read the signal once,
and then just remain in the testing loop, because it knows the
answer. With volatile, the system is forced to reread the ready
status on each pass through the loop.

Volatile means "something other than this code can alter this
value".

I remember a long thread on the exact semantics of volatile in
comp.std.c and there were some interesting discussions.

<http://groups.google.com/group/comp.std.c/browse_frm/thread/a1fc78b30424f8c5/35480a3974c5e831>
<http://groups.google.com/group/comp.std.c/browse_frm/thread/d0ab34c579b23a32/24cfd852741d242a>

These made great reading. It's been years since I've read Dan Pop.

I went through the standard, looking where volatile enters the ballgame,
and it's in a lot of places and a lot of footnotes. I would claim that it
is one of those things that you cannot *learn* from the standard; you must
antecedently know.

The fact that I have to ask leaves me to believe that I have no use for the
'volatile' function qualifier. I had hoped that things I didn't know about
'volatile' would enlighten things I didn't know about the function
specifier 'fortran', but not so.
--
All men are frauds. The only difference between them is that some admit it.
I myself deny it.
H. L. Mencken

[Ron Ford]

On Mon, 14 Jul 2008 00:46:14 -0700, Keith Thompson posted:

Ron Ford <ro*@nowhere.netwrites:

>On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:

>>In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

A question for you, Walter.

Since C is completely safe, why does one use the 'volatile' function
specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is
"volatile" to be opposed to that which is "safe." I've never used
this qualifier in my own code.

The English meaning of the term doesn't tell you much about what it
means in C. "volatile" is not the opposite of "safe" in this context.

>So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

This is a somewhat abstract point here. Can one restate this in terms of
*external* functions that might be called?

>
The same applies to writes as well as reads.

>I'm not really any closer than a half hour ago. What is the difference
between type specifiers and type qualifiers?

The latest draft of the standard is at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
It defines both terms, in 6.7.2 and 6.7.3, respectively.

The type specifiers are void, char, short, int, long, and so forth.

The type qualifiers are const, restrict, and volatile (restrict is new
in C99).

Of which type was register?

I looked at §6.7.2 and the next and am confident that this is beyond my
experience.
--
I confess I enjoy democracy immensely. It is incomparably idiotic, and
hence incomparably amusing.
H. L. Mencken

[santosh]

Ron Ford wrote:

<snip>

The fact that I have to ask leaves me to believe that I have no use
for the 'volatile' function qualifier. [ ... ]

Qualify an object as volatile when you want to be sure that writes and
reads to it actually happen according to the abstract semantics of C.
If you need atomicity too, you can further use the sig_atomic_t
qualifier, though that everely restricts the guaranteed range of the
object.

<snip>

[Ben Bacarisse]

Ron Ford <ro*@nowhere.netwrites:

On Mon, 14 Jul 2008 00:46:14 -0700, Keith Thompson posted:

<snip>

>If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

This is a somewhat abstract point here. Can one restate this in terms of
*external* functions that might be called?

I think you need to restate your question (printf and puts are
external functions). What is it about Keith Thompson's example that
needs restating?

--
Ben.

[Keith Thompson]

Ron Ford <ro*@nowhere.netwrites:

On Mon, 14 Jul 2008 00:46:14 -0700, Keith Thompson posted:

>Ron Ford <ro*@nowhere.netwrites:

>>On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:
In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

>A question for you, Walter.

>Since C is completely safe, why does one use the 'volatile' function
>specifier?

I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is
"volatile" to be opposed to that which is "safe." I've never used
this qualifier in my own code.

The English meaning of the term doesn't tell you much about what it
means in C. "volatile" is not the opposite of "safe" in this context.

>>So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

This is a somewhat abstract point here. Can one restate this in terms of
*external* functions that might be called?

Not usefully. What makes you think that external functions would make
this clearer, or that "volatile" and external functions are related to
each other?

[...]

>The latest draft of the standard is at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
It defines both terms, in 6.7.2 and 6.7.3, respectively.

The type specifiers are void, char, short, int, long, and so forth.

The type qualifiers are const, restrict, and volatile (restrict is new
in C99).

Of which type was register?

Neither. "register" is a storage-class specifier, as are typedef,
extern, static, and auto (C99 6.7.1). ("typedef" is treated as a
storage-class specifier only for syntactic convenience; it doesn't
actually specify a storage class.)

A type specifier specifies what type you're using (int vs. double,
etc.).

A type qualifier gives you additional information about a type,
usually something that applies to a specific object (it can't be
modified, for example).

A storage-class specifier (other than typedef) specifies the storage
class of a declared entity (its lifetime and, in an abstract sense,
where it's stored).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ron Ford <ro*@nowhere.netwrites:
[...]

The fact that I have to ask leaves me to believe that I have no use
for the 'volatile' function qualifier. I had hoped that things I
didn't know about 'volatile' would enlighten things I didn't know
about the function specifier 'fortran', but not so.

What is a "function qualifier"? "volatile" is a *type qualifier*.
It's typically applied to objects, not to functions.

You *could* declare something like:

volatile int func(void) { ... }

but it wouldn't make sense; the "volatile" would just be ignored.

Or you could declare:

volatile int *another_func(void) { ... }

but that means that another_func returns a pointer to volatile int; it
applies to the object that the result points to, not to the function.

I think that much of your confusion stems from your incorrect
assumption that "volatile" is for functions.

As for "fortran", that's a non-standard extension. It's listed under
"Common extensions" in C99 J.5, but I haven't actually seen a compiler
that supports it. Here's what the standard says about it:

The fortran function specifier may be used in a function
declaration to indicate that calls suitable for FORTRAN should be
generated, or that a different representation for the external
name is to be generated (6.7.4).

But this is in a non-normative section of the standard.

If you want to know about a non-standard "fortran" keyword, you'll
have to consult the documentation of whatever compiler supports it --
and be aware that it's not at all portable.

(The only standard function specifier (not "function qualifier") is
"inline".)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones]

Keith Thompson <ks***@mib.orgwrote:

>
As for "fortran", that's a non-standard extension. It's listed under
"Common extensions" in C99 J.5, but I haven't actually seen a compiler
that supports it.

I have. It meant essentially the same thing as Microsoft's "__stdcall"
does (use the system's standard calling conventions and don't mess with
the function's name), so it was widely used on systems where the
standard calling conventions don't mesh well with C. Why Microsoft
didn't just use it instead of inventing their own name, only they know.
--
Larry Jones

My upbringing is filled with inconsistent messages. -- Calvin

[Ron Ford]

On Tue, 15 Jul 2008 08:31:50 -0700, Keith Thompson posted:

Ron Ford <ro*@nowhere.netwrites:

>On Mon, 14 Jul 2008 00:46:14 -0700, Keith Thompson posted:

>>Ron Ford <ro*@nowhere.netwrites:
On Sat, 12 Jul 2008 13:59:11 +0000 (UTC), Walter Roberson posted:
In article <x3***************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:
>
>>A question for you, Walter.
>
>>Since C is completely safe, why does one use the 'volatile' function
>>specifier?
>
I don't recall ever saying that "C is completely safe". It was
certainly never designed to be "completely safe".

No, I was engaging in hyperbole. I think of that which is
"volatile" to be opposed to that which is "safe." I've never used
this qualifier in my own code.

The English meaning of the term doesn't tell you much about what it
means in C. "volatile" is not the opposite of "safe" in this context.

So I spent some time with K&R, thinking I would there find the reason to
use the "volatile." Instaed I find §A8.2 in the footnote: "the const and
volatile properties are new with the ANSI standard. The purpose of const
.... The purpose of volatile is to force an implementation to suppress
optimization that could otherwise occur...."

If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

This is a somewhat abstract point here. Can one restate this in terms of
*external* functions that might be called?

Not usefully. What makes you think that external functions would make
this clearer, or that "volatile" and external functions are related to
each other?

Well I clearly had notions about volatile that were compleatly wrong. I'm
just going to leave it at as "ensuring that code not be optimized away,"
and think of the above source as illustrative.

>>The latest draft of the standard is at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
It defines both terms, in 6.7.2 and 6.7.3, respectively.

The type specifiers are void, char, short, int, long, and so forth.

The type qualifiers are const, restrict, and volatile (restrict is new
in C99).

Of which type was register?

Neither. "register" is a storage-class specifier, as are typedef,
extern, static, and auto (C99 6.7.1). ("typedef" is treated as a
storage-class specifier only for syntactic convenience; it doesn't
actually specify a storage class.)

A type specifier specifies what type you're using (int vs. double,
etc.).

A type qualifier gives you additional information about a type,
usually something that applies to a specific object (it can't be
modified, for example).

A storage-class specifier (other than typedef) specifies the storage
class of a declared entity (its lifetime and, in an abstract sense,
where it's stored).

That's a lot to keep straight. I wish there was a book on reading the C
standard.
--
Every election is a sort of advance auction sale of stolen goods.
H. L. Mencken

[Ron Ford]

On Tue, 15 Jul 2008 12:57:45 +0100, Ben Bacarisse posted:

Ron Ford <ro*@nowhere.netwrites:

>On Mon, 14 Jul 2008 00:46:14 -0700, Keith Thompson posted:

<snip>

>>If a program reads the value of a variable, and the compiler is able
to determine what its current value happens to be, it can generate
code that doesn't actually load the variable's value. For example:

...
int x = 42;
printf("x = %d\n", x);
...

The compiler can legitimately replace the printf() call with
puts("x = 42");
because it *knows* what the result of evaluating x would have been.

If x were qualified with "volatile", it would not be permitted to
perform that optimization.

This is a somewhat abstract point here. Can one restate this in terms of
*external* functions that might be called?

I think you need to restate your question (printf and puts are
external functions). What is it about Keith Thompson's example that
needs restating?

I thought that volatile would have properties like static, but not so. I
don't seem to be running out of misconceptions on this one, so I'll commit
the above example to memory and be done with it.
--
Archbishop - A Christian ecclesiastic of a rank superior to that attained
by Christ.
H. L. Mencken

[Keith Thompson]

Ron Ford <ro*@nowhere.netwrites:
[...]

Well I clearly had notions about volatile that were compleatly
wrong. I'm just going to leave it at as "ensuring that code not be
optimized away," and think of the above source as illustrative.

[...]

Specifically, volatile inhibits optimizations *related to accessing an
object* (where "accessing" can be either reading or writing). Other
optimizations are generally not affected, except perhaps indirectly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[santosh]

Ron Ford wrote:

[ ... ] I wish there was a book on reading the C standard.

[ ... ]

There are two that I know of. One is the Rationale document for the
current standard published on WG14's website, the other is a *huge* but
interesting book called /The C Standard: An Economic and Social
Commentary/ by Derek Jones, again published by the author on his
website.

<http://www.knosof.co.uk/cbook/cbook.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

[Joachim Schmitz]

santosh wrote:

Ron Ford wrote:

>[ ... ] I wish there was a book on reading the C standard.

[ ... ]

There are two that I know of. One is the Rationale document for the
current standard published on WG14's website, the other is a *huge*
but interesting book called /The C Standard: An Economic and Social
Commentary/ by Derek Jones, again published by the author on his
website.

I won't call a 10 MB pdf file huge. Hmm, hold on: that's 1615 pages! So yes,
it is huge ...

>
<http://www.knosof.co.uk/cbook/cbook.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

Thanks for these usefull URLs!

Bye, Jojo

[santosh]

Joachim Schmitz wrote:

santosh wrote:

>Ron Ford wrote:

>>[ ... ] I wish there was a book on reading the C standard.

[ ... ]

There are two that I know of. One is the Rationale document for the
current standard published on WG14's website, the other is a *huge*
but interesting book called /The C Standard: An Economic and Social
Commentary/ by Derek Jones, again published by the author on his
website.

I won't call a 10 MB pdf file huge. Hmm, hold on: that's 1615 pages!
So yes, it is huge ...

>>
<http://www.knosof.co.uk/cbook/cbook.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

Thanks for these usefull URLs!

And of course the latest edition of Harbison & Steele's /C: A Reference
Manual/ is also a very good companion in interpreting and understanding
the Standard itself.

[Ron Ford]

On Wed, 16 Jul 2008 13:52:15 +0530, santosh posted:

Ron Ford wrote:

>[ ... ] I wish there was a book on reading the C standard.

[ ... ]

There are two that I know of. One is the Rationale document for the
current standard published on WG14's website, the other is a *huge* but
interesting book called /The C Standard: An Economic and Social
Commentary/ by Derek Jones, again published by the author on his
website.

<http://www.knosof.co.uk/cbook/cbook.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

Thanks santosh, I've started picking at the Rationale document. It doesn't
take long to bump into something with the volatile type qualifier:

Such behavior is, of course, too loose for hardware-oriented applications
such as device drivers
and memory-mapped I/O. The following loop looks almost identical to the
previous example,
but the specification of volatile ensures that each assignment to *ttyport
takes place in 20
the same sequence, and with the same values, as the abstract machine would
have done.
volatile short *ttyport;
/* ... */
for (i = 0; i < N; ++i)
*ttyport = a[i];

I know what a device driver is but not memory-mapped IO. Here, the
rationale for volatile sounds different: "ensuring that each assignment ...
takes place in the same sequence."
--
Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
H. L. Mencken

[Ron Ford]

On Thu, 17 Jul 2008 07:36:11 +1000, Mark L Pappin posted:

Ron Ford <ro*@nowhere.netwrites:

>santosh posted:

>>Ron Ford wrote:
I wish there was a book on reading the C standard.

>>There are two that I know of. One is the Rationale document for the
current standard published on WG14's website

>><http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

>Thanks santosh, I've started picking at the Rationale document. It
doesn't take long to bump into something with the volatile type
qualifier:

>Such behavior is, of course, too loose for hardware-oriented
applications such as device drivers and memory-mapped I/O.

(Not a criticism, just emphasizing a point that's been made to several
posters here recently: making some sort of visual distinction in your
post between text you have written and text you have quoted (and
citing your sources) will ease the cognitive load for your readers.
It's best to assume Usenet readers don't see font or color changes, so
conventions involving extra blank lines and attribution marking have
developed over the last few decades to help here.)

Thanks for mentioning this. My quote was from §6.7 of the Rationale doc,
as is the quote that follows. I thought I was doing well to render it as I
did, but quotes from a .pdf doc using the text selection tool appear to
need a good deal of processing, needing a complete overhaul of newlines and
adiosing the numbers as multiples of five that serve as line numbers in the
pdf doc.

With dialog, I can paste as a quote using or a custom quote. How does
this look:

%% A static volatile object is an appropriate model for a memory
%% -mapped I/O register. Implementors of C translators should
%% take into account relevant hardware details on the target systems
%% when implementing accesses to volatile objects. For instance,
%% the hardware logic of a system may require that a two-byte
%% memory-mapped register not be accessed with byte operations;
%% and a compiler for such a system would have to assure that no
%% such instructions were generated, even if the source code only
%% accesses one byte of the register. Whether read-modify-write
%% instructions can be used on such device registers must also be
%% considered. Whatever decisions are adopted on such issues must
%% be documented, as volatile access is implementation-defined. A
%% volatile object is also an appropriate model for a variable
%% shared among multiple processes. --§6.7

If the register is to hold the temperature in the hallway next to my
woodburner, what do "static" and "volatile" do together?

>I know what a device driver is but not memory-mapped IO.

Some machines have special instructions for accessing I/O devices
(e.g. the x86 family), and I/O operations using these are not
"memory-mapped".

Some machines reserve memory addresses such that reads from or writes
to those addresses do not access actual memory, but instead read or
modify the state of other hardware.

This "memory-mapping" of I/O may be defined into the architecture
(e.g. the Microchip PIC series of microcontrollers, with I/O devices
on the chip) or it may be completely independent of the processor
(e.g. the Apple ][ family, with logic on the motherboard or expansion
cards decoding the address lines and tweaking hardware as appropriate
- any access to a specific location toggled the speaker cone, for
instance). Even machines with special I/O instructions may also have
some memory-mapped I/O.

Where 'volatile' comes in handy is in ensuring that the compiler does
not "helpfully" eliminate a read from such a memory location because
it knows what was last read from that location, or eliminate a write
because another write happens a little later and would "overwrite" any
previously-stored value. If, say, there's really a temperature sensor
feeding an ADC behind a "memory" address and a DAC driving a motor
controller behind another, then your program probably won't do as you
intended if it forever sees the temperature as being the same as when
it first read it; and only writing the final-ever requested speed to
your motor controller, at the end of the run, won't make the robot go.

Thanks mlp. I have this fantasy of being able to teach my x86 computer to
fire events based on temperature. The calculus is very simple and involves
two fans and a swamp cooler. One of the fans is next to the woodburner,
and the swamper has 2 switches: one for the motor and one for the pump.
(If you haven't lived somewhere near Albuqerque, you probably have never
experienced evaporitive cooling.)

I'm mudding all the walls, so burying wires to wherever they need to be is
in the cards. Do you have any notion of what hardware/software I would
need to make that a reality?

--
The basic fact about human existence is not that it is a tragedy, but that
it is a bore. It is not so much a war as an endless standing in line.
H. L. Mencken

[CBFalconer]

Mark L Pappin wrote:

Ron Ford <ro*@nowhere.netwrites:

>Mark L Pappin posted:

>>making some sort of visual distinction in your post between text
you have written and text you have quoted (and citing your
sources) will ease the cognitive load for your readers.

With dialog, I can paste as a quote using or a custom quote.
How does this look:

%% A static volatile object is an appropriate model for a memory
%% -mapped I/O register. Implementors of C translators should
%% take into account relevant hardware details on the target
%% systems when implementing accesses to volatile objects.

Looks fine to me, and makes it obvious that the quote has come
from somewhere other than Usenet. There are also arguments for
sticking with '>' (providing you keep attributions/citations
clear).

Actually the arguments against using anything other that '>' are
overwhelming. The point is that most software can recognize the
'>' marker and take appropriate action while reformatting
over-length lines, etc. Odds are greatly against success with any
other marker.

There are similar arguments agains indenting either your quotes or
your additions. The problems don't show up immediately, but do
appear after further requoting. I use indenting for actual
quotation from third parties, i.e. non-usenet messages, and
normally enclose such quotes in quote marks. E.g.:

"This is a third party
quotation. Note the
terminal quote mark.
Also note the revision
of the subject header."

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ron Ford]

On Fri, 18 Jul 2008 12:33:56 +1000, Mark L Pappin posted:

>Thanks mlp. I have this fantasy of being able to teach my x86
computer to fire events based on temperature.

...

>(If you haven't lived somewhere near Albuqerque, you probably have
never experienced evaporitive cooling.)

Grew up in tropical North Queensland - experienced it plenty,
occasionally even via artificial means. And some Aussies have canvas
waterbags strapped to the front of their 4WDs (you'd call them SUVs)
for cold water in hot weather - same principle.

>I'm mudding all the walls, so burying wires to wherever they need to
be is in the cards. Do you have any notion of what
hardware/software I would need to make that a reality?

I do, but discussing it is not appropriate here in comp.lang.c. Talk
to the good folks in comp.arch.embedded for further pointers, or email
me privately for consulting.

mlp

I don't know how to set the follow-up with this client. I'll download MS's
latest C product and fire up your suggestion.

Cordially,
--
To die for an idea; it is unquestionably noble. But how much nobler it
would be if men died for ideas that were true!
H. L. Mencken