Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2002 15:14:52 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        FreeBSD current users <current@FreeBSD.ORG>
Subject:   Re: controversial fix or some errors breaking LINT
Message-ID:  <Pine.BSF.4.21.0202271508230.97278-100000@InterJet.elischer.org>
In-Reply-To: <p05101410b8a31356bb54@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help

It's not my problem as jhb has volunteered to fix all these.
:-)

we just add an entry point for bcopy_volatile()
next to that for bcopy.
(I called it vbcopy in my suggestion.)
bzero has the same thing 
bzero_volatile() I guess.

Though I still feel that it breaks POLA to not be able to use 
bcopy and bzero.



On Wed, 27 Feb 2002, Garance A Drosihn wrote:

> At 1:27 PM -0800 2/27/02, Julian Elischer wrote:
> >There are saveral places (e.g. if_ie.c) where data
> >is copied out of a buffer that is shared with the hardware.
> >
> >The pointer to this is correctly labelled as "volatile", though
> >at the time we will copy the data out we know it to be stable.
> 
> Note:   "at the time we will copy the data ... we know"
> 
> >A while ago I proposed the following patch:
> >
> >/*
> >  * Note: the "volatile" below does not REQUIRE that the argument be
> >  * volatile, but rather ony says that it is OK to use a volatile * i
> >  * there. Same for the const. I know a const volatile sounds strange
> >  * but it only indicates that either is acceptable.
> >  */
> >void    bcopy __P((volatile const void *from, volatile void *to,
> >            size_t len));
> 
> This will always allow bcopy to do the copy to or from any volatile
> location, even if the call is done at a bad time.  Any programmer
> calling bcopy should at least get a little flag waved at them if
> they are working with volatile arguments.
> 
> How philosophically sickening would it be to create a macro:
> 
> #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y)
> 
> so that you can have cleaner-looking source code, but still have
> it so the programmer has to *explicitly* say "Yes, I know I am
> dealing with volatile memory here".
> 
> -- 
> Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
> Senior Systems Programmer           or  gad@freebsd.org
> Rensselaer Polytechnic Institute    or  drosih@rpi.edu
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202271508230.97278-100000>