Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!thetone!swilson
From: swilson%thetone@Sun.COM (Scott Wilson)
Newsgroups: comp.sys.mac.programmer
Subject: LSC 3.0, argc & argv, linking
Message-ID: <66791@sun.uucp>
Date: 2 Sep 88 19:13:28 GMT
Sender: news@sun.uucp
Reply-To: swilson@sun.UUCP ()
Organization: Sun Microsystems, Mountain View
Lines: 55

The topic of passing argc and argv to a C program came up on comp.lang.c
which got me thinking about the way this works in THINK's LightspeedC.
For those who aren't familiar, in LSC to get a pseudo UNIX command line
that allows you to type program arguments that will end up as argv, you
call your main() function _main().  You then link your program with the
file "unix main.c" which has a main() in it that parses the command line
and then calls your _main().  I think this is kludgey.  I don't like the
idea of having code that looks like:

	#ifdef THINK_C
	#define main _main
	#endif

This is ugly.  To me, there seems to be a better way to do this (I would
mail this to THINK, but they don't seem too thrilled to listen to me these
days).  I would like to see this problem solved by how the program
was linked:  if "unix main.c" is added to the project then a command
line is prompted for and args are passed to main() in the user's program; if
"unix main.c" is not in the project then main() is called with argc of 1.
This way main() in the user's program would always be called main.  The
file "unix main.c" could have a _main() in it that would do the command line
stuff and then call main().  In the abscence of "unix main.c", another _main() 
would be linked in that would just set argc to 1 (and either the program
name or "" for argv) and call main().  This other, nearly null, _main() would
reside in MacTraps or some other convenient place and would be supplanted by
the _main() in "unix main.c" if present.  Of course, this means that LSC's
startup code would jump to _main() to start off instead of main(), but
this would be transparent to the program which certainly isn't the case
now.

I don't think this is currently possible at present, however, which
brings me to the next topic.  I haven't been able to make it work,
but does LSC allow you to supersede some functions of a library
without causing link errors?  For example let's say you wanted to
link with strings but wanted to have your own version of just strcpy().
I believe that this evokes an error message complaining of multiple
occurrences of strcpy().  I think this is something LSC should allow,
but it would mean there needs to be some method of determining which
occurrence of a function was used.  UNIX in this case does the following
(I think):  a function that came from a file given on the command line
supersedes any occurrence of a function of the same name that is found
in a library.  The distinction is between compiled user files and system
libraries.  LSC could do something similar, if a user's .c contained
a function also found in a library then the user's version would be used.
This would also mean that code ported to LSC would not have to worry
about clashing with some non-standard fucntions in LSC's library (like
trying to port a program that had it's own Move() in it (I think that's
the name LSC uses, but I don't have it here)).

Any comments on this?

--
Scott Wilson		arpa: swilson@sun.com
Sun Microsystems	uucp: ...!sun!swilson
Mt. View, CA