Excerpts from Prof Brian Ripley's message of Sun Dec 28 15:03:28 +0100 2008: > Thank you. You do realize that your example is not passing a > NativeSymbolInfo object, don't you? I believe the intention is that you > pass 'sym'.
Yes, I had originally used sym and later changed it to sym$address to verify, that the fix also works for case b) described in the comment above checkValidSymboldId(), namly passing in a pointer to a function. I'm not sure if this is currently a 'supported' method of calling a function, since it is only mentioned in the man page for getNativeSymbolInfo() and not in the .Call() man page. > I'll incoporate the patch once I have worked out an accuracy description > of what it does .... The behavior before the patch is to assume that the head of args is a string. When it is anything else, the call to translateChar() when deriving the function name for the error message fails. Instead of dealing with each possible type, the patch reuses the function name that was returned by resolveNativeRoutine() which in turn calls checkValidSymbolId() (all defined in dotcode.c). If CAR(args) is a string, checkValidSymboldId simply returns and resolveNativeRoutine() copies the name into buf. If CAR(args) is a NativeSymbolInfo object, checkValidSymbolId() recalls itself with the second element of the NativeSymbolInfo object (its address member). Lastly if CAR(args) is a EXTRPTRSXP (the type of the address member of a NativeSymbolInfo object) checkValidSymboldId() extracts the symbol name from the EXTPTRSXP if it is a registered symbol. This is the only loophole. If I where to pass an address to .Call() or .External() which was a "native symbol" but not a "registered native symbol", the buffer holding the function name would never be filled. I'm not sure how to deal with this corner case. One option would be to copy some (un)descriptive like '<Unknwon>' into the buffer. If this is acceptable I can add it and post a revised patch. Greetings from Dortmund Olaf Mersmann ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
