Re: cluts review

[Solar Designer <solar@openwall.com>]

On Wed, Jul 13, 2011 at 09:29:06PM +0200, Luka Mar??eti?? wrote:
> On 07/13/2011 07:52 PM, Solar Designer wrote:
> >>and go back to SA_NODEFER.
> >OK, but there's a cleaner way to do it.
> 
> If you mean SA_NODEFER is new,

No, I don't.

> my comment is: Yes, but note that for 
> sigsetjmp to do the same job, I'd need yet another global variable.

No, you wouldn't.  You already have a jmp_buf variable, which you'd
replace with a sigjmp_buf one.  It's a trivial change, really.

(I wrote the above before I saw Rich's response about the same.)

> >>Oh, and I do believe I know aht "clobbered" means (overwriting the new
> >>value of the variable with the old one, from when the context was saved,
> >>right?).
> >Yes.  Do you know in what cases this happens, and how to prevent it?
> 
> If you don't mind i'll skip this one :-(

Rich might be able to provide a better / more correct answer (I'd be
interested), but here's my understanding:

The clobbering happens when those variables are kept in registers rather
than in memory (on stack).  To prevent it from happening, you may force
the compiler not to place the variables in registers.  One way to do it
is to take the variable's address:

(void) &var;

(I am not sure what guarantees this provides.  IIRC, it was documented
to provide the needed safety under GNU C.)

Another is to declare it "volatile", but this does a bit more than is
needed (so has extra performance impact).

Better yet, structure your function such that there are no variables to
clobber.  If you put your sigsetjmp() at the very beginning of the
function, before any local variable is assigned a value, there's nothing
to clobber yet.

> >>That's what I've said I've checked with buf.c.
> >What exactly did you check/change?
> 
> I don't remember if I had to change anything, but I can comment on 
> -Wclobbered messages, that might convince you:
...

So basically you review the code and then knowingly ignore the warnings?
That's not great.

Alexander