Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!garry
From: garry@batcomputer.tn.cornell.edu (Garry Wiegand)
Newsgroups: comp.lang.c
Subject: canonical values - an amenity
Message-ID: <1542@batcomputer.tn.cornell.edu>
Date: Wed, 19-Nov-86 13:58:46 EST
Article-I.D.: batcompu.1542
Posted: Wed Nov 19 13:58:46 1986
Date-Received: Thu, 20-Nov-86 08:20:42 EST
Reply-To: garry%cadif-oak@cu-arpa.cs.cornell.edu.arpa
Organization: Cornell Engineering && Flying Moose Graphics
Lines: 42

The new C incipient-spec has a primitive datatype called "void *". It has
the property that a pointer of any type cast to (void *) and back again
is guaranteed to emerge unharmed.

I use this heavily to pass pointers (to structures) through utility routines
which do not know what type of pointer is coming down, and back again to
action routines which *do* know what type is coming.

What I would like is to be able to do the same thing with *any* kind of
(primitive) value, not merely pointer values!!! (Why do things half-way 
in the language ??)

On many/most machines, "unknown" (somebody was brain-damaged when they
overloaded the word "void"!) would be equivalent to:

	(unknown)char ->    (double)char
	(unknown)pointer -> (double)(long)pointer
	(unknown)short ->   (double)short
	(unknown)long ->    (double)long
	(unknown)int ->     (double)int
	(unknown)float ->   (double)float

I can get away with this because doubles almost always have more
precision in them than any of the other datatypes. I can't
#define "unknown" as "double" because (unknown)pointer will break
on many (broken) compilers. It can't be (double)(long) because
(unknown)float will break. So I need it as a primitive. Ideally
it would just be a 64-bit bitmask internally rather than a double,
to avoid unnecessary conversions.

A fringe benefit is that I can declare *actual variables* to be of
type "unknown", and so avoid having to play with unions of {int, char,
float, double, void *}. 

Tests for equality should still work. Tests for ordering (<, >) would 
work easily on a doubles-implementation but might be tough on bitmasks.

Yah, I know I'm too late. Can I at least have (double)pointer not break,
pleeez? Does the spec already say that (double)pointer is as legit as
and equivalent to (double)(long)(void *)pointer ??

garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)