foreach

[H. S. Teoh via Digitalmars-d]

On Mon, Jun 16, 2014 at 06:37:56PM +0000, Wyatt via Digitalmars-d wrote:
> On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via Digitalmars-d wrote:
[...]
> >Or, on the flip side, functions with 10-15 parameters, each of which
> >influences which subset of the others actually have any effect.
> >
> Tame.  Gaze upon true horror:
> 
> #2  0x0809082c in stnz_sutrs (rec=0x461d550,
> app_context_arg=0x461dfd0, attribute_set=0x0, answer_complete=1,
> present_type=2, cgm=0, graphics=0, highlight_option=1,
> records_requested=1, current_field=76, num_fields=88,
> field=0x462a160, ans=0x0, database=0x45e0628 "REGISTRY",
> esn_list=0x461dd98, issue_break=0x461d754, callback=0x806f82d
> <display_next_answer>, callback_arg=0x461d668,
> field_callback=0x8087bff <field_formatter>,
> field_callback_arg=0x462adb8, callback_scheduled=0xfef92ac0, dg=0,
> dp=5, line_length=100) at stnz_sutrs.c:399

Whoa. I think I need therapy after reading this...


> Of course, most of those are passed directly from the parent frame
> with no changes at all. :V

The 10-argument function I alluded to actually gets called with unique
parameters each time... except that out of the space of possible
parameter values, only a small handful actually works ("works" as in, it
won't trigger a bug, do something unexpected, malfunction, corrupt the
database, or bring down the system), and good luck figuring out what
these combinations are (they involve very non-obvious values -- like
most of the parameters being NULL or 0 indicating they are unused, but
for the rest of them, 0/NULL is a meaningful value).

Not to mention, out of the few combinations that actually work, some
parameters are used with inconsistent meanings, and some parameter
values contradict each other (e.g. aFork == fork and create a new task;
aCreate == create a new task, so what does aFork=1, aCreate=0 mean??!
And no, the *actual* behaviour of the code has nothing to do with what
might be construed to be the most logical resolution of this antinomy).


> Enterprise code is probably worse than you think it is by nearly
> every metric you can think of.
[...]

Yep. I've seen C++ code where dtors perform useful computations, which
confounded me for weeks as to where in that piece of code the actual
work is done.

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!


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond