Initializers containing function names

MICPRF at latvax8.lat.oz MICPRF at latvax8.lat.oz
Fri Mar 16 00:22:40 AEST 1990


In article <1990Mar13.174517.14634 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
> In article <383 at latvax8.lat.oz> MICPRF at latvax8.lat.oz writes:
>>My cc compiler complains about illegal initialization if an attempt is
>>made to include a function name in an initializer...
>>
>>int dummy(){};
>>int address = (int) dummy;
>>
>>In the S code this type of thing is embedded in arrays of structures, for
>>the hash tables but the problem seems to come down to the above...
> 
> The problem may be the cast rather than the use of the function name.
> Through what seems to have been an accidental oversight, casts were not
> on the list of compile-time operators in K&R1, and some compilers have
> faithfully perpetuated this mistake.

Many thanks Henry. You got it in one! I wrote a couple of small test
routines and the compiler treats them in a manner completely consistent
with your suggestion. Trouble is I don't know how important it is to
S that the addresses for the functions in the hash tables be stored
in variables of type long. (I used int in my example for the heck of it
as on my machine int and long are both 32 bits and the behaviour was
the same). So I've replaced what was load time initialization with
a subroutine that assigns all the values at run time right at the start.

> 
> (Casting a function pointer to int is also a very machine-dependent
> operation, which may not give meaningful results, but that's a different
> issue.)

Yes you are right, I hadn't thought about this (see above).

> -- 
> MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
> an Operating System.          | uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.lang.c mailing list