Must casting destroy lvalueness?

Thread View: net.lang.c

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by NET-RELAY.ARPA Mon, 20 Oct 1986 22:11

#9618

Author: NET-RELAY.ARPA
Date: Mon, 20 Oct 1986 22:11

26 lines
1662 bytes

I'm relatively new to info-c and don't know if you've had this debate
so just banish me to the archive if you have.

C pedants claim that casting destroys lvalueness.  Their argument is
essentially that they can imagine a machine on which casting forces
the use of a temp so lvalueness is gone.

C users, on the other hand, find they have to program real machines not
hypothetical ones and that almost all of these real machines don't use a 
temp when casting.  For example, a useful and readable way to move a pointer 
through a buffer containing a mixture of objects of different sizes is 

                       ((OBJECT)pointer)++

This construct is disallowed by Harbison's compiler. 

I fear that the C standards committee is going to take away such practical 
constructs and turn production quality C compilers into academic quality 
ones.  Who knows, there may develop a brisk business in C compilers that 
promise NOT to be standard conforming.

How sayeth the C standard committee?  How sayeth the users?

                                                        Regards, Scott

"You can hack any formalism so why not have useful formalisms?"

Re: Must casting destroy lvalueness?

#9642

Author: stephen
Date: Thu, 23 Oct 1986 13:19

21 lines
1173 bytes

I generally use or define caddr_t as the type of a generic pointer, and then
use macros to perform the indicated operations, i.e.:

caddr_t generic_pointer;

#define DATA( p, type ) (*((type *)(p)))
#define SUCC( p, type ) ((p) += sizeof(type))
#define PRED( p, type ) ((p) -= sizeof(type))

a = DATA(p,int);
SUCC(a, int);
b = DATA(p,double);
SUCC(p, double);

In the case of a compiler where the cast in DATA is invalid, an 
alternate formulation can be made.


Stephen Watkins                    UUCP: ihnp4!datacube!stephen
Datacube Inc.; 4 Dearborn Rd.; Peabody, Ma. 01960; 617-535-6644

Re: Generic pointers

#9669

Author: Chris Torek
Date: Tue, 28 Oct 1986 22:44

27 lines
1394 bytes

In article <7800017@datacube> stephen@datacube.UUCP writes:
>I generally use or define caddr_t as the type of a generic pointer, and then
>use macros to perform the indicated operations, i.e.:
>
>caddr_t generic_pointer;
>
>#define DATA( p, type ) (*((type *)(p)))
>#define SUCC( p, type ) ((p) += sizeof(type))
>
>a = DATA(p,int);
>SUCC(a, int);
>b = DATA(p,double);
>SUCC(p, double);

Or, if you want the effect of *(type *)(p)++:

	#define	ACCESS(p, type)	((p) += sizeof (type), (type *)(p)[-1])

		a = ACCESS(p, int);
		b = ACCESS(p, double);

Note that any such mangling of pointer types is inherently machine
dependent.  You can reduce the dependency, but not eliminate it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads