Path: utzoo!mnetor!uunet!husc6!hao!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Variable function names
Message-ID: <2045@haddock.ISC.COM>
Date: 21 Dec 87 22:34:58 GMT
References: <973@russell.STANFORD.EDU> <47000027@uxe.cso.uiuc.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 22

In article <47000027@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>[Re generating code at runtime: (*(int (*)())&array[0])()]
>Yes, I really mean it. I can't see why it cannot be specified to be generally
>useful. ... The language specifiers should put it in the language.  Then, if
>a particular machine simply can't do it, their C compiler would be sold with
>[a disclaimer that it isn't full ANSI].

Certainly it's a useful option when the architecture and the operating system
can support it.  It has already been mentioned that this isn't always the
case, so I won't harp on that.  But even if ANSI were only concerned with such
"reasonable" architectures, it is clearly beyond their jurisdiction to try to
specify anything about the result of converting a data pointer to a code
pointer or vice versa.

However, I really don't think you have anything to worry about.  Most likely,
the C compilers on "reasonable" architectures will continue to support such
intersegment casts as a Common Extension.

There is some analogy with the casting of pointer to integer.  Have you seen
what the dpANS says (and doesn't say) about that?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint