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      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index