Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!swrinde!elroy.jpl.nasa.gov!usc!apple!agate!usenet
From: raymond@math.berkeley.edu (Raymond Chen)
Newsgroups: comp.lang.c
Subject: Re: An Ubiquitous C bug
Message-ID: <1991Jan25.195914.16067@agate.berkeley.edu>
Date: 25 Jan 91 19:59:14 GMT
References: <s64421.664471332@zeus> <156097@felix.UUCP> <14975@smoke.brl.mil>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: raymond@math.berkeley.edu (Raymond Chen)
Organization: U.C. Berkeley
Lines: 23
In-Reply-To: gwyn@smoke.brl.mil (Doug Gwyn)

In article <14975@smoke.brl.mil>, gwyn@smoke (Doug Gwyn) writes:
>a trivial way to satisfy the constraint would be to link a
>startup object module first, and that is probably what the compiler manuals
>say to do.

Pardon me for injecting facts into the discussion, but here's a quote
from the Turbo C manual; namely, the section titled, `Using TLINK with
Turbo C Modules':

    The general format for linking Turbo C programs with TLINK is

      tlink C0x <myobjs>, <exe>, [map], <mylibs> [emu|fp87 mathx] Cx

    where:
      C0x = initialization module for memory model t, s, c, n, l or h.

    The initialization module <<must appear as the first object
    file in the list>>.  [emphasis mine]

Consequently, anybody who doesn't list C0x first is not following
the instructions and therefore deserves whatever he gets.

We now return you to the petty bickering, already in progress.