Re: Different C runtime libraries

Igor Tandetnik wrote:
> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
> news:%23RFb0dmhFHA.1412@xxxxxxxxxxxxxxxxxxxxxxx
>>> Again, under this theory, neither my LIB nor yours should expect any
>>> particular CRT implementation. The LIB advertises that it requires
>>> an external function named fopen
>>
>> Named fopen. That's it. There is no information in C beyond the name.
>>
>>> with a particular signature
>>
>> In C++ only.
>>
>>> (that's how
>>> OBJs and LIBs work already). The linker ultimately decides how to
>>> satisfy this requirement.
>>
>> Precisely. And because there is no information about data
>> representation, semantics (MT vs. ST) etc. the linker cannot make
>> this choice.
>
> The programmer setting up the EXE project makes this choice for the
> linker, by specifying which CRT flavor she wants to link the whole
> thing against. It is at this point that /MT or /ML or whatever is
> specified. Again, the idea is that individual LIBs would work with
> whatever setting is chosen for the EXE - they do not force one
> themselves. At least not explicitly - perhaps an accompanying
> documentation would mention that a particular library only works with
> certain CRT flavors (e.g. multithreaded only), and it would be up to
> the user to choose a CRT flavor that works for all LIBs she plans to
> use.

Well, if you are talking about physical *possibility* of linking an
executable in such a way then, of course, it is possible. Would the
resultant executable work without problems? Very likely not.

>>>> I bet there will be problems. For better or worse my FILE may be
>>>> different from your FILE and they expect different fprintfs.
>>>
>>> Your library code does not depend on the internals of FILE, right?
>>
>> It does every time I call putc() for example (IIRC - it was a long
>> time since I looked at its source).
>
> But the implementation of putc comes from the same CRT library as the
> implementation of fopen - surely the two would agree on the definition
> of FILE.

[...]

> Again, all this disregards the possibility of putc being implemented
> as a macro (or inline function or intrinsic), which, as I believe we
> agree, would render the technique nonviable and the discussion moot.

putc is a macro (IIRC). That's the whole point. When I write and compile my
lib I use various CRT facilities like putc, malloc etc. which are expanded
by preprocessor or compiler before linker is involved in any way. Actually
the distinction between preprocessor, compiler, linker and loader is very
blurred today. From my point of view there is an opaque "build" that results
in a running process. After one part of "build" (for example creation of a
static lib) is done the result is in some way "bound" to the particular
static libs that were used. Any attempt to use a different set for other
"build" stages will most likely not work.

>>> It
>>> only ever manipulates FILE*. These are, at the binary and linker
>>> level, independent of CRT flavor.
>>
>> Only in an ideal world where FILE * is truly abstract. Unfortunately
>> it is not.
>
> I don't quite understand this statement. Can you show some legal code
> that relies on the definition of FILE structure, and would break if
> said definition changes (assuming that the implementation of all CRT
> functions taking FILE* as a parameter changes at the same time to
> accomodate the new definition)?

putc('a')

(assuming putc is a macro which it most likely is)

>> I cannot recall a single CRT item that could qualify for being truly
>> interface-only. There are lots of pure functions (like strcpy()) but
>> every time there is some state it "leaks" using your term to headers.
>
> Again, can you show an example? Perhaps I'm missing something obvious.

For example CRT headers were to declare something like

typedef struct FILE FILE;

and use FILE * exclusively it would be an interface. Unfortunately the
contents of FILE are visible to client code and used in macros. Another
example is malloc()/free(). Depending on how you compile the malloc may
become _malloc_dbg (typing from memory) and I am not sure that free() can
free what is being allocated by _malloc_dbg. (Even if it can this isn't a
good thing to rely on)


--
Eugene
http://www.gershnik.com


.

Relevant Pages

  • Re: Linkerproblem, wenn wmain/wWinMain in Lib stecken
    ... Von einer CRT steht da nämlich nichts, und man benötigt auch gar keine für reines Win32. ... Das VS hat in den beiden Testprojekten diesen Schalter automatisch gesetzt, trotzdem durchsucht der Linker nicht die Lib nach wmain bzw. wWinMain. ...
    (microsoft.public.de.vc)
  • Re: Linkerproblem, wenn wmain/wWinMain in Lib stecken
    ... Von einer CRT steht da ... Compiler erzeugt wurde auch immer mit der passenden CRT ... trotzdem durchsucht der Linker nicht die Lib nach ...
    (microsoft.public.de.vc)
  • Re: Linker-Error LNK2005: Symbol already defined
    ... dass VS bzw. der Linker die CRT immer vor meiner Lib linkt. ...
    (microsoft.public.de.vc)
  • Re: statische Libs
    ... bevorzuge grundsätzlich die CRT-Version als gesharte DLL. ... Die CRT wird in keinem fall in die lib aufgenommen sondern Deine Objekt ...
    (microsoft.public.de.vc)
  • Re: statische Libs
    ... >> statischen Lib auf eine nur deklarierte Funktion zugreifen die dann ... Warum nicht auch mit der CRT? ... > Weil im schlechtesten Fall Dein Programm abraucht. ...
    (microsoft.public.de.vc)
Loading