William Kucharski wrote:
>> Garrett D'Amore wrote:
>> Having an old binary on Solaris stop working would, I think, be bad news.
Garrett didn't write those words. I did.
> But at the same time, to stop working that old binary would have to use a
> construct that has been explicitly documented to NOT necessarily work in
> Solaris (and before that SunOS) for at least 20 years.
Indeed. And we have examples of such programs, and the usage case
itself is "obvious" to programmers familiar with it.
> This strikes me as similar to the issue that occurs when a programmer moves
> from a system that has historically zeroed automatic variables as a side
> effect of its implementation to one that doesn't and their programs break (or
> alternatively, one that needed "-fwritable-strings" to avoid crashing when
> compiled with gcc.)
In 30-odd years of coding, I've never encountered a system that zeros
out stack allocations as a matter of course. New pages, sure, but all
variables, even in previously written parts of a stack page? But that
small issue aside, I don't agree.
This is quite different. Assuming that this will "work" is indeed silly:
int i;
i += 5;
Even programmers of modest skill know the problems with "uninitialized
variables." And decent tools will warn users about the problem.
But except for specmanship, it's unclear why programmers should have
assumed that the following will work *sometimes* and simply corrupt
memory silently at other times:
/* delete third character in buffer */
strcpy(buf + 2, buf + 3);
And neither compilers nor lint will warn.
> I understand the argument for fixing this, but where do you draw the line in
> supporting code that broke because "undefined" happened to work in its favor
> in the past and no longer does?
For five reasons I can think of:
- The usage (wrong or not) is known to exist in the field. That's
how this whole discussion started.
- The failure case doesn't just make the program break; it works
most of the time, and every once in a while causes data corruption.
- The usage (ignoring the language in the man page) is obvious and not
unreasonable as an expectation based on older K&R documents.
- The legal alternatives are far uglier.
- The available tools are inadequate to warn of the problem. I doubt
that even valgrind (if we had it) would catch this one.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
