std library hooks

[H. S. Teoh]

On Sun, Apr 15, 2012 at 03:05:36PM +0300, Manu wrote:
[...]
> That said, all of that does not match my observation with the VC
> linker.  I defined atoi locally, but it complained straight up. If it
> was selectively pulling objects containing unresolved symbols from the
> lib, I shouldn't have seen that error I pasted above, since the symbol
> was already defined within the object that referenced it, it shouldn't
> have tried to pull atox.obj...

What I described earlier is the behaviour of the unix ld. I don't know
how the VC linker works; it may resolve symbols in a different way.

But assuming it does work like ld, then your problem could be caused by
atoi being defined in an object file that also exports another symbol
that your program uses elsewhere. For example, if x.obj (just making
that up for illustration purposes) exports both atoi and strtoul, then
if you define atoi yourself but not strtoul, if your program somewhere
calls strtoul (directly or indirectly -- you may be calling another
library function that indirectly calls strtoul, for example), then the
linker will try to link in x.obj, and then it will complain that x.obj's
atoi conflicts with your version of atoi.


> I'm still going to put all of this down as 'very unpredictable' to
> anyone who isn't a compiler author, and suggest that maybe if we want
> the formal ability to override some of the basic druntime functions
> (malloc/file/assert, etc), we should either make an API to register
> hooks (like the deprecated assert hook), or at least mark the symbols
> that are safe to replace as weak, and document it.

IMO, it's safer to provide hooks. Marking symbols as weak is dangerous
for functions that depend on each other. For example, free() may depend
on the exact implementation of malloc(); if you make malloc and free
weak symbols, then you have the possibility that somebody may redefine
malloc but not free, which leads to runtime memory corruption and/or
crashes. They really should be replaced completely if you're going to
replace them, not piecemeal.

Alternatively, if there is a fixed API for, say, the GC or malloc/free
(i.e. they exist in their own object file with a well-known list of
exports), then you can replace them by substituting your own version of
all the exported functions. As somebody mentioned, if dmd always puts
druntime at the end of the command-line, then your version of the
functions should get picked up before the linker sees the druntime
version (which shouldn't get linked 'cos at that point you've already
resolved all symbols that may have pulled in that object file).


T

-- 
Life would be easier if I had the source code. -- YHL