Re: Improve vi(1) recovery

2021-08-19 Thread Theo de Raadt
+h_alrm(int signo) +{ + GLOBAL_CLP; + + F_SET(clp, CL_SIGALRM); F_SET is |=, which is not atomic. This is unsafe. Safe signal handlers need to make single stores to atomic-sized variables, which tend to be int-sized, easier to declare as sig_atomic_t. Most often these are global

Re: Improve vi(1) recovery

2021-08-19 Thread trondd
I've switched this to using alarm(3) instead of setitimer(2) which is a little simpler in the code but most of the changes are just vi event handling boilderplate. There is very little new functional code. Original investigation write-up follows. Have had quite a bit of user feedback and

Re: Improve vi(1) recovery

2021-05-09 Thread trondd
trondd wrote: > trondd wrote: > > > trondd wrote: > > > > > > > > While investigating an occasional crash when recovering a file with 'vi > > > -r' > > > after a power failure, I noticed that the recovery files are actually > > > never > > > updated during an editing session. The

Re: Improve vi(1) recovery

2021-04-19 Thread trondd
trondd wrote: > trondd wrote: > > > > > While investigating an occasional crash when recovering a file with 'vi -r' > > after a power failure, I noticed that the recovery files are actually never > > updated during an editing session. The recovery files are created upon > > initial

Re: Improve vi(1) recovery

2021-01-05 Thread trondd
trondd wrote: > > While investigating an occasional crash when recovering a file with 'vi -r' > after a power failure, I noticed that the recovery files are actually never > updated during an editing session. The recovery files are created upon > initial modification of the file which saves

Improve vi(1) recovery

2020-12-26 Thread trondd
While investigating an occasional crash when recovering a file with 'vi -r' after a power failure, I noticed that the recovery files are actually never updated during an editing session. The recovery files are created upon initial modification of the file which saves the state of the file at