Re: CVS commit: src/dist/cdk

[Alistair Crooks <agc%wasabisystems.com@localhost>]

On Fri, Aug 29, 2003 at 11:20:21AM +1000, matthew green wrote:
> 
>    On Thu, Aug 28, 2003 at 02:56:36PM +0100, David Laight wrote:
>    > On Thu, Aug 28, 2003 at 11:32:34AM +0000, Alistair G. Crooks wrote:
>    > > 
>    > > Module Name:   src
>    > > Committed By:  agc
>    > > Date:          Thu Aug 28 11:32:34 UTC 2003
>    > > 
>    > > Modified Files:
>    > >        src/dist/cdk: scroll.c
>    > > 
>    > > Log Message:
>    > > Use bounded string op (snprintf instead of sprintf) for an automatic
>    > > array which is used to calculate the maximum width of a scroll entry
>    > > item.  Previous use of sprintf would blindly overwrite the stack if
>    > > there were more than 100 characters in an entry item.
>    > 
>    > Mmmm - so now it silently discards anything longer than 100 chars.
>    > Is that really a fix?
>    
>    It means you won't get a core dump if you give it a line longer than
>    96 characters. So, yes, it's really a fix.
> 
> 
> is switching from known data loss to silent data loss really a fix?

You make it sound like I should be happy that my application exits with
a message saying "Core dump. Your fault", and the core dump itself is
useless because the shared library function has overwritten the stack.
As an addendum to this, when are we going to start shipping debug
versions of system libraries?

The cdk library has other features, too - add more than 2000 items to
a scrollable region and it will run (FSVO "run"), but not give the
expected results, since bounds are not checked.  More than 2000
entries in a scrollable region isn't the greatest idea in UI, but
that's beside the point.  Since this is a dist/reachover style piece
of software, I tried to make as few changes as possible.

Consider the sysinst bug that dsl fixed recently - in the good old
days, when we had "known data loss", and people's first introduction to
NetBSD was a core dump in the middle of a system installation,
everyone was much happier.

We could have a long, philospophical argument about whether it's better
to have "known data loss" or not, but I'll pick a program that runs to
completion any time.

Now, haven't you got some work to do? :-P :-)