Re: controversial fix or some errors breaking LINT

On Wed, 27 Feb 2002, Julian Elischer wrote: > ok so I leave it to other people to fix LINT > I'm not going near it any more > > one small example: > > ../../../dev/ie/if_ie.c:1471: warning: passing arg 1 of pointer to > function discards qualifiers from pointer target type > ../../../dev/ie/if_ie

Re: controversial fix or some errors breaking LINT

On Wed, 27 Feb 2002, Matthew Dillon wrote: > :/* > : * 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

Re: controversial fix or some errors breaking LINT

* Peter Wemm <[EMAIL PROTECTED]> [020227 15:44] wrote: > Alfred Perlstein wrote: > > * Matthew Dillon <[EMAIL PROTECTED]> [020227 14:51] wrote: > > > > > > : > > > :ok so I leave it to other people to fix LINT > > > :I'm not going near it any more > > > > > > It's the responsibility of whoev

Re: controversial fix or some errors breaking LINT

Peter Wemm wrote: > Alfred Perlstein wrote: > > * Matthew Dillon <[EMAIL PROTECTED]> [020227 14:51] wrote: > > > > > > : > > > :ok so I leave it to other people to fix LINT > > > :I'm not going near it any more > > > > > > It's the responsibility of whoever added -Werror to the default > > >

Re: controversial fix or some errors breaking LINT

In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : does bus-space have a bzero? Effectively yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: controversial fix or some errors breaking LINT

sure.. does bus-space have a bzero? On Wed, 27 Feb 2002, Warner Losh wrote: > In message Garance A Drosihn writes: > : How philosophically sickening would it be to create a macro: > : > : #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) > > How abou

Re: controversial fix or some errors breaking LINT

In message Garance A Drosihn writes: : How philosophically sickening would it be to create a macro: : : #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) How about just using bus_space in these drivers? That's the right solution and isn't too hard to d

Re: controversial fix or some errors breaking LINT

I presume then that you also feel that allowing bcopy to copy volatile regions is a bad idea? On Wed, 27 Feb 2002, Peter Wemm wrote: > Alfred Perlstein wrote: > > * Matthew Dillon <[EMAIL PROTECTED]> [020227 14:51] wrote: > > > > > > : > > > :ok so I leave it to other people to fix LINT > >

Re: controversial fix or some errors breaking LINT

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 bcop

Re: controversial fix or some errors breaking LINT

On Wed, Feb 27, 2002 at 03:15:09PM -0800, Peter Wemm wrote: > If there are files that are too hard to fix, or vendor files, or the fix > isn't clear, we should use the nowerror conf/files* flags. > > It is important that we stop new warnings turning up when the compile > output is so damn large t

Re: controversial fix or some errors breaking LINT

Alfred Perlstein wrote: > * Matthew Dillon <[EMAIL PROTECTED]> [020227 14:51] wrote: > > > > : > > :ok so I leave it to other people to fix LINT > > :I'm not going near it any more > > > > It's the responsibility of whoever added -Werror to the default > > compile to unbreak the tree, ei

Re: controversial fix or some errors breaking LINT

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

Re: controversial fix or some errors breaking LINT

>No. Leave it in, this will benifit us all in the long run. Until we start hitting the broken/buggy warnings, which will cause people to write more obfuscated or harder to maintain code in order to avoid the warnings. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe fre

Re: controversial fix or some errors breaking LINT

* Matthew Dillon <[EMAIL PROTECTED]> [020227 14:51] wrote: > > : > :ok so I leave it to other people to fix LINT > :I'm not going near it any more > > It's the responsibility of whoever added -Werror to the default > compile to unbreak the tree, either by fixing the problem or by > b

Re: controversial fix or some errors breaking LINT

: :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. -Matt To U

Re: controversial fix or some errors breaking LINT

ok so I leave it to other people to fix LINT I'm not going near it any more one small example: ../../../dev/ie/if_ie.c:1471: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1480: warning: passing arg 1 of pointer to function disc

Re: controversial fix or some errors breaking LINT

:/* : * 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. : */ :voidbcopy __P((volati

controversial fix or some errors breaking LINT

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. the problem is that it uses "bcopy()" to do this, and tha