tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: why cast to char* through void*
[Greg Wbods]
> [Thor Lancelot Simon]
>> I think more often than not, a cast to (char *) in the modern era
>> where we have (void *) as a generic pointer is in fact likely to be
>> intentional and safe -- it indicates the programmer really, *really*
>> wanted bytewise access to the structure in question.
>> I think this is almost certainly why the pointer-aliasing rules, in
>> fact, make a special exception for (char *), and so I think lint
>> should, too.
> I understand the lint warning as being valid for different reasons.
> I.e. here we really are mixing fundamentally incompatible data types
> in the same storage object (though it's not a true storage object in
> the sense of being associated with a basic type). Normally I think
> this would be considered to be "A BAD Thing". Lint really is right
> to warn.
I think there are two fundamentally conflicting philosophies at
loggerheads here.
Thor is right from what I might characterize as C's original target: an
implementation languages for things, such as the low levels of
operating systems, where type-unsafe operations such as bytewise access
to structures, or treating pointers as the bit patterns that make them
up, are fundamentally necessary.
Greg is right from a very different perspective: the high-level one,
the one appropriate when neither the program nor the programmer cares
(or, ideally, knows) the underlying representation of any or the types.
Modern C comes close to being suitable for both purposes (pretty
astoundingly so, in view of how strongly at odds with one another they
are, I'd say). However, they _are_ fundamentally at odds, and taking
either of them to its logical conclusion - or even just to the point of
a really good language for that purpose - will wreck it for the other.
I think it's a mistake to try.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index