lkml.org 
[lkml]   [2002]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] C undefined behavior fix
Date
> -----Original Message-----
> From: Laurent Guerby [mailto:guerby@acm.org]
> Sent: Sunday, January 06, 2002 2:41 PM
> To: dewar@gnat.com
> Cc: paulus@samba.org; gcc@gcc.gnu.org; linux-kernel@vger.kernel.org;
> trini@kernel.crashing.org; velco@fadata.bg
> Subject: Re: [PATCH] C undefined behavior fix
>
>
> dewar@gnat.com wrote:
>
> > pragma Atomic in Ada (volatile gets close in C, but is not
> close enough) will
> > ensure a byte store in practice, but may not ensure byte reads.
>
>
> I see no distinction between read and write in the text of
> the Ada standard.
>
> Also I think if you declare a byte array with Atomic_Component
> and Volatile_Component and that the compiler accepts it for its
> target architecture, then the compiler is required to generate
> a byte read and store for each occurence in the text source.
> From C.6:
>
> 15 For an atomic object (including an atomic component)
> all reads and
> updates of the object as a whole are indivisible.
>
> 16 For a volatile object all reads and updates of the object as a
> whole are
> performed directly to memory.
>
> 20 {external effect (volatile/atomic objects) [partial]}
> The external
> effect of a program (see 1.1.3) is defined to include each read and
> update of
> a volatile or atomic object. The implementation shall not
> generate any
> memory
> reads or updates of atomic or volatile objects other than
> those specified by
> the program.
>
> In my exemple byte array, if I say X := T (I) I don't see how
> a conformant
> compiler accepting the declaration could generate anything other than
> one and exactly one byte read. Per 20 it has no right to read
> T (I+1) or
> T(I-1)
> since they are "other" objects (components to be pedantic).

It seems to me that you are right, but there is other cases; for example:
X := T(0)*256 + T(1);
compiled on a big endian architecture may well generate just one 16-bit word
read...

Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.048 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site