mysore@bsu-cs.bsu.edu (Swamy Bale) (08/03/89)
Hi everybody, I would like to know how to convert a character into its numerical form (or ascii number). I used atoi function, but it takes only numerical characters(If I am not wrong). for example : 'a' ----> should return its numerical equivalent. I would appreciate if anybody help me. Swamy
lhf@aries5 (Luiz H. deFigueiredo) (08/04/89)
In article <8487@bsu-cs.bsu.edu> you write: >Hi everybody, > > I would like to know how to convert a character into its numerical form >(or ascii number). I used atoi function, but it takes only numerical >characters(If I am not wrong). > >for example : 'a' ----> should return its numerical equivalent. > >I would appreciate if anybody help me. > >Swamy Come now, 'a' is just SHORTHAND for 65 (if you're using ascii). I suspect that this is going to be joined by a million others... :-) PS: Apologies for broadcasting this but my mailer doesn't know bsu-cs.bsu.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/04/89)
In article <8487@bsu-cs.bsu.edu> mysore@bsu-cs.bsu.edu (Swamy Bale) writes:
- I would like to know how to convert a character into its numerical form
-(or ascii number). I used atoi function, but it takes only numerical
-characters(If I am not wrong).
-for example : 'a' ----> should return its numerical equivalent.
The charater is already represented as its (ASCII) numerical code value.
Therefore there is no conversion necessary.roemer@cs.vu.nl (Roemer Lievaart) (08/04/89)
mysore@bsu-cs.bsu.edu (Swamy Bale) writes: >Hi everybody, > I would like to know how to convert a character into its numerical form >(or ascii number). >for example : 'a' ----> should return its numerical equivalent. Hi, everybody, I'm also a University's student in need of help. I always see that people define the function 'main' in C-programs. Why is that? What should it return? Can't I use another name? Thanks in advance, I need your help desperately!!!!!!!!!!!!!!!!!!!! ____________________________________________________________________________ Roemer B. Lievaart | Pavlov's dog: "I've trained this professor Amsterdam, Holland | thoroughly. Every time a bell rings, he'll bring roemer@cs.vu.nl | me food." -- Rudy Kousbroek
jba@harald.ruc.dk (Jan B. Andersen) (08/04/89)
lhf@aries5 (Luiz H. deFigueiredo) writes: >PS: Apologies for broadcasting this but my mailer doesn't know bsu-cs.bsu.edu Same problem here. -- Jan B. Andersen ("SIMULA does it with CLASS")
maart@cs.vu.nl (Maarten Litmaath) (08/04/89)
roemer@cs.vu.nl (Roemer Lievaart) writes: \mysore@bsu-cs.bsu.edu (Swamy Bale) writes: \>Hi everybody, \> I would like to know how to convert a character into its numerical form \>(or ascii number). \>for example : 'a' ----> should return its numerical equivalent. \ \Hi, everybody, \ \I'm also a University's student in need of help. I always see that people \define the function 'main' in C-programs. Why is that? What should it return? \Can't I use another name? \ \Thanks in advance, I need your help desperately!!!!!!!!!!!!!!!!!!!! To use `pipo' for `main' use: cc -Dpipo=main prog.c :-) -- "Mom! Eric Newton broke the day! In 24 |Maarten Litmaath @ VU Amsterdam: parts!" (Mike Schmitt in misc.misc) |maart@cs.vu.nl, mcvax!botter!maart
ggg@sunquest.UUCP (Guy Greenwald) (08/08/89)
In article <2980@solo9.cs.vu.nl>, roemer@cs.vu.nl (Roemer Lievaart) writes: > > Hi, everybody, > > I'm also a University's student in need of help. I always see that people > define the function 'main' in C-programs. Why is that? What should it return? > Can't I use another name? > > Thanks in advance, I need your help desperately!!!!!!!!!!!!!!!!!!!! I'd love to answer your question. Unfortunately, when I read it, I tried to jam all ten fingers in my mouth at once and ended up injuring myself. As soon as I can type comfortably, you'll get the answer you deserve.
darin@nova.laic.uucp (Darin Johnson) (08/11/89)
In article <2980@solo9.cs.vu.nl>, roemer@cs.vu.nl (Roemer Lievaart) writes: > > Hi, everybody, > > I'm also a University's student in need of help. I always see that people > define the function 'main' in C-programs. Why is that? What should it return? > Can't I use another name? It is a UNIX-ism. The UNIX linker uses that function name as the name of the first routine to jump to (although many UNIX version may have ways around this). Other operating systems and linkers do things differently (first function found, special symbol in the object file, specified on command line, etc.). However, most C compilers use main() as the default (with a way out if you need to), since that is what K&R uses. Also, for you confusion, most UNIX kernels do not start at main() or even have a main()... Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
karl@haddock.ima.isc.com (Karl Heuer) (08/12/89)
In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >[Name deleted on purpose] writes: >> I'm also a University's student in need of help. I always see that people >> define the function 'main' in C-programs. Why is that? What should it >> return? Can't I use another name? Come on, folks, this was almost certainly a JOKE. It was posted in response to another "dumb question". >It is a UNIX-ism. The UNIX linker uses that function name as the name of >the first routine to jump to. And the answer is somewhere between misleading and wrong. First of all, main() is special according to everything that resembles a standard: (K&R, H&S, D&M, pANS); this is a property of C, not of UNIX. Second, it is not special-cased by the linker in any UNIX implementation I know of. Rather, there is a pre-main routine that calls main() just like a normal function. Execution begins at this pre-main routine, not because of a linker hack, but because when the `cc' command invokes `ld', it tells it the name of the entry-point label. The magic is in the driver program `cc'. >Also, for you confusion, most UNIX kernels do not start at main() or even >have a main()... Which is, btw, also consistent with the pANS, which states: "In a freestanding environment ... the name and type of the function called at program startup are implementation-defined." [2.1.2.1] For all practical purposes (unless you're compiling C code to run on microwave ovens), "freestanding" means you're compiling the UNIX kernel. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bright@Data-IO.COM (Walter Bright) (08/12/89)
In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: <In article <2980@solo9.cs.vu.nl>, roemer@cs.vu.nl (Roemer Lievaart) writes: << I always see that people << define the function 'main' in C-programs. Why is that? What should it return? << Can't I use another name? Some point has to be the entry point for your program. It's convenient for that one to be called 'main'. Main is simply a function called from the startup object file linked in from the library that initializes the program. You can use another name if you modify the startup code and reassemble it. <It is a UNIX-ism. The UNIX linker uses that function name as the name of <the first routine to jump to. It has nothing to do with the linker. The startup code calls main. The startup code contains the start address of the program, and is normally not associated with any particular name. It's not a UNIX-ism. It's a C-ism. Other languages, such as Fortran, have different methods for defining the starting point of the code, and so have different startup code. The same linker is used. <Also, for your confusion, most UNIX kernels do not start at main() or even <have a main()... That's because they don't use the C startup code.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/12/89)
In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: -In article <2980@solo9.cs.vu.nl>, roemer@cs.vu.nl (Roemer Lievaart) writes: -> I'm also a University's student in need of help. I always see that people -> define the function 'main' in C-programs. Why is that? What should it return? -> Can't I use another name? -It is a UNIX-ism. The UNIX linker uses that function name as the name of -the first routine to jump to (although many UNIX version may have ways -around this). Other operating systems and linkers do things differently -(first function found, special symbol in the object file, specified on -command line, etc.). However, most C compilers use main() as the -default (with a way out if you need to), since that is what K&R uses. The special role of main() is NOT a "UNIXism". It is REQUIRED BEHAVIOR in ANY standard-conforming hosted implementation of C. Standalone use of C can indeed have other startup rules.
peter@ficc.uu.net (Peter da Silva) (08/12/89)
In article <14269@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > For all practical purposes (unless you're compiling C code to run on > microwave ovens), "freestanding" means you're compiling the UNIX kernel. Or unless you're writing an Amiga device driver, handler, or library. I think there are certain special-cases on the Macintosh as well where the start-up sequence isn't compatible with a standard UNIX-ish main(). I have also heard that certain Microsoft Windows modules need this too. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
seanf@sco.COM (Sean Fagan) (08/13/89)
In article <14269@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >>Also, for you confusion, most UNIX kernels do not start at main() or even >>have a main()... >Which is, btw, also consistent with the pANS, which states: "In a freestanding >environment It's ok, 'cause he's wrong here, as well. Every Unix kernel I've looked at (i.e., all of them I could get my grubby little hands on 8-)) had a main. The kernels I'm running on right now (at home, called up to work, rlogin'd to another machine) all have a main in them. Hold on a sec. Yep, just took a look at the 4.3 kernel sources, and it has a main, as well. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.
cik@l.cc.purdue.edu (Herman Rubin) (08/15/89)
In article <14269@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: > >[Name deleted on purpose] writes: > >> I'm also a University's student in need of help. I always see that people > >> define the function 'main' in C-programs. Why is that? What should it > >> return? Can't I use another name? > > Come on, folks, this was almost certainly a JOKE. It was posted in response > to another "dumb question". > > >It is a UNIX-ism. The UNIX linker uses that function name as the name of > >the first routine to jump to. > > And the answer is somewhere between misleading and wrong. First of all, > main() is special according to everything that resembles a standard: (K&R, > H&S, D&M, pANS); this is a property of C, not of UNIX. Second, it is not > special-cased by the linker in any UNIX implementation I know of. Rather, > there is a pre-main routine that calls main() just like a normal function. > Execution begins at this pre-main routine, not because of a linker hack, but > because when the `cc' command invokes `ld', it tells it the name of the > entry-point label. The magic is in the driver program `cc'. No, the question is not a JOKE. It is a stupidity in UNIX which causes the problem. I have used other systems in which the main program could have any name whatever, and even in which the entry need not be to a main program, while a main program is present. I have even used it. Those who remember the old Fortran will know that one normally had a PROGRAM card, which was of the form PROGRAM NAME(.............) amd NAME was the name of the main entry point of the program. If you look at the documentation of ld, it states that one can specify the original entry point. This seems not to be implemented well in any version of UNIX with which I am familiar, and frankly, I miss it. It is true that one can get around this by rewriting crt0 and linking it, but THAT problem is the one which I believe the loader should handle, and does not. There is no even moderately fair reason why the user's program should start at main (or _main if from C, or _MAIN_ if from Fortran). -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
Tim_CDC_Roberts@cup.portal.com (08/15/89)
Regarding the 'Why is main called main()?' fiasco:
If this was a joke, then I was taken in, because I penned a four paragraph
beginner-style response to this message.
There are pros and cons to the main_as_default_transfer_address scheme,
of course. If you allowed any label to be the transfer address, then you
would need some kind of syntax to specify what to use:
main (int argc, char ** argv) { ....
could become
transfer int entry_point (int argc, char ** argv) { ...
The problem with this is that it requires a re-think of the startup code
issue. One precedent (FORTRAN) would be to have the _transfer_ entry point
(called 'entry_point' above) actually be the loader transfer address, and
have the compiler insert a call to startup code in any function with a
_transfer_ modifier.
However, IMHO, the 'main' idea is conceptually cleaner.
Tim_CDC_Roberts@cup.portal.com | Control Data...
...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.ask@cbnews.ATT.COM (Arthur S. Kamlet) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >Those who remember the old Fortran will know that one normally had a PROGRAM >card, which was of the form > > PROGRAM NAME(.............) > >amd NAME was the name of the main entry point of the program. If you look at >the documentation of ld, it states that one can specify the original entry >point. This seems not to be implemented well in any version of UNIX with Well, instead of bringing back the old PROGRAM card, we substitute main(){PROGRAM_NAME()} hey, hey, hey, one line, that's all. just like the old days :^) -- Art Kamlet a_s_kamlet@att.com AT&T Bell Laboratories, Columbus
idall@augean.OZ (Ian Dall) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <14269@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: >> In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >> >[Name deleted on purpose] writes: >> >> I'm also a University's student in need of help. I always see that people >> >> define the function 'main' in C-programs. Why is that? What should it >> >> return? Can't I use another name? >> >> And the answer is somewhere between misleading and wrong. First of all, >> main() is special according to everything that resembles a standard: (K&R, >> H&S, D&M, pANS); this is a property of C, not of UNIX. Second, it is not >> special-cased by the linker in any UNIX implementation I know of. Rather, >> there is a pre-main routine that calls main() just like a normal function. > >No, the question is not a JOKE. It is a stupidity in UNIX which causes the >problem. I have used other systems in which the main program could have >any name whatever, and even in which the entry need not be to a main program, >while a main program is present. I have even used it. The UNIX kernal knows nothing about an entry point called main. Neither the compiler nor the assembler not the linker know anything special about "main". The 4.3 BSD ld arranges for execution to start at the beginning of the first file linked (normally crt0.o). The SysV linker normally arranges for execution to start at "start" or "_start" but be changed by options to ld. The only place where "main" appears explicitly is in the source for "crt0.o" which has the entry point "start" or "_start". If you have a burning desire to call your top level function something else I would suggest writing your own crt0.{c,s} and using a cpp parameter as the name of the function to call. You then recompile crt0 each time. >Those who remember the old Fortran will know that one normally had a PROGRAM >card, which was of the form > > PROGRAM NAME(.............) > >amd NAME was the name of the main entry point of the program. How many of those implimentations simply ignored the PROGRAM statement (except for the compiler error messages) and aranged some system standard entry point in the actual executable? > If you look at >the documentation of ld, it states that one can specify the original entry >point. This seems not to be implemented well in any version of UNIX with >which I am familiar, and frankly, I miss it. Works OK on my SysV system. Of course you have to understand that you are not changing the name of "main" but of "start" and crt0.o which you have left out might do important things on your system! >There is no even moderately fair reason why the user's program should start >at main (or _main if from C, or _MAIN_ if from Fortran). Most high level languages need some special code to be executed when the program first starts. Either the compiler needs to understand that the main program (by whatever name) is special and arrange the execution of that code to happen in the start of the main program, or the system has to arrange for a start up routine to be executed first which does the start up code and then calls the users main program. The way it is done in C (and it is a C standard) the compiler doesn't treats the main program like any other function which I think is kind of elegant. What do you actually want? Do you care what is in the actual executable symbol table? If not simply compile with cc -Dmymain=main -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others. idall@augean.oz
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: [Here Rubin goes again. As regular readers of this newsgroup will recall, he seems to be of the opinion that C "should" allow him to do anything he can do in assembler.] >There is no even moderately fair reason why the user's program should start >at main (or _main if from C, or _MAIN_ if from Fortran). There is no particular reason why it shouldn't, either, in C. Arguments about how other languages, linkers, etc. do it differently are simply irrelevant. The initial entry to a C program in a hosted environment is the function named "main", which has a well-defined interface (that differs in some ways from other C functions). Learn to use the language instead of fighting it!
tkacik@rphroy.UUCP (Tom Tkacik) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >> >> I'm also a University's student in need of help. I always see that people >> >> define the function 'main' in C-programs. Why is that? What should it >> >> return? Can't I use another name? > It is a stupidity in UNIX which causes the >problem. I have used other systems in which the main program could have >any name whatever, and even in which the entry need not be to a main program, >while a main program is present. I have even used it. >There is no even moderately fair reason why the user's program should start >at main (or _main if from C, or _MAIN_ if from Fortran). The pANS C got rid of the still born keyword 'entry'. Maybe it had no meaning, or was to mean something completely different, but my interpretation of it was to give the entry point into the program, if you did not like main. Maybe something like: entry start(); start() { /* this is now the main routine */ } Does anybody know what 'entry' was supposed to do? --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette -- --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette
davidsen@sungod.crd.ge.com (ody) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: | No, the question is not a JOKE. It is a stupidity in UNIX which causes the | problem. I have used other systems in which the main program could have | any name whatever, and even in which the entry need not be to a main program, | while a main program is present. I have even used it. There is no main program in C. There is a procedure named main. In FORTRAN the main program is diferent from a subroutine or function, in C it just happens to have a special name. If you really want to have a program which enters somehere else write a dummy main: main(argc, argv, env) int argc; char *argv, *env; { exit(yourname(argc, argv, env)); } I totally fail to see what the advantage of using another name is, but I'm sure someone finds it aestheticaly (sp?) pleasing. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
henry@utzoo.uucp (Henry Spencer) (08/16/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >There is no even moderately fair reason why the user's program should start >at main (or _main if from C, or _MAIN_ if from Fortran). Is there a reason why it shouldn't? (Other than that Herman Rubin doesn't like it, which is unremarkable since he doesn't like a lot of things.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/17/89)
In article <1701@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > If you really want to have a program which enters somehere else write >a dummy main: > main(argc, argv, env) > int argc; > char *argv, *env; > { exit(yourname(argc, argv, env)); } > > I totally fail to see what the advantage of using another name is, but >I'm sure someone finds it aestheticaly (sp?) pleasing. > bill davidsen (davidsen@crdos1.crd.GE.COM) I have problems with ``main'' from two different directions. 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. 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. Secondly, I don't really like the idea of having a _single_ entry point to a program. I prefer a scheme which allows any external function to be called from the command line. You can distinguish a single function as the main entry. Of course, yo without requiring that it be the _only_ entry. 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(). It's worth noting that the debugger can call any subroutine at any time. What sort of command line syntax should be used for multi-entry point programs? The biggest problem with this sort of scheme is how to process the arguments for arbitrary types of function arguments. In closed single-language systems (lisp and some ada environments come to mind) the command line parser is part of the compiler, and can manage this. The debugger can typically do this, too, though only for the program being debugged. 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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
quiroz@cs.rochester.edu (Cesar Quiroz) (08/17/89)
Just a few difficulties I have with Badger's argument. In <2538@trantor.harris-atd.com>, bbadger@x102c.harris-atd.com wrote: | ... | I have problems with ``main'' from two different directions. | | 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. Not quite so. I bet all the C code I keep has different names for different programs. I just happen to use the filename to name the programs. The particular entry point used by the runtime system is of no importance when looking for informative naming, because that name is not the one people associate with the program! The objection is trivially true, and quite irrelevant. [I wouldn't claim the scheme in use is perfect, think about how many times a novice writes a `test.c' and gets himself into strange states.] | 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. This is true, and also irrelevant. It is not unusual to have a `usage()' function, just because it is the reasonable thing to do. Do you also special-case this? This point only says that the tools need a correct model of the naming system, rather than build in erroneous assumptions (``No two programs have different functions with the same name''). | Secondly, I don't really like the idea of having a _single_ entry | point to a program. ... This is more interesting. Is it fair to say that this issue goes beyond the language itself and into the design of the programming environment? If you could suppress the hand-waving and provide more detail about how you would go about changing exec and the shells it would be a stronger proposal. As it is, it amounts to `I don't like it, I like X and you take care to make sure X works for me', a position for which I have no sympathy. If anyone cares to formulate this proposal in terms that can be discussed, I would suggest taking a look at the debate (in the Lisp community) between residential and file-based systems, just to make sure no time is spent in rediscoveries. My impression is that the new language created that way will have little resemblance to C anyway. -- Cesar Augusto Quiroz Gonzalez Department of Computer Science University of Rochester Rochester, NY 14627
news@ism780c.isc.com (News system) (08/17/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >Those who remember the old Fortran will know that one normally had a PROGRAM >card, which was of the form > > PROGRAM NAME(.............) > Herman's recolection of old FORTRAN is different from mine. The original FORTRAN (for the IBM 704) had no user written subroutine facility at all so the question of a name was moot. FORTRAN/2, FORTRAN/4, (and I think FORTRAN/66) programs all begin execution with the one and only ANONYMOUS program unit. FORTRAN/77 also begins execution with the anonymous program unit if there is one although the entry unit may be named. In the FORTRAN/77 system that I implemented the program name, if given, is ignored. This was done in order to implement the concept of an anonymous entry point. And speaking of old FORTRAN, The first FORTRAN system that I am aware of that used control cards was called FMS (Fortran Monitor System). This system did not have a PROGRAM card. An input card file looked like: *FORTRAN <fortran-source-cards> *FAP <assembly-language-source-cards> <previously-compiled-object-decks> *DATA <data-for-the-object-program> If a PROGRAM NAME(....) card was used in later systems, my guess is that it was on a system with online object file storage and that NAME was the name of the file containing the program, not the name of the entry point. Is is possible that Herman is confusing the name of the file containing a program with the name of an entry point? Marv Rubinstein
barmar@think.COM (Barry Margolin) (08/17/89)
In article <2538@trantor.harris-atd.com> bbadger@x102c.harris-atd.com writes: >Secondly, I don't really like the idea of having a _single_ entry point >to a program. I prefer a scheme which allows any external function to >be called from the command line. You can distinguish a single function >as the main entry. Of course, yo without requiring that it be the _only_ >entry. There are lots of UNIX programs written to simulate this by >switching on the value of argv[0] Multics does precisely what you are describing. On Multics, the shell is basically a user interface to the dynamic linker, so anything that can be called from another program can be invoked from the command line. There are argument restrictions, of course; the shell always passes character string arguments (procedures intended to be invoked as commands use a varargs-like interface). An entrypoint is specified as filename$entrypoint; if there's no "$", the system looks for an entrypoint with the same name as the file, and then for an entrypoint "main_" (for the benefit of programs ported from environments where the main procedure is specified in the program -- e.g. the Multics equivalent of crt0 has a main_ entrypoint that initializes things and calls main). One aspect of Multics that makes this feasible is that no special setup is normally necessary when invoking a command. The entire login session is a single process, so all the process state is already initilized; there's generally no need for anything like crt0 (there actually is something like it for C, because we wanted our C runtime to emulate some Unix behavior, such as freeing everything malloc'ed by a program when it exits or main returns, so you can't use the above mechanism with C on Multics). The way to implement this on Unix is to make a version of exec() that takes an entrypoint name. It would look it up in the file's symbol table, and pass it on to start() (the actual initial routine in crt0). start() would call this address instead of always calling main(). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
cik@l.cc.purdue.edu (Herman Rubin) (08/17/89)
In article <21309@cup.portal.com>, Tim_CDC_Roberts@cup.portal.com writes: > Regarding the 'Why is main called main()?' fiasco: > > If this was a joke, then I was taken in, because I penned a four paragraph > beginner-style response to this message. > > There are pros and cons to the main_as_default_transfer_address scheme, > of course. If you allowed any label to be the transfer address, then you > would need some kind of syntax to specify what to use: > > main (int argc, char ** argv) { .... > > could become > > transfer int entry_point (int argc, char ** argv) { ... This is not adequate. I have used systems where only one program card was used, and it needed the explicit list of program arguments, but one could still transfer to any other entry point. Of course, this did not use argc and argv. In C, one could start an arbitrary program with int argc; char** argv; program(........) to handle the problem. If this does not work (I have not tried it), put the handling of argc and argv in the loader. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/17/89)
In article <2538@trantor.harris-atd.com> bbadger@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". >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 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.
cik@l.cc.purdue.edu (Herman Rubin) (08/17/89)
In the previous operating systems I have used, the startup procedure was done by the loader. This is what is missing in UNIX; the loader does not have the capability to produce the startup program, so that must be explicitly put in. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/17/89)
In article <15373@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: >Does anybody know what 'entry' was supposed to do? Yes, it was intended for the same thing as Fortran's alternate function entry point facility. The usual example is sincos (one function with separate entries for sin() and cos()). C's "entry" was rarely, if ever, implemented, primarily because with file-static functions it was really unnecessary.
henry@utzoo.uucp (Henry Spencer) (08/17/89)
In article <15373@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: >The pANS C got rid of the still born keyword 'entry'. >Maybe it had no meaning, or was to mean something completely different, >but my interpretation of it was to give the entry point into the program, >if you did not like main. Rather more likely is that it was meant to be similar to ENTRY in PL/I (and FORTRAN, I think -- my memory is dim), providing for multiple entry points into individual functions. Ugh. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/17/89)
In article <1989Aug16.203219.11825@cs.rochester.edu> quiroz@cs.rochester.edu (Cesar Quiroz) writes: >Just a few difficulties I have with Badger's argument. >In <2538@trantor.harris-atd.com>, bbadger@x102c.harris-atd.com wrote: >| 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. >Not quite so. I bet all the C code I keep has different names for >different programs. I just happen to use the filename to name the >programs. The particular entry point used by the runtime system is >of no importance when looking for informative naming, because that >name is not the one people associate with the program! The >objection is trivially true, and quite irrelevant. [I wouldn't >claim the scheme in use is perfect, think about how many times a >novice writes a `test.c' and gets himself into strange states.] > Yes, and occaisonally you'll see a file ``main.c''! The point is that the main program has a _purpose_ which could (should!) be described in its name. Just like every other function. C's lazy run-time startup code is responsible for this blemish. It doesn't ruin the language, but it is a wart. You use significant names for the files of your programs, why shouldn't you use significant names for the main routines? I suppose a standards committee would put the burden of proof on those wishing to change the status quo, but I'm not a standards committee, I'm used to having this feature in other languages, and I feel it's up to the defenders of ``main()'' to show why this restriction is desirable. >| 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. > >This is true, and also irrelevant. It is not unusual to have a >`usage()' function, just because it is the reasonable thing to do. >Do you also special-case this? This point only says that the tools >need a correct model of the naming system, rather than build in >erroneous assumptions (``No two programs have different functions >with the same name''). Of course the tools could be better! My point is that ``main'' is an *unnecessary* restriction. You _could_ program in a language which requires all parameters to have fixed names (r1,r2,r3...). It's more expressive to be able to name things yourself. Even assemblers are symbolic. Why *not* let me choose the name of the main program? ``Well, we've always done it this way.'' isn't much of a reason (except in standardizing existing practice). A work-around for now is to adopt a coding convention to trivialize main(): int printenv(int argc, char *argv[] ,char *renvp[]); int main(int argc, char *argv[] ,char *renvp[]) {return (printenv(argc, argv ,renvp));} int printenv(int argc, char *argv[] ,char *renvp[]) { ...stuff ...} But I'd much rather just write: int printenv(int argc, char *argv[] ,char *renvp[]) { ...stuff ...} >| Secondly, I don't really like the idea of having a _single_ entry >| point to a program. ... >This is more interesting. Is it fair to say that this issue goes >beyond the language itself and into the design of the programming >environment? ... provide more detail about how you would go about >changing exec and the shells it would be a stronger proposal. ... Yes, this is chiefly an environment problem -- how does a shell construct arguments for arbitrary functions? UNIX takes the easy way out by restricting the interface to strings (main(argc,argv,envp)). Many single-language systems offer a more complete interface. Lisp, Cedar, Arcturus (Interpreted Ada, Thomas Standish UC,Irvine) and the Rational Corp. Ada environment come to mind. The UNIX shell has two in-out interfaces (IFs) to programs. The first IF is the main call arguments and return value: int main(int argc, char *argv[] ,char *renvp[]) The command line words and the environment strings are bundled and passed to main, and the return value is used as a status. The second IF is the standard input/output redirection, as used in pipelines. In particular output from a program can be captured in the shell command using `foo` syntax to insert the output from command foo into the command line. (As in `` mv $i `echo $i | sed 's/.ada/.a/'` ''. Note that `` and '' are not part of the command.) Actually, this problem has already been solved by the debuggers: dbx, sdb, adb, gdb. Each of these has ways of calling any function within the object module. >As it is, it amounts to `I don't like it, I like X and you take care >to make sure X works for me', a position for which I have no sympathy. > >If anyone cares to formulate this proposal in terms that can be >discussed, I would suggest taking a look at the debate (in the Lisp >community) between residential and file-based systems, just to make >sure no time is spent in rediscoveries. My impression is that the >new language created that way will have little resemblance to C >anyway. There really wouldn't be any much change to C. Even now, main() isn't treated specially by the C compiler. It's just that the runtime system makes a direct call to main after initial start-up. 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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
svirsky@ttidca.TTI.COM (Bill Svirsky) (08/18/89)
In article <2538@trantor.harris-atd.com> bbadger@x102c.harris-atd.com writes: +In article <1701@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: +> If you really want to have a program which enters somehere else write +>a dummy main: +> main(argc, argv, env) +> int argc; +> char *argv, *env; +> { exit(yourname(argc, argv, env)); } +> +I have problems with ``main'' from two different directions. + +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. +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. Any reason why the following wouldn't work? #define InformativeName main ... InformativeName(argc, argv) int argc; char *argv[]; When working with someone else's code for the first time, I like being able to find where the program starts by doing a global search for "main", since many programmers don't put it at the beginning of the source. Or, if there are many modules, and none with a name that gives a clue of which is the main module, I can do an fgrep on main. Not all the source I get has good, or even any, documentation. -- Bill Svirsky, Citicorp+TTI, 3100 Ocean Park Blvd., Santa Monica, CA 90405 Work phone: 213-450-9111 x2597 svirsky@ttidca.tti.com | ...!{csun,psivax,rdlvax,retix}!ttidca!svirsky
r4@cbnews.ATT.COM (richard.r.grady..jr) (08/18/89)
In article <31668@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: >In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >> >>Those who remember the old Fortran will know that one normally had a PROGRAM >>card, which was of the form >> >> PROGRAM NAME(.............) >> > >Herman's recolection of old FORTRAN is different from mine. The original >FORTRAN (for the IBM 704) had no user written subroutine facility at all so >the question of a name was moot. FORTRAN/2, FORTRAN/4, (and I think >FORTRAN/66) programs all begin execution with the one and only ANONYMOUS ^^^^^^^^^^ >program unit. [...] This is getting a bit away from the C language, but... Control Data's version of FORTRAN/66 *required* a PROGRAM statement. Furthermore, all I/O files (even standard input and output) had to be declared in the PROGRAM statement. PROGRAM FOO(INPUT,OUTPUT,TAPE1,TAPE2,....) where TAPE1, TAPE2, etc., corresponded to logical unit 1, 2, etc. If you didn't declare a file this way, the program would barf. (If you forgot OUTPUT, the barf was silent, because the complaint routine couldn't find the file OUTPUT to write on!) ------------------------------------------------------------------- Dick Grady r_r_grady@att.com ...!att!mvuxd!r4
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/18/89)
In article <2549@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >You use significant names for the files of your programs, why shouldn't you >use significant names for the main routines? main() certainly is a descriptive name for the role of that pseudo-function within a C application. The application within its invocation context has yet another, hopefully descriptive, name ("grep"?) or icon (smiling frog?) or whatever. >There really wouldn't be any much change to C. Even now, main() isn't >treated specially by the C compiler. Speak for yourself. The C compiler I use at home processes the main() pseudo-function differently from other functions, and in general any Standard-conforming implementation is going to have to give some degree of special treatment to main(), since it doesn't follow quite the same rules as normal C functions. The question has come up, can the main() function be invoked as a normal C function (i.e. recursively by the application). I think it is not guaranteed by the Standard; others think it is. This would be a good thing for X3J11 to address in the "interpretations" phase.
bill@twwells.com (T. William Wells) (08/18/89)
In article <1507@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
: In the previous operating systems I have used, the startup procedure was
: done by the loader. This is what is missing in UNIX; the loader does not
: have the capability to produce the startup program, so that must be explicitly
: put in.
I have worked on such systems. They are a royal pain in the ass if
you don't want to do exactly what the loader wants you to do.
Moreover, your point is irrelevant: one rarely needs to call the
loader directly. Most C compiler systems have some kind of front-end
program which handles (among many other things) the dirty work of
specifying the startup program. For all practical purposes, the
loader is called 'cc' (or something similar) and puts in the startup
program for you. Just like those old and grungy systems. Of course,
since cc isn't really the loader, if you have to do something
different, you can just call the loader directly with whatever
startup makes you happy.
On my machine, for example, if I compiled with -g, I am fairly sure
(*) I could massage the object files and produce a startup program
that knows how to call each global function in those files. I could
then link that function with my files and, there you have it, the
ability to call any function from the command line. On a UNIX system.
Of course, I'd never bother with such an absurdity.
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com
(*) I'm not sure if COFF files get the function argument types put
into the symbol table. If not, I rather suspect that it wouldn't be a
big deal to add this to the COFF format.jsb@advdev.LBP.HARRIS.COM (FLEA) (08/18/89)
# In article <10770@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
# >Speak for yourself. The C compiler I use at home processes the main()
# >pseudo-function differently from other functions, and in general any
# >Standard-conforming implementation is going to have to give some degree
# >of special treatment to main(), since it doesn't follow quite the same
# >rules as normal C functions.
I'm curious. What does your C compiler at home do differently with main()
and why is it a "pseudo-function"?
What different rules does it follow?
Jeff "Out-of-touch-with-standards-but-it-didn't-use-to-be-that-way" Barberbbadger@x102c.harris-atd.com (Badger BA 64810) (08/19/89)
In article <10770@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <2549@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >>You use significant names for the files of your programs, why shouldn't you >>use significant names for the main routines? > >main() certainly is a descriptive name for the role of that pseudo-function >within a C application. The application within its invocation context has >yet another, hopefully descriptive, name ("grep"?) or icon (smiling frog?) >or whatever. Descriptive of what? I guess if you do something often enough it begins to seem natural. Why should there even _be_ a distinguished main program? Consider the compress/uncompress program, which changes its function based on the argv[0] string. To me, this is a clever work-around to a problem which has no _need_ to exist -- just let the program have multiple entry points. I know, you have to get the shell to invoke the program at a particular entry point, but this can be worked out. > >>There really wouldn't be any much change to C. Even now, main() isn't >>treated specially by the C compiler. > >Speak for yourself. The C compiler I use at home processes the main() >pseudo-function differently from other functions, and in general any >Standard-conforming implementation is going to have to give some degree >of special treatment to main(), since it doesn't follow quite the same >rules as normal C functions. OK, but the only thing special about main() that I found in the gcc compiler source code was to prevent main() from being inline-d. Exactly what does your C compiler _do_ differently for main? I don't see why a compiler would care that crt0.o happens to call main() eventually. What's so different about main()? That is, what rules are you inferring? > >The question has come up, can the main() function be invoked as a normal >C function (i.e. recursively by the application). I think it is not >guaranteed by the Standard; others think it is. This would be a good >thing for X3J11 to address in the "interpretations" phase. On my system (HCX-9 running HCX/UX 3.0), you can call main() from main(): --- begin cut here --- /* Can main () call main() ? * Print out arguments in reverse order. */ #include <stdio.h> int main(argc, argv ) int argc; char *argv[]; { if (argc > 0) { main(argc - 1, &argv[1]); if (argc > 1) putchar(' '); printf("%s",argv[0]); } return 0; } --- end cut here --- But why not allow this as a main program?: --- begin cut here --- /* * Print out arguments in reverse order. */ #include <stdio.h> int reverse(argc, argv ) int argc; char *argv[]; { if (argc > 0) { reverse(argc - 1, &argv[1]); if (argc > 1) putchar(' '); printf("%s",argv[0]); } return 0; } --- end cut here --- 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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/19/89)
In article <10760@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <2538@trantor.harris-atd.com> bbadger@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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/19/89)
In article <8496@galbp.LBP.HARRIS.COM> jsb@advdev.UUCP (FLEA) writes: >I'm curious. What does your C compiler at home do differently with main() >and why is it a "pseudo-function"? >What different rules does it follow? int main(void) { ... } is required to work properly even when there are arguments that could have been passed to it. This is not true of genuine functions.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/19/89)
In article <2561@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >Exactly what does your C compiler _do_ differently for main? Apart from applying special interface rules, as described in a previous posting, this particular compiler generates the program entry point itself as part of the code generated for the main() pseudo-function.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/19/89)
In article <2563@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >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. I think this is another instance of fighting the language instead of working with it. I've never felt the need to "program around" C's use of main() as the entry point for (hosted) programs.
dworkin@Solbourne.COM (Dieter Muller) (08/19/89)
In <a whole bunch of articles> a bunch of folks have complained about not being able to specify a start-up function other than main () on Unix. Umm, folks? Stupid question time. What's wrong with ld's ``-e entry'' argument? This (or a variant thereof) has been in every version of Berkeley Unix I've seen, and I'm pretty sure it was in Version 6 (my manual is a few miles away at the moment). ``-e entry'' specifies the entry-point of the program as _entry_. We now return you to your regularly-scheduled C vs FORTRAN flame war. Dworkin -- "Your spatial laws are ok, but God, the choices you give us." -- Deborah Blau boulder!stan!dworkin dworkin%stan@boulder.colorado.edu dworkin@solbourne.com Flamer's Hotline: (303) 678-4624 (1000 - 1800 Mountain Time)
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/22/89)
In article <2043@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: >What's wrong with ld's ``-e entry'' argument? Two things: It's of no use for portable C programming; but more importantly, it bypasses the startup module that is necessary for the hosted environment to get set up properly (in many environments).
thomas@uplog.se (Thomas Hameenaho) (08/25/89)
In article <14269@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >[Name deleted on purpose] writes: >> I'm also a University's student in need of help. I always see that people >> define the function 'main' in C-programs. Why is that? What should it >> return? Can't I use another name? Text deleted. Second, it is not special-cased by the linker in any UNIX implementation I know of. Rather, there is a pre-main routine that calls main() just like a normal function. Execution begins at this pre-main routine, not because of a linker hack, but because when the `cc' command invokes `ld', it tells it the name of the entry-point label. The magic is in the driver program `cc'. Not always true either. COFF ld has the built-in rules: a) The value of the symbol specified with the -e option. b) The value of the symbol _start, if present. c) The value of the symbol main, if present. d) The value zero. In our Unix (V.2 for 68k) we are using the entry field in the COFF header. -- Real life: Thomas Hameenaho Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
thomas@uplog.se (Thomas Hameenaho) (08/25/89)
In article <1507@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
In the previous operating systems I have used, the startup procedure was
done by the loader. This is what is missing in UNIX; the loader does not
have the capability to produce the startup program, so that must be explicitly
put in.
This is actually a feature. You can do whatever you like in the startup
code. One example I'm familiar with is for cross-compiling and downloading
into a standalone system. The startup code initializes the hardware and
things.
--
Real life: Thomas Hameenaho Email: thomas@uplog.se
Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406
Box 1218 Fax: +46 18 132039
S - 751 42 Uppsala, Swedenpeter@ficc.uu.net (Peter da Silva) (08/26/89)
In article <THOMAS.89Aug25111034@uplog.uplog.se>, thomas@uplog.se (Thomas Hameenaho) writes: > This is actually a feature. You can do whatever you like in the startup > code. One example I'm familiar with is for cross-compiling and downloading > into a standalone system. The startup code initializes the hardware and > things. I know a guy who avoided having to write an assembler for a pcode language by defining the appropriate macros in m4 for as, assembling, linking (to resolve references), and using the resulting a.out. This would have been, to say the least, unpleasant if he had to deal with startup code. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'" -- Tom Neff 'U` "I didn't know that ksh had a built-in APL interpreter!" -- Steve J. Friedl
jeffrey@algor2.algorists.com (Jeffrey Kegler) (08/29/89)
In article <10781@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >I've never felt the need to "program around" C's use >of main() as the entry point for (hosted) programs. I have, occasionally. Consider a directory (bigapp.d) containing a large applications (bigapp), where you want you have some smaller associated utilities (ut1, ut2, ...) which use routines in bigapp. It does not always make sense to group the routines shared by the large application with one or more of the utilities into a library in a separate directory. Now bigapp.c, ut1.c, ut2.c, etc., each must have a main(). This is annoying for use with debuggers, cross-referencers, etc. In the above situation it makes a lot of sense to have each routine in bigapp.d named differently. It would be nice for the entry point for the ut1, ut2, ... executables to be named ut1(), ut2(), etc. The entry point in bigapp.c could be called main() or bigapp() depending on taste. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/29/89)
In article <1989Aug28.202551.9514@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >Now bigapp.c, ut1.c, ut2.c, etc., each must have a main(). This is >annoying for use with debuggers, cross-referencers, etc. If your debuggers etc. are that sick, then how in the world do you cope with using the same file-static variable and function names in different files? Really, I still don't see a problem with C and main(). There may be a problem with your other software development tools, though, if they can't handle such a simple thing.
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/31/89)
In article <10865@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1989Aug28.202551.9514@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >>Now bigapp.c, ut1.c, ut2.c, etc., each must have a main(). This is >>annoying for use with debuggers, cross-referencers, etc. > >If your debuggers etc. are that sick, then how in the world do you cope >with using the same file-static variable and function names in different >files? Really, I still don't see a problem with C and main(). There >may be a problem with your other software development tools, though, if >they can't handle such a simple thing. Of course, tools can do make-up fixes and kludge their way around a problem. Who needs ``for'' or ``while'' when you have ``if'' and ``goto''?? (:-)) This is the difference between ``unworkable'' and ``annoying''. But Mr. Gwyn is saying, ``What problem?'' It's kind of like having a tiny bubble in the lens of your glasses. It doesn't really interfere with your vision, and is hardly noticable unless you look directly at your glasses. Yet there are those of us who prefer to have our glasses without bubbles in the lenses. Some will say, ``But it's so small!'' Others will tell us to tip our heads and look through the top half of the lenses only. ``People who can't see over the bubble in their glasses don't know how to use their eyes.'' Well, it really is only a small detail, but it is a completely unnecessary implementation ``feechur'' which has, unfortunately, always been a part of the standard. I can't quite decide if Mr. Gwyn has actual reservations about doing without ``main()''. If the burden of proof was on putting ``main()'' into a new language, instead of taking it out of a language, how would you stand? Footnote: I see two distinct sides the problem of ``main()'': 1) Having to specify a single, fixed, main routine 2) Having to call the single, fixed, main routine, ``main''. (I'm making a distinction here between the ``main routine'' and the image entry point.) Side 1 probably deserves a separate thread, since the issues are more complex. Since most of the discussion to this point has been on side 2 of the problem, I've limite my comments in this article to side 2. I have assumed, for argument's sake, that the only thing we want to change about in: int main(int argc, char **argv, char **envp); is the name ``main''. ----- - - - - - - - ---- Bernard A. Badger Jr. 407/984-6385 |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.