Re: [AD] Proposal for new magic main

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> IMHO, the executable name is pretty irrelevant, but that's a
> side issue.

Not that much of a side issue, as we have in the API:

void get_executable_name(char *buf, int size);
Fills buf with the full path to the current executable, writing at most size
bytes. This generally comes from argv[0], but on Unix systems if argv[0]
does not specify the path, we search for our file in $PATH.

Is there any mean to retrieve the argv[0] parameter under Unix, apart from
the main() entry point ? If so, we could get rid of the magic main under
Unix.

> I think END_OF_MAIN was intended just to ensure this was done
> at precisely one place in the program.  So perhaps it's sufficient
> to just do something like:
>
>     #define main \
>         WinMain(parameters) \
>         { \
>             stuff to call main \
>         } \
>         int main
>
> on Windows only?

If we effectively got rid of the magic main under Unix, I think we should
keep the current Windows magic main (based on END_OF_MAIN) because it hasn't
got the flaw Michael pointed out. Changing the magic main is really only
needed for Unix, because of Darwin.

> I don't like defining `main' though, we could equally well provide
> exactly the current END_OF_MAIN define, which does nothing on
> any system except Windows where it inserts the WinMain entry point.

I agree.

> It's up to you guys what you do, but it has irritated me in the
> past that Allegro on Unix seems to interfere with `main' for the
> sole purposes of things which are essentially pointless
> (returning the executable name, and setting __crt0_argc and
> __crt0_argv, which aren't useful to the user since they were
> passed on to the main function anyway).

I agree that we could get rid of the __crt0_* stuff. But we are stuck with
the executable name for 4.1.x because of the API function.

> And if only one platform needs END_OF_MAIN, nobody will bother
> with it on other platforms. :(

It's not really our problem, I think, that users don't follow the rules.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx