On Thu, Oct 20, 2016 at 01:50:41PM +0200, Otto Moerbeek wrote:
> On Thu, Oct 20, 2016 at 11:28:37AM +0200, Otto Moerbeek wrote:
>
> > On Thu, Oct 20, 2016 at 11:21:26AM +0200, Otto Moerbeek wrote:
> >
> > > On Thu, Oct 20, 2016 at 11:17:25AM +0200, Otto Moerbeek wrote:
> > >
> > > > On Thu, Oct 20, 2016 at 04:42:13AM -0400, Ted Unangst wrote:
> > > >
> > > > > Otto Moerbeek wrote:
> > > > > > That is certainly not correct: snprintf and friends return the
> > > > > > length as
> > > > > > it would have been if an infinite buffer was passed in.
> > > > > > So the strlen should stay. I'll make a new diff soon though with the
> > > > > > error checking, although it might be overkill for this case.
> > > > >
> > > > > I think we're getting a little weird here. The circumstances under
> > > > > which
> > > > > snprintf can return -1 are quite limited.
> > > >
> > > > it can only happen on encoding errors, right? These are not relevant
> > > > in this case.
> > > >
> > > > -0tto
> > >
> > > But what happens if somebody creates an invalid encoded UTF8 __progname?
> > >
> > > -Otto
> >
> > It seems that as long as we use %s and not %ls we're safe.
> >
> > -Otto
>
> Hi,
>
> This morning I committed the diff but backed it out just a minute ago.
> There is a problem with the GC combination. This should fix it. The
> change is in omalloc() wrt the filling of the canary bytes. By
> compensating for mopts.malloc_guard in a wrong way I overwrote the
> wrong bytes.
>
> -Otto
Final diff is now in. To get wide test coverage, I recommend to
everyone (esp. on -current or snapshots) running with C, possibly
combined with J and or G:
# ln -s C /etc/malloc.conf
-Otto
