Xref: utzoo comp.sys.mac.hypercard:333 comp.sys.mac:12294
Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!nrl-cmf!ames!lll-tis!lll-lcc!pyramid!voder!apple!tomas
From: tomas@apple.UUCP (Tom Taylor)
Newsgroups: comp.sys.mac.hypercard,comp.sys.mac
Subject: Re: HyperCard XFCNs in MPW C
Message-ID: <7360@apple.UUCP>
Date: 9 Feb 88 01:25:07 GMT
References: <226STORKEL@RICE> <3105@watcgl.waterloo.edu>
Reply-To: tomas@apple.UUCP (Tom Taylor)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 87

In article <3105@watcgl.waterloo.edu> kdmoen@watcgl.waterloo.edu (Doug Moen) writes:
>In article <226STORKEL@RICE> STORKEL@RICE.BITNET (Scott Storkel) writes:
>>Help! I am trying to compile a Hypercard XFCN written in MPW C. The program
>>compiles fine, then I try to link it using the following commands:
>>     
>>      link -sn Main=Bool -sn STDIO=Bool:
>>           -sn INTENV=Bool -rt XFCN=5:
>>           -m BOOL Boolean.c.o "{CLibraries}"CRuntime.o:
>>           "{CLibraries}"CInterface.o:
>>           "{CLibraries}"StdCLib.o:
>>           "{CLibraries}"CSANELib.o:
>>           -o HyperCommands
>>     
>>When I  do this, the compiler gives me the error "Data initialization code is
>>not being called" and terminates. The output file contains the XFCN resources
>>Bool=5, and also SADEV=6, SACONSOL=7, and CSANELIB=8.
>
>You can't have global variables *or character string literals* in
>an XFCN written in MPW C.
>
>Boy was I pissed off when I figured this out.
>I don't know of any reasonable workarounds, either.
>
>Some kludges for faking string literals:
>* You can put them into STR# resources
>* You can use the following C function that I invented:
>
>	strlit(p, s)
>	char *p;
>	{
>		strcpy(p, (char *)&s);
>		return p;
>	}
>
>Now you can replace character string literals like:
>	"foobar"
>with:
>	char buf[256];
>	...
>	strlit(buf, 'foob','ar\0\0');
>
>Both kludges are really pretty awful, but I have no better ideas right
>now except to write a preprocessor for stripping out string literals
>and replacing them with something that the linker won't choke on.
>
>By the way, you can't put global variables or string literals into
>INITs, desk accessories, and related code resources, either.
>
>Does anybody at Apple care enough to fix this?
>-- 
>Doug Moen
>University of Waterloo Computer Graphics Lab
>UUCP:     {ihnp4,watmath}!watcgl!kdmoen
>INTERNET: kdmoen@cgl.waterloo.edu

Here is a way, though not elegant, to put string literals in the
code of a standalone resource.  Basically, you put the string literals
in an assembly file with DC.B.  Each string must be declared in a
PROC statement.  On the C side, declare the strings as extern char *stringname.
When linking as a standalone code resource, the linker knows to force
all references to the string as code-to-code references, and so does not
use the jump table.

Example:

In ASM:

stringFoo	PROC	EXPORT
	DC.B	'This is a string'
	ENDPROC
	END

In C:

extern char *stringFoo;

NOTE: the link order is important... the C file with the code must
      appear in the link list before the asm file with the data.  The
      reason is that most routines that call these code resources simply
      load the resource and jump to the beginning.

This is not pretty.  I still recommend putting strings in resources.
The 3.0 C compiler has an option to put constants and strings at the
end of the code so that these problems will disappear.

Tom Taylor
Development Systems Group