Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: increment casted void pointer  --  ANSI?
Message-ID: <1991Mar27.101020.19979@thunder.mcrcim.mcgill.edu>
Date: 27 Mar 91 10:10:20 GMT
Article-I.D.: thunder.1991Mar27.101020.19979
References: <4142@rwthinf.UUCP> <1991Mar8.165300.11692@zoo.toronto.edu> <288@nazgul.UUCP>
Organization: McGill Research Centre for Intelligent Machines
Lines: 26

In article <288@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes:
> The usual to do a 'type paint', which is to change the type of an
> object without changing the bit pattern, is to:
> 	*(newtype *)&(object)
> It's not perfect, i.e. strict ANSI compilers won't let you do this on
> an lvalue

*except* on an lvalue, I hope you meant.  (Actually, it's something
more like "addressable lvalues" - I don't know the precise wording.)
And you may get garbage when you indirect the resulting pointer.

> and it doesn't work on constants,

They aren't lvalues; you can't apply & to anything but an lvalue.

> but it usually gets the job done

Many not-fully-portable tricks are nevertheless perfectly useful.  Such
a construction is to be discouraged, but not necessarily interdicted
entirely....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu