I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main(). Is it a convention or is there
some deeper underlying reason?
Nov 14 '05
75  9782 
In article <gN********************@comcast.com> Joe Wright <jo********@comcast.net> writes: glen herrmannsfeldt wrote:
.... There is another reason to rename main, though, and that is the
ability to put multiple programs into a library.
It has never occurred to me to put complete programs in a library.
Why would you do that?
In some OS's (and I think Glen is describing one of them), a program
was processed either from a library (system or custom) or from your
current set of directly available files. So when you have a set of
commands you regularly use, you put those in a library, and put that
library in the search list.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hx********@cwi.nl... In article <72******************************@news.teranews.co m> "Stephen
Sprunk" <st*****@sprunk.org> writes: ... > Executables for the particular OS I checked (Linux) certainly have a
symbol > table: nm shows a _start near the beginning of every binary I checked.
> However, it just occured to me to strip a binary (not the default) and
the > symbol table does indeed disappear completely. Apparently the _start
symbol > isn't magical, so there must be something in the ELF (or whatever)
object > format that dictates entry at _start in my implementation.
No. Under Linux (and its Unix predecessors) execution starts at code
address 0 or somesuch. Indeed, a fixed address.
Linux will load ELF objects and begin execution wherever the ELF header
specifies. There may be common values for those addresses, but any value in
the first 2GB of virtual memory works on the i386 platform. I don't know
about other platforms Linux runs on, nor do I have any clue how COFF objects
work on i386.
[ Which, of course, means that _start is not meaningful to the loader and
therefore is specific to GCC on my platform -- something I hadn't bothered
to investigate before ]
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
On Mon, 17 May 2004 00:00:20 GMT,
Dik T. Winter <Di********@cwi.nl> wrote: In article <72******************************@news.teranews.co m> "Stephen Sprunk" <st*****@sprunk.org> writes:
... Executables for the particular OS I checked (Linux) certainly have a symbol
table: nm shows a _start near the beginning of every binary I checked.
However, it just occured to me to strip a binary (not the default) and the
symbol table does indeed disappear completely. Apparently the _start symbol
isn't magical, so there must be something in the ELF (or whatever) object
format that dictates entry at _start in my implementation.
For a dynamic linked program there is a separate symbol table for use by the
dynamic linker and that symbol table isn't removed by strip. Neither is
it shown using the nm program, only objdump -T will display it.
No. Under Linux (and its Unix predecessors) execution starts at code
address 0 or somesuch. Indeed, a fixed address.
Must by "somesuch" as address 0 does not become part of your program
under Linux.
The object contains some headers, and one of the fields of one of the headers
have the address of the entry point. This address is determined by the linker,
on unix usuly by specifying the -e option or if no -e option is specified the
address of a default symbol name becomes the entry point.
Things do get quite a bit more complicated for a dynamic linked program.
For thise program execution starts in the dynamic linker; the main program
would be pretty helpless until the dynamic linker has found and loaded
the C runtime library.
Villy
"Stephen Sprunk" <st*****@sprunk.org> wrote: "Dik T. Winter" <Di********@cwi.nl> wrote:
<snip> No. Under Linux (and its Unix predecessors) execution starts at code
address 0 or somesuch. Indeed, a fixed address.
Linux will load ELF objects and begin execution wherever the ELF header
specifies. There may be common values for those addresses, but any value in
the first 2GB of virtual memory works on the i386 platform. I don't know
about other platforms Linux runs on, nor do I have any clue how COFF objects
work on i386.
<OT>
FWIW, the COFF headers for program images contain a field called
'AddressOfEntryPoint', telling the loader the starting address
relative to the image base.
</OT>
Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
In <86************@lns-vlq-37-82-254-162-226.adsl.proxad.net> James Kanze <ka***@gabi-soft.fr> writes: Da*****@cern.ch (Dan Pop) writes:
|> In <f1********************************@4ax.com> Leor Zolman
|> <le**@bdsoft.com> writes:
|> >On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote:
|> >>"Keith Thompson" <ks***@mib.org> wrote in message
|> >>news:ln************@nuthaus.mib.org...
|> >>> "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
|> >>> [...]
|> >>> > No. Dan Pop gave the correct explanation. Execution does NOT
|> >>> > start with main(), but with the C runtime ("crt") code which
|> >>> > sets up a runtime environment for main(), e.g.,: initializing
|> >>> > argc, argv and envp.
|> >>> Execution of what? Execution of the user's program starts with
|> >>> main. What happens before that is implementation-specific; there
|> >>> may or may not be anything called a "C runtime".
|> >>Yet "something" has to pass argc and the argv[] array to main().
|> >>While not specifically defined, it IS guaranteed by K&R. I don't
|> >>know if there's a standard that says whether quotes should be
|> >>stripped from arguments (i.e. echo arg1 "arg2 has spaces" arg3)...
|> >Couldn't that "something" be the OS directly? It doesn't seem to me
|> >that there's anything that would preclude argc/argv being set up
|> >for a C (or whatever) program directly by the
|> >shell/command-processor, with the C-generated executable having an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^|> >entry point directly at the start of main().
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> This is a highly unrealistic approach.
So unrealistic that it is actually used by some OS's. Like all Posix
compliant systems, or Linux, for example.
Nope. None of them invokes the main function *directly*.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <86************@lns-vlq-37-82-254-162-226.adsl.proxad.net> James Kanze <ka***@gabi-soft.fr> writes: Da*****@cern.ch (Dan Pop) writes:
|> >> No. Dan Pop gave the correct explanation. Execution does NOT
|> >> start with main(), but with the C runtime ("crt") code which sets
|> >> up a runtime environment for main(), e.g.,: initializing argc,
|> >> argv and envp.
|> >where does it say this in the standard?
|> 5.1.2.2.1
|> The values of argc and argv must come from somewhere. This somewhere
|> is typically called the C runtime environment or C startup module.
Or the OS, or the invoking process, or ...
Concrete examples, please, but not *bogus* ones. Under Unix, main does
receive its arguments from the startup module and not from anything else.
It is the startup module that receives them from the invoking process, via
the OS, but this is NOT the same thing.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <86************@lns-vlq-37-82-254-162-226.adsl.proxad.net>, James Kanze <ka***@gabi-soft.fr> writes:
In practice, under Unix, it is the exec'ing process which sets up the
argc/argv for the invoked process.
Debatable. In Unix-like systems, the caller of the exec* family does
set the values used for argv, and by extension for argc, but IMO this
does not constitute "set[ting] up argc/argv for the invoked process".
The caller does not modify the invoked process's address space. It's
still up to the C startup code to create the actual parameter list for
main.
This leads to some interesting
questions: is it even possible to implement a hosted C under Unix, since
there is no way to ensure that argv[0] contains the program name (and in
fact, several common Unix programs count on the fact that it doesn't).
And of course, about all the standard requires is that argv[0] either
contain the program name, or be an empty string.
Since the standard does not define "program name", any non-empty
string is acceptable. In fact, as I read C90 5.1.2.2.1, the "program
name" is no more and no less than the contents of argv[0] (if argc >
0 and argv[0][0] != 0). Correspondence with any string known to the
OS or the user is felicitous but not required.
--
Michael Wojcik mi************@microfocus.com
The surface of the word "profession" is hard and rough, the inside mixed with
poison. It's this that prevents me crossing over. And what is there on the
other side? Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)
Joe Wright wrote:
(snip) There is another reason to rename main, though, and that is the
ability to put multiple programs into a library.
It has never occurred to me to put complete programs in a library. Why
would you do that?
For OS/360 and successors, through MVS, OS/390, z/OS...
the link editor has the ability to read its own output,
and the usual form of an object library is such output.
There are some cases where it is useful to store main programs
in such a library, and later link them with other subroutines,
either from a library or supplied by the user.
One might, for example, have a main program that would do
numerical integration or root finding on a supplied function.
Source for the function would then be linked with a main
program from a library and run.
As far as complete programs, not just main programs without
called subprograms, yes, OS/360 and successors store them
in libraries. Maybe similar to Java's jar files, a single
disk file contains multiple executable programs.
-- glen mw*****@newsguy.com (Michael Wojcik) writes:
|> In article
|> <86************@lns-vlq-37-82-254-162-226.adsl.proxad.net>, James
|> Kanze <ka***@gabi-soft.fr> writes:
|> > In practice, under Unix, it is the exec'ing process which sets up
|> > the argc/argv for the invoked process.
|> Debatable. In Unix-like systems, the caller of the exec* family does
|> set the values used for argv, and by extension for argc, but IMO
|> this does not constitute "set[ting] up argc/argv for the invoked
|> process". The caller does not modify the invoked process's address
|> space. It's still up to the C startup code to create the actual
|> parameter list for main.
At least in some older Unix, the parameters to exec were copied directly
into the new program stack by the OS. All the start up routine did with
them was pass the argc and the argv on.
|> > This leads to some interesting questions: is it even possible to
|> > implement a hosted C under Unix, since there is no way to ensure
|> > that argv[0] contains the program name (and in fact, several
|> > common Unix programs count on the fact that it doesn't).
|> > And of course, about all the standard requires is that argv[0]
|> > either contain the program name, or be an empty string.
|> Since the standard does not define "program name", any non-empty
|> string is acceptable. In fact, as I read C90 5.1.2.2.1, the "program
|> name" is no more and no less than the contents of argv[0] (if argc >
|> 0 and argv[0][0] != 0). Correspondence with any string known to the
|> OS or the user is felicitous but not required.
Well, I guess that's one way of looking at it. So the program we
generally call bash has the name -bash when started by login.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
In <B87qc.68938$iF6.5833885@attbi_s02> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes: As far as complete programs, not just main programs without
called subprograms, yes, OS/360 and successors store them
in libraries. Maybe similar to Java's jar files, a single
disk file contains multiple executable programs.
Probably as a lame compensation for not providing a decent hierarchical
file system. Such a file could be considered as a poor surogate of a
directory.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: In <B87qc.68938$iF6.5833885@attbi_s02> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
As far as complete programs, not just main programs without
called subprograms, yes, OS/360 and successors store them
in libraries. Maybe similar to Java's jar files, a single
disk file contains multiple executable programs.
Probably as a lame compensation for not providing a decent hierarchical
file system. Such a file could be considered as a poor surogate of a
directory.
Well, yes, there is that. Though the 44 character names were
long enough for fake hierarchy in many cases.
Still, the idea of keeping related programs together in one
file seems useful. Unix has ar files for libraries.
Though #include files tend to be in a directory structure
as separate files.
-- glen
Dan Pop wrote: glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
As far as complete programs, not just main programs without
called subprograms, yes, OS/360 and successors store them
in libraries. Maybe similar to Java's jar files, a single
disk file contains multiple executable programs.
Probably as a lame compensation for not providing a decent
hierarchical file system. Such a file could be considered as a
poor surogate of a directory.
Back in CP/M days, shortly after .LBR files appeared, people began
packing executables into them. Then the LRUN program appeared, to
extract and run a particular component from COMMAND.LBR. Even
later my CCPLUS incorporated that function, together with a search
path, into the 'shell'. Similar things were done with interpreted
executables, using PCDS.LBR. I had systems using the same format
as conventional searchable libraries for object code modules.
There is very little new under the sun.
All these packages provided a convenient way to supply a set of
utilities to the user.
Those interested can explore the download/cpm/ area of my site,
below.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Tue, 18 May 2004 18:43:05 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote: Though #include files tend to be in a directory structure
as separate files.
if anyone remembers VMS, they'll recall that all the system headers were in
a text library, a file with a .tlb extension. The C compiler knew
automagically how to read out the relevant block of data at runtime.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre wrote: On Tue, 18 May 2004 18:43:05 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote:
Though #include files tend to be in a directory structure
as separate files.
if anyone remembers VMS, they'll recall that all the system headers were in
a text library, a file with a .tlb extension. The C compiler knew
automagically how to read out the relevant block of data at runtime.
Someday I might have a running MicroVAX running VMS,
and some compilers under the hobbyist license.
I did some C under VMS many years ago. The most interesting
one is the messages you get out from exit() for arguments
other than 0. I had a program with exit(8) and it took
me a while to understand the message that came out.
-- glen
In <ZOsqc.73130$536.11864898@attbi_s03> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes: Still, the idea of keeping related programs together in one
file seems useful. Unix has ar files for libraries.
Though #include files tend to be in a directory structure
as separate files.
ar files are for linker consumption, while header files are for compiler
and human consumption. Furthermore, there is no one-to-one correspondence
between them. So, the different handling makes sense.
The Unix model is quite popular on non-Unix systems, too, except that
ar files are called, usually, libraries (ar stands for "archiver" and the
..a suffix for "archive").
Another Unix oddity is the usage of the "lib" *prefix* in the name of
archives built for linker consumption: this prefix is omitted, along
with the .a suffix, when the linker is asked to search a library using
the -l option: to include libm.a in the linking process (it contains
the <math.h> stuff and is not searched by default) you have to use
the -lm option.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Beni wrote: I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main(). Is it a convention or is there
some deeper underlying reason?
I love reading all of the wanking on this thread regarding "hosted
implementations" and the CRT.
An executable image gets loaded by the OS and somewhere in the image, there
has to be a starting point, usually denoted in the header. The OS jumps to
the starting points address after the image is loaded into memory (today,
this also means dynamically linking libraries too and a lot of other
garbage.) But in C terms, the starting point is an address (pointer to fcn
returning int). return (*entry_point)(). BFD.
This starting point gets set by the linker (loader or linking loader in
years gone by). The C compiler frontend adds the symbol name of that
starting point to the linker command line when the objects are linked into
an executable. Now, pick a name for that starting point -- "main" sounded
like a good one and it stuck. Worse yet, the CRT is generally now the entry
point and the CRT expects to call main as a function.
Why is the user's entry point called "main"? It could have been something
else entirely, but at the time of PDP-11s and early Unix/C, the "main entry
point of the program" was a phrase in common usage.
On Tue, 18 May 2004 22:44:41 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote: Mark McIntyre wrote:
On Tue, 18 May 2004 18:43:05 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote:Though #include files tend to be in a directory structure
as separate files.
if anyone remembers VMS, they'll recall that all the system headers were in
a text library, a file with a .tlb extension. The C compiler knew
automagically how to read out the relevant block of data at runtime.
Someday I might have a running MicroVAX running VMS,
and some compilers under the hobbyist license.
can you do that? point me at a url, my office has a stack of VMS
workststions its junking, I could have hours of fun...
I did some C under VMS many years ago. The most interesting
one is the messages you get out from exit() for arguments
other than 0. I had a program with exit(8) and it took
me a while to understand the message that came out.
Same with return (somedigit) from main.-- glen
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre wrote: glen herrmannsfeldt <ga*@ugcs.caltech.edu> wrote:
.... snip ...
Someday I might have a running MicroVAX running VMS,
and some compilers under the hobbyist license.
can you do that? point me at a url, my office has a stack of VMS
workststions its junking, I could have hours of fun...
You may get a lot of interest in those from a.f.c, to which I have
cross-posted this.
(Mark is in the UK)
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote: Another Unix oddity is the usage of the "lib" *prefix* in the name of
archives built for linker consumption: this prefix is omitted, along
with the .a suffix, when the linker is asked to search a library using
the -l option: to include libm.a in the linking process (it contains
the <math.h> stuff and is not searched by default) you have to use
the -lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
It relies on a naming convention that should be universally followed, and
the desire avoid typing boilerplate. Assuming all library files are named
following the libfoo.a scheme, only the foo part is at all meaningful to
the human linking the program: It is, or should be, predictable from the
headers you included or the naming scheme of the functions you called, and
it certainly should be trivially derived from the full name of the
collection of code you just called into.
Therefore, stripping the first and last bits off ought to leave the poor
typist compiling programs all day (and recall, Unix was designed for poor
typists ;-)) with something short and memorable to put behind that -l flag.
(Not scanning libm.a by default might arguably be a bug in this age of
cheap clock cycles and the possibility of intelligent linkers, but that's
a different Holy War.)
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
In <fr********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes: On Tue, 18 May 2004 22:44:41 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote:
Mark McIntyre wrote:
On Tue, 18 May 2004 18:43:05 GMT, in comp.lang.c , glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote:
Though #include files tend to be in a directory structure
as separate files.
if anyone remembers VMS, they'll recall that all the system headers were in
a text library, a file with a .tlb extension. The C compiler knew
automagically how to read out the relevant block of data at runtime.
Someday I might have a running MicroVAX running VMS,
and some compilers under the hobbyist license.
can you do that? point me at a url, my office has a stack of VMS
workststions its junking, I could have hours of fun...
Lots of hours, indeed, given the speed of these things...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@sig.now> August Derleth <se*@sig.now> writes: On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote:
Another Unix oddity is the usage of the "lib" *prefix* in the name of
archives built for linker consumption: this prefix is omitted, along
with the .a suffix, when the linker is asked to search a library using
the -l option: to include libm.a in the linking process (it contains
the <math.h> stuff and is not searched by default) you have to use
the -lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
Well, I was not attacking it in the first place... But since you want
to defend it: what's the point of having the lib prefix in the first
place, as long as the purpose of the file can be derived from the suffix
alone?
(Not scanning libm.a by default might arguably be a bug in this age of
cheap clock cycles and the possibility of intelligent linkers, but that's
a different Holy War.)
It's not as much an issue of cheap clock cycles as it is of fast disks.
Back when it was not uncommon to have a floppy disk as your fastest
I/O device, any such optimisations made perfect sense. Nowadays, they
mere reflect the stubborness of a few people who think that whatever
was the right thing 30 years ago *must* be the right thing today.
Back then, the "standard" C library was contained in two library files,
libc.a and libm.a that were covered by two headers, <stdio.h> and
<math.h>. For obvious reasons, libm.a wasn't searched by default
(I can't remember writing a single *production* Unix program including
<math.h> and I guess I'm not alone). By the time the one-to-one
correspondence between headers and library files was broken, treating
the <math.h> stuff in a special manner at link time started to make less
sense than before. In time, it made less and less sense...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: August Derleth <se*@sig.now> writes: On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote:
Another Unix oddity is the usage of the "lib" *prefix* in the
name of archives built for linker consumption: this prefix is
omitted, along with the .a suffix, when the linker is asked to
search a library using the -l option: to include libm.a in the
linking process (it contains the <math.h> stuff and is not
searched by default) you have to use the -lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
Well, I was not attacking it in the first place... But since
you want to defend it: what's the point of having the lib prefix
in the first place, as long as the purpose of the file can be
derived from the suffix alone?
I think historically .a (archive) files were used for other
purposes, much as tar and zip are today. Only some of these were
object libraries.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
On Fri, 21 May 2004 14:56:23 +0000, Dan Pop wrote: In <pa****************************@sig.now> August Derleth <se*@sig.now>
writes:
On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote:
Another Unix oddity is the usage of the "lib" *prefix* in the name of
archives built for linker consumption: this prefix is omitted, along
with the .a suffix, when the linker is asked to search a library using
the -l option: to include libm.a in the linking process (it contains
the <math.h> stuff and is not searched by default) you have to use the
-lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
Well, I was not attacking it in the first place... But since you want
to defend it: what's the point of having the lib prefix in the first
place, as long as the purpose of the file can be derived from the suffix
alone?
As CBFalconer said, the ar archiver was used for other things before tar
became widespread enough to be the archiver of choice. (Although seeing
shell archives is more common among old Unix source archives, a shell
archive is really just a shell program. You can see the potential for
abuse.)
Secondly, it's more common for extensions to describe the format of a file
and not its use. (Except for executable files, which ideally shouldn't
have extensions at all, no matter what they look like internally.)
So, really, it's the same reason the compilers don't scan libm.a by
default: Tradition.
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote: August Derleth <se*@sig.now> writes: On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote:
Another Unix oddity is the usage of the "lib" *prefix* in the
name of archives built for linker consumption: this prefix is
omitted, along with the .a suffix, when the linker is asked to
search a library using the -l option: to include libm.a in the
linking process (it contains the <math.h> stuff and is not
searched by default) you have to use the -lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
Well, I was not attacking it in the first place... But since
you want to defend it: what's the point of having the lib prefix
in the first place, as long as the purpose of the file can be
derived from the suffix alone?
I think historically .a (archive) files were used for other
purposes, much as tar and zip are today.
AFAIK, ar and tar must be roughly of the same age and tar is the one
supposed to be used for other purposes than archiving on tapes.
But there may have been a time window when ar was and tar wasn't...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@sig.now> August Derleth <se*@sig.now> writes: On Fri, 21 May 2004 14:56:23 +0000, Dan Pop wrote:
In <pa****************************@sig.now> August Derleth <se*@sig.now>
writes:
On Wed, 19 May 2004 14:32:31 +0000, Dan Pop wrote:
Another Unix oddity is the usage of the "lib" *prefix* in the name of
archives built for linker consumption: this prefix is omitted, along
with the .a suffix, when the linker is asked to search a library using
the -l option: to include libm.a in the linking process (it contains
the <math.h> stuff and is not searched by default) you have to use the
-lm option.
As long as we're [OT], I might as well defend this behavior. ;-)
Well, I was not attacking it in the first place... But since you want
to defend it: what's the point of having the lib prefix in the first
place, as long as the purpose of the file can be derived from the suffix
alone?
As CBFalconer said, the ar archiver was used for other things before tar
became widespread enough to be the archiver of choice. (Although seeing
shell archives is more common among old Unix source archives, a shell
archive is really just a shell program. You can see the potential for
abuse.)
Secondly, it's more common for extensions to describe the format of a file
and not its use. (Except for executable files, which ideally shouldn't
have extensions at all, no matter what they look like internally.)
Unix doesn't use file extensions at all...
Then, pray tell, what are the prefixes used in conjunction with the .tar
suffix? How about the .c or .o suffix?
The common convention is that the name of the directory containing a file
together with the file name suffix provide an indication about the file's
use. So, if the directory name is "lib" and the suffix is .a, the "lib"
prefix is as redundant as you can get.
So, really, it's the same reason the compilers don't scan libm.a by
default: Tradition.
Nope: you can't *explain* tradition by invoking it ;-)
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Mon, 17 May 2004 00:40:46 GMT, "Stephen Sprunk"
<st*****@sprunk.org> wrote: "Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hx********@cwi.nl... In article <72******************************@news.teranews.co m> "Stephen
Sprunk" <st*****@sprunk.org> writes:
<snip> No. Under Linux (and its Unix predecessors) execution starts at code
address 0 or somesuch. Indeed, a fixed address.
Linux will load ELF objects and begin execution wherever the ELF header
specifies. There may be common values for those addresses, but any value in
the first 2GB of virtual memory works on the i386 platform. I don't know
about other platforms Linux runs on, nor do I have any clue how COFF objects
work on i386.
M$ PE~COFF (at least) does have a start-address field.
However, *original* Unix did start at virtual 0 -- and "a.out" format
began with an 8-word header whose first word was (always) 0407, the
PDP-11 instruction to branch over the 7 remaining words to the first
actual code (thus) always at virtual byte 020. AFAICT, this plus ar
originated the now-hoary convention of identifying file formats by a
"magic number" in the first 2 or nowadays often 4-8 bytes.
- David.Thompson1 at worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: subrat |
last post by:
Hello,
I know that the main( ) function is the starting point of execution in a C++
program.
What if an object is in the global space before main()?
Where is the constructor of the class object...
|
by: JohnQ |
last post by:
The way I understand the startup of a C++ program is:
A.) The stuff that happens before the entry point.
B.) The stuff that happens between the entry point and the calling of
main().
C.)...
|
by: itsraghz |
last post by:
Dear All,
I have an issue with destroy() method of java.lang.Process class. All what I am trying to do is, controlling the execution of one program through another. Let's say, Program B has to be...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
