On Fri, 14 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I've seen it with some depressing regularity over the years. It generally
> > takes the form of an upgrade to a library that breaks existing
> > executables, something we're going to have to deal with as we're looking
> > to encourage long-term use of bytecode-compiled programs.
>
> This seems to me the same, as that strcpy(3) should be guarded against
> wrong argument count at runtime. But swapped destination/source can't be
> detected anyway ;)
We can't detect bugs like that, true. But we can detect when someone calls
us with two arguments and someone has, in the mean time, "helpfully" added
an optional length arg to strcpy.
> > ... But there are
> > several issues here:
>
> > 1) vararg calls with non-pmc registers involved
>
> I already did propose the syntax:
[Snip]
> at least, so that runtime checks can be omitted for certain cases.
No IMCC syntax that's purely compile-time is of any help here. The code
doing the calling
> > 2) Runtime modification of sub definitions
>
> are evil, forbidden, disallowed. This just can't work.
True, false, false. It happens, in some cases a *lot*. This is perl,
python, and ruby we're talking about, where changing the definition of a
sub is as trivial as a reference assignment into a global hash. It's easy,
people do it. Often, in some cases. (Heck, I've done it)
Methods also cause significant headaches, since there are *no* signatures
available to the calling code, as there's no way for it to look up the
signature. (And yeah, that's a reasonable argument for all method calls to
be unprototyped, but I'm not sure I want to place that restriction in
right now)
> > 3) Drift in interface definitions
>
> needs code adaption and recompiling.
To operate properly, yes. To fail properly, no.
> > ... Because of that we have to pass in sufficient information to
> > validate things at the interface, which means at least arg counts.
>
> If someone changes libc behind the curtain in an incompatible way,
> existing programs probably just segfault.
Yes, they do. For us that's unacceptable--we have to be able to let code
provide at least some boundary guarantees with safe failure modes.
> > If someone wants to propose we have an alternate, more static convention
> > that lends itself better to one-off static linking with link-time
> > signature checking for verification, which is what the complaints all seem
> > to allde to, well... go ahead and if you do we'll see where we go from
> > there.
>
> e.g. version checking at program load.
Which doesn't solve the problem. Ask for version 1.20 or higher, get
version 1.33, and find the interface has changed. (An interface that was
fine in versions 1.20 through 1.32) This happens, with some frequency.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
