foreach

[Wyatt via Digitalmars-d]

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