I think Jim already addressed this, which is basically that this becomes
a matter of personal taste to a certain extent. (Meaning /*LINTED*/
versus (void *).)
One rationale for using (void *) is that it mirrors our use of the
source pointer in these cases -- that is, we are using the source
pointer as an untyped pointer (e.g. mp->b_rptr), so it makes sense to
use an untyped cast ... i.e. void *. It does have the possibility that
it obfuscates the type of the destination pointer, but I think good
programming practice is that you use names such that the type is more or
less obvious -- though I'm *NOT* advocating Hungarian notation.
Anyway, are you happy with the other changes, and can I list you as a
reviewer on the RTI? I want to submit this RTI as soon as possible, as
my advocate has requested this be submitted asap as he wants to avoid
introducing further lint breakage in another putback he's working on. :-)
-- Garrett
Tzongyu Paul Lee wrote:
>
>
> James Carlson 写道:
>> Garrett D'Amore writes:
>>
>>> James Carlson wrote:
>>>
>>>> Garrett D'Amore writes:
>>>>
>>>>> There is a closed version, which includes one closed file fix, at
>>>>>
>>>>> http://jurassic.sfbay/~gd78059/webrev/mblkl
>>>>>
>>
>> "OK" on all the responses.
>>
> I am uncomfortable with some of the (void *) changes, for example,
> closed/uts/common/io/ib/clients/sdpib/sdp_link.c
>
> from
> 102 /* LINTED */
> 103 ipllc = (ipllc_t *)mp->b_rptr;
> 104 ipllc->ipllc_cmd = IP_IOC_RTS_REQUEST;
>
> to
>
> 102 ipllc = (void *)mp->b_rptr;
>
> 103 ipllc->ipllc_cmd = IP_IOC_RTS_REQUEST;
>
> Although (void *) makes lint happy, this change
> greatly dilutes the clarity of a structure pointer which
> gets used immediately to access member fields in that structure.
> I feel that we are bending too much to please the lint checker.
>>
>>>> uts/intel/pcwl/Makefile
>>>>
>>>> 75: remove
>>>>
>>> Huh? You better clarify that one for me.
>>>
>>
>> Instead of actually removing the now-unused LINTTAGS += entry in this
>> one Makefile, you just commented it out. I think it'd be better to
>> remove the line. If anyone really needs it in the future, they'll
>> have to come up with the recipe on their own.
>>
>>
>
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
