On Thursday, June 19, 2003, at 01:57 PM, [EMAIL PROTECTED] wrote:This is because you want to explicity allocate memory for the string which MetaCard can use and dispose of. A string constant is allocated locally in your external and could potentially make bad things happen when MetaCard tries to read from that spot in memory (or dispose of the memory).
It may be the case that the memory is dealt with so quickly that the risk is small with such a small return value, but you could potentially get into trouble by way of bad luck, platform differences, and/or the size of the return value.
Most likely MetaCard checks for NULL, in which case this is ok- but if Metacard is expecting a pointer, it's more "correct" to give it one. If the engine were to try to read from that pointer after you set it to NULL, it could crash your app.
All this is doing is creating an empty string: strings are terminated with a NULL byte, so the 1 byte is just the "end-of-string" marker with no string data before it
Yennie, & List:
I have the Hypercard Script Language Guide, and Appendix A is about writing Externals.
At first I was put off because the call interface seems to be different in RR externals than inHypercard XCMD/XFCNs: there used to be an XCmdPtr structure, but now it's a more explicit interface (args, nargs, retstring, pass, error).
Upon looking closer, the rest of the Appendix seems to more or less match up with what I'm seeing in the external.c demo stack. Lo and behold, I guess this is the oft referred to API for externals!!
Here is a note about the question above. (p.510) "Storing a result string is optional for an XCMD; it is expected of an XFCN, but it's not required." If that still holds true then it's OK to return NULL from xcommand/functions?
Question: How literally should I take the stuff in Appendix A of Hypercard Script Language Guide? Any areas where RR is known to have made a big departure from this original specification of how externals are meant to be written?
Alex Rice, Software Developer Architectural Research Consultants, Inc. http://ARCplanning.com
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
