want to know

[Badger BA 64810]

In article <10760 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <2538 at trantor.harris-atd.com> bbadger at x102c.harris-atd.com writes:
>>Firstly, it is less informative to the user.  Having a fixed entry like main
>>removes the possibility of a descriptive name being applied to a program.
>Program users do not see the name of the main() function at all.
>I don't think I've ever had a UNIX program called "main".
Users aren't concerned with C at all!  It's programmers who see the C code.
This reminds me of the ``a.out'' problem.  This is an example of the same
quick-hack mentality.  (``Well, I can always mv it to somthing else later!''
Of course only quiche-eaters use ``cc -o invocation_name'', right? (:-))


>>It also interferes with naming conventions for files and cross-reference tools
>>like ctags.  Our local ctags has been modified to substitute ``Mfoo'' for 
>>the symbol ``main()'' found in file ``foo.c''.  This kind of game wouldn't
>>be required if C let you choose your main program name.
>
>It's not required anyway.  There can be only one external function named
>main() among all the source files constituting a program.  Besides, you
>shouldn't lay deficiencies in "ctags" at C's doorstep.
There's more than one program in a system.  I'm not complaining about ctags
failure to resolve the multiple "usage()" functions which may be present,
I'm protesting the lack of a mechanism in C to name *all* my functions,
even the ``main'' procedure.

>>There are lots of UNIX programs written to simulate this by 
>>switching on the value of argv[0] (the name the program was invoked by --
>>see vi/ex, [ec]tags for examples), but this facility could be legitimized
>>by providing an entry point specification in exec().
>Programs such as "vi" do NOT follow the model you suggest, and for
>exec to be able to do what you propose there would have to be substantial
>changes to the kernel and to the C run-time startoff module, adding
>overhead to essentially every UNIX process.  I don't see that the putative
>benefits could possibly justify the cost.
Actually, the UNIX exec system call is perfectly flexible in this, since 
it places no constraints on what the run-time does with the argv values.
The argv[0] value could be used to specify an alternate entry point.
I'm not seriously suggesting that these changes _should_ be made to UNIX,
but it would merely involve changing the shells and the runtime startup.

For example, argv[0] could have the form "entrypoint:callstring" where
"entrypoint" is the startup symbol in the file, and "callstring" is the
same thing that used to be passed in argv[0], i.e., the string.  
Each enterable function in the object could have a compiled-in
interface entry which understood how to convert the strings in argv 
into something digestible by the actual function.  In the case of main()
all that function would do is increment argv[0] past the "entrypoint:"
so that argv[0] points to "callstring".  

Now, that was the complex case, where multiple entry points with 
user-defined argument types was involved.  The simpler case is where 
I don't want to upset the single entry point concept, I just want to put
a symbolic name on my [main] function and have that name show up in the 
symbol table.  It seems to me that some simple aliasing of ``_main'' to
``_myfunc'' would be quite simple.  A simple option to ld would work:
	ld -o foo foo.o -main=fubar
[Please excuse any ignorance of actual ld option syntax, I don't have
time to look it up right now.] 

The use of ``main()'' as an entry point **in the higher-level language** 
is a slightly annoying quirk.  It can be programmed around, but its a bother.


Bernard A. Badger Jr.	407/984-6385          |``Use the Source, Luke!''
Secure Computer Products                      |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.