Address of array

[Peter Curran]

Relay-Version: version B 2.10.1 6/24/83; site ecr1.UUCP
Path: ecr1!ecrhub!hcrvax!utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris at umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <422 at umcp-cs.UUCP>
Date: Fri, 21-Mar-86 07:04:26 EST
Date-Received: Tue, 25-Mar-86 04:33:12 EST
References: <750 at abic.UUCP> <211 at dg_rtp.UUCP> <685 at steinmetz.UUCP> <58 at paisley.ac.uk>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 53

Chris Torek writes (in reply to Robert Hamilton's reply to Wayne Throop):
> I think you missed the point.  Suppose you write the following:
> 
> 	#include "../projlib/types.h"
> 
> 	x_type	variable;
> 
> 	f()
> 	{
> 		g(&variable);
> 		...
> 	}
> 
> 	g(p)
> 		x_type *p;
> 	{
> 		x_type newvalue;
> 
> 		...
> 		*p = newvalue;
> 		...
> 	}
> 
> This looks perfectly reasonable, and works quite well if `x_type'
> is a name for a simple type, a structure, or a union.  It does not
> work---indeed, it does not even compile---if `x_type' is a name
> for an array.  The problem is that you are not `allowed' to know
> just what `x_type' really is.
> 
> As it turns out, it is not often useful to write something like
> the above if `x_type' is a name for an array, and this problem does
> not seem to come up in practice---or at least I have not seen it.
> And if all else fails one can always wrap the array in a structure:
> 
> 	typedef struct {
> 		int	x_val[10];
> 	} x_type;

This situation does occur - in connection with longjmp/setjmp.
The functions are passed a variable of type 'jmp_buf'.  In fact,
the functions expect an address.  With most compilers, 'jmp_buf'
is an array, and naming it produces an address.  On a few compilers,
the 'jmp_buf' is a structure (which makes more sense), but you must
pass its address (i.e. using the '&' operator).  One more portability
hiccup.
-- 

Peter Curran
Emerald City Research, Ltd.
...utzoo!ecrhub!ecr1!peterc