[M3devel] FW: NT386 jmpbuf size?

[Olaf Wagner]

If there is a chance that more bytes are actually used under
special circumstances, I'd vote to make the jmp_buf large enough
to avoid memory corruption. I'm not sure if the extra bytes
will have performance impacts on thread switching, but I think
a special instruction could be used for copying them so that
it should be not much difference. I'm no expert on the Intel
processors though...

Quoting Jay <jayk123 at hotmail.com>:

> truncated again...
>
> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386  
>  jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000
>
>
> Does anyone mind wasting an extra 32 bytes of stack in functions   
> with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you   
> read the assembly, _setjmp doesn't use it all, and _setjmp3 might.   
> The difference is whether not a situation in which Modula-3 calls   
> longjmp "past" C or C++ code, does the C __finally and C++   
> destructors run.Presently I think with Modula-3, not.Like, if   
> Modula-3 passes some C/C++ a callback and the callback raises an   
> exception and the C/C++ wanted to do some cleanup as the exception   
> "goes by". I think it's always been this and I guess nobody noticed,  
>  so maybe leave it alone and shrink the jmpbuf back to 32 bytes from  
>  64? Inflating from 8 to 13 also does get you some possible interop   
> between NT386 and NT386GNU.  - Jay
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194