Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Apr 1997 17:37:04 +0400 (MSD)
From:      =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        cvs-all@FreeBSD.org, CVS-committers@FreeBSD.org, cvs-usrbin@FreeBSD.org
Subject:   Re: cvs commit:  src/usr.bin/vacation vacation.c
Message-ID:  <Pine.BSF.3.96.970425172901.2877A-100000@nagual.pp.ru>
In-Reply-To: <199704251158.VAA28172@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Apr 1997, Bruce Evans wrote:

> >So, right now we already have some sort of this support by default
> >based on current gcc behaviour. If this behaviour will be changed (more
> >general case you speak about), such compiler must support vfork
> >especially, i.e. not cross-optimizing, keeping stack frame, etc.
> 
> I just noticed that gcc already has some support.  Put back the vfork()
> in mount.c and compile with -Wall, and you will see the useful warnings
> that `optbuf' and `name' might be clobbered by `longjmp' or `vfork'.

It has more support than just a warnings, vfork calling function
marked and processed in the same way as setjmp calling function now
(returns twice). It looks like noop right now because we not turn
NON_SAVING_SETJMP define on. Perhaps we should turn it off for setjmp()
and on for vfork() separately.

-- 
Andrey A. Chernov
<ache@null.net>
http://www.nagual.pp.ru/~ache/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970425172901.2877A-100000>