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 ;) > ... But there are > several issues here: > 1) vararg calls with non-pmc registers involved I already did propose the syntax: .sub prototyped var_args If the HLL can't provide this information, we could use the opposite: .sub prototyped fixed_args at least, so that runtime checks can be omitted for certain cases. > 2) Runtime modification of sub definitions are evil, forbidden, disallowed. This just can't work. > 3) Drift in interface definitions needs code adaption and recompiling. > ... 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. > 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. The main program has something like: load_lib "mylib", "0.22" If the lib version doesn't match, we spit out a warning. If the lib is compatible the code can get adjusted to read: load_lib "mylib", "0.22-0.24" There could be some implicit rules, that state, e.g. versions with the same major version numbers are compatible by default. Module authors and users have responsibilities, which we can't solve with runtime checks. > Dan leo
