[AD] [ alleg-Bugs-3143062 ] [PATCH] Fix al_get_standard_path on OS X

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #3143062, was opened at 2010-12-23 09:58
Message generated for change (Comment added) made by jeffconnelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3143062&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Mac OSX
Group: 4.9
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jeff Connelly (jeffconnelly)
Assigned to: Peter Hull (peterhull90)
Summary: [PATCH] Fix al_get_standard_path on OS X

Initial Comment:
On the Mac OS X port of Allegro, al_get_standard_path(ALLEGRO_EXENAME_PATH) is unreliable. It first tries to get the path from argv[0] if it is absolute, otherwise it tries to search $PATH for argv[0]. The launching program can specify anything for argv[0], so this method is unreliable, and it will crash if argv[0] is null (for example, if al_run_main() is called from a wrapper library without a valid argc/argv):

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 41440]
0x000000000035f2fa in osx_get_path (id=<value temporarily unavailable, due to optimizations>) at /Users/jeff/Downloads/allegro-5.0.0rc3/src/macosx/system.m:662
662	            if (__crt0_argv[0][0] == '/') {

The comments ask if this code should use getprogname() instead, but the function you're looking for is _NSGetExecutablePath(). It simplifies the code considerably, removing the need to search $PATH, and works regardless of whatever was passed in argv[0]. 

Attached patched is against Allegro5.0.0rc3.

----------------------------------------------------------------------

Comment By: Jeff Connelly (jeffconnelly)
Date: 2010-12-23 19:41

Message:
The changes committed to the 5.1 branch work great. But if the call returns
0, ans will remain nil. It is possible to recover from this case. From
<http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/dyld.3.html>:
" This function returns 0 if the path was successfully
     copied.  It returns -1 if the buffer is not large enough, and *
bufsize is set to the size required.
     Note that _NSGetExecutablePath() will return "a path" to the
executable not a "real path" to the exe-
     cutable.  That is, the path may be a symbolic link and not the real
file. With deep directories the
     total bufsize needed could be more than MAXPATHLEN."


----------------------------------------------------------------------

Comment By: Peter Wang (tjaden)
Date: 2010-12-23 15:45

Message:
Thanks! I added some missing error checking, but I don't have a Mac so it
would be good if you could confirm that it is okay.  The patch is currently
on the 5.1 branch only.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3143062&group_id=5665