The configure script should check the psinfo struct for compatibility and
not set ALLEGRO_HAVE_SV_PROCFS if it doesn't work. This is obviously
broken somehow.
Anyway,
+ /* The System V way doesn't work on Solaris */
+ #if ((defined(sun) || defined(__sun__)) && defined(__svr4__))
+ s = getexecname();
+ if (s) {
+ do_uconvert (s, U_ASCII, output, U_CURRENT, size);
+ return;
+ }
+ s = NULL;
+ #endif
The comment is misleading - it used to work with older versions of Solaris
as far as I know (I recall checking it when I changed
_unix_get_executable_name()). I no longer have acces to any Solaris system
(safe SourceForge's compile farm) so I can't reconfirm that.
Actually, the
#ifdef ALLEGRO_HAVE_PROCFS_ARGCV
if (_find_executable_file(psinfo.pr_argv[0], output, size))
return;
lines were there specifically for Solaris. I guess we should add a check
for pr_argv being NULL though.
That said, getexecname() looks like a very convenient function to use in
this case! Rather than checking for any of the sun preprocessor directives
(which are unreliable, as I recall) we should have the configure script
check if the function exists - afterall, we don't want to know if we're on
Solaris, but if getexecname() works!
That's sounds better certainly, but I don't know how to do that
:) I don't use configure or the like in any of my personal
projects.
It also seems to me that the BSD's might use this same code section (the System V way)?
I'm a little bit concerned though: the manpage,
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaman/hman3c/getexecname.3c.html,
suggests that it isn't always reliable, so we should at least check if it
the return value makes sense or not.
Well, I had already covered the concern of the function not suceeding.
But, it looks like the only additional possibility is that sometimes it
might return a relative path to the executable instead of an absolute
path. It suggests pre-pending the output of getcwd in such a case.
Otherwise, I think it's definitely the preferred way to go about this.
I can make the necessary change to have it account for the relative
path case, as I'm not concerned about the warning regarding getcwd not
working: "unless the process or one of its ancestors has changed its
root directory or
current working directory since the last successful call to one of the exec
family of functions". Since this happens at the beginning of the
allegro init cycle. Once someone changes the current working directory
all bets are off anyway.
> 2) In several key cases XKeysymToString was being used to directly pass
> arguments to other routines, without checking the return value first.
This
> is bad. XKeysymToString can return NULL as a value. I only fixed the
places
> that were causing Allegro to segfault for me, not all of them. I noted
that
> the Allegro code was already checking this in some places, but not in
> others. This should be addressed.
I agree. Do you think you can make a (seperate) patch for that?
What changes I made were already separated out within the patch file I
originally sent. Did you mean you wanted me to add code to check the
rest of the cases and send an additional patch for that or ... ?
> 3) I was unable to compile on Solaris since there is no GFX_MODEX support
> available, and the #ifdef checks being used are rather pointless since
I'm
> told the GFX_MODEX is always defined. So, they were changed to
GFX_HAS_VGA
> instead per the recommendation of one of the other list members here.
GFX_HAS_VGA is, I think, supposed to be internal only. The problem should
be addressed by defining the modex* functions on all UNIX systems (bleh)
since GFX_MODEX `exists' on all UNIX systems as well.