volatile

Chris Torek chris at mimsy.UUCP
Wed May 18 12:58:25 AEST 1988


In article <390 at attila.weitek.UUCP> mahar at weitek.UUCP (Mike Mahar) writes:
>Consider the following C program.  Remember this is All the information you
>get.  The actual addresses of variables are unknown. Any other modules 
>are compiled separately.  What you see is all you get.

You have made what can be called an unreasonable restriction.  Why
is the compiler not able to see the other modules?  The only possible
answers are `they do not exist' or `the compiler is not smart enough'.
If they do not exist, there is no problem; if they are later created,
the compiler is expected to be smart enough to see them then.

(All this requires is that you defer code generation until after the
link step.)

[compressed, and with the bug fixed:]
>char fifo;
>buf_fill(char *buffer, int cnt) {
>    int i;
>    for (i = 0; i < cnt; i++) *buffer++ = fifo;
>}

If I as a reader saw this, I might be tempted to rewrite it thus:

	register int i = cnt, fillbyte = fifo;
	while (--i >= 0) *buffer++ = fillbyte;

The compiler may be able to tell whether `fifo' is volatile, but given
the lack of such a declaration or a comment or `#pragma' or any other
clue, *I* may not, so please use something like

	volatile char fifo;

or	char fifo;		/* DANGER : i/o space : volatile : DANGER */

or	char fifo;
	#pragma volatile fifo;
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list