On Monday, 16 June 2014 at 20:32:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
Another recent "enterprise" nastiness I ran into: having
several functions with identical name in the source tree, each
of which does something completely different, and which one
ends up in the executable depends on which library you link
(this is C btw, there's no function overloading here -- you
just end up passing arguments of the wrong types to the wrong
function). To add salt to the wound, the calls to this
function are inside a library (let's call it libX). So if your
program links libX and libY, then you're fine, but if your
program links libX and libZ, then it will produce subtle,
almost untraceable memory corruption errors due to passing an
int to a function that expects a pointer. But since one of
these functions is compiled as a weak symbol, so if you link
*both* libY and libZ with libX, it mysteriously starts working
again!
Bah, we can go deeper! So you have different compilation units
with different implementations of the same function. Say,
alloc_vc(). Now, there are actually five different
implementations of this with generally identical signatures,
right down to the argument names and types. Actaully, the
implementations are largely similar-if-not-quite-identical now
that I adjusted them to all use calloc() (aside: stupid Solaris
nulls all allocations even with malloc() and enterprise-grade
programmers WILL rely on this behaviour). Then things get weird:
one of the arguments is of type VC. This is an issue because
that typedef appears ELEVEN TIMES, and the struct ranges from 5
to 35 members. I had to take a walk and clear my head when I
first ran into that.
</commiseration>
-Wyatt
