strong/weak typing and pointers

[Steven Bethard]

Alex Martelli <aleaxit <at> yahoo.com> writes:
> 
> I apologize if I have given the impression of being upset.

No problem -- my mistake for misinterpreting you.  I'm just sensitive to these
kind of things because I know I've previously miscommunicated, and
unintentionally got people upset before (you being one of them). ;)

> I am, in a
> way, I guess -- astonished and nonplusses, as if somebody asked me to
> justify the existence of bread -- not of some exotic food, mind you, but
> of the most obvious, elementary, fundamental substance of earthly
> sustenance (in my culture, and many others around it).

Yeah, this goes to the heart of the misunderstanding.  I'm not asking anyone to
justify the _existence_ of weak-typing.  Weak-typing is a direct result of a
language's support for untyped (bit/byte) data.  I agree 100% that this sort of
data is not only useful, but often essential in any low-level (e.g. OS, hardware
driver, etc.) code.

> So, we have an area
> of 8 bytes in memory which we need to be able to treat as:
>     8 bytes, for I/O purposes, say;
>     a float, to feed it to some specialized register, say;
>     a bit indicating sign plus 15 for mantissa plus 48 for significand,
>         or the like, to perform masking and shifting thereof in SW -- a
>         structure of three odd-bit-sized integers juxtaposed;

As a quick refresher, I quote myself in what I was looking for:
"taking advantage of weak-typing would be a case where you treat the bits as
three different things: the sequence of bits, and two (mutually exclusive)
intended structures."

My response to this example is that your two intended structures are not
mutually exclusive.  Yes, you have to do some bit-twiddling, but only because
your float struct doesn't have get_sign, get_mantissa and get_significand
methods.  ;)  You're still dealing with the same representation, not converting
to a different type.  You're just addressing a lower level part of the
representation.

I can see the point though: at least in most of the languages I'm familiar with,
float is declared as a type while there's no subtype of float that specifies the
sign, mantissa and significand.
 
(Oh, and by the way, in case you really were wondering, they still do teach
float representations, even in computer science (as opposed to computer
engineering), or at least they did through 1999.)

> Another example: we're going to send a controlblock of 64 bytes to some
> HW peripheral, and get it back perhaps with some mods -- a typical
> control/status arrangement.  Depending on the top 2 (or in some case 4)
> bytes' value, the structure may need to be interpreted in several
> possible ways, in terms of juxtaposition of characters, halfwords and
> longwords.  Again, the driver responsible for talking with this
> peripheral needs to be able to superimpose on the 64 bytes any of
> several possible C-level struct's -- the cleanest way to do this would
> appear to be pointer-casting, though unions would (as usual, of course)
> be essentially equivalent.

Is the interpretation of the controlblock uniquely defined by the top 2 or 4
bytes, or are there some values for the top 2 or 4 bytes for which I have to
apply two different interpretations (C-level structs) to the same sequence of 
bits?

If the top 2 or 4 bytes uniquely define the structs, then I would just say
you're just going back and forth between a typed structure and its untyped
representation.  If the top 2 or 4 bytes can specify multiple interpretations
for the same sequence of bits, then this is the example I was looking for. =)

Steve