Re: [avr-libc-dev] -mint8 problem with setjmp/longjmp

[Joerg Wunsch]

As Nils Kristian Strom wrote:

> setjmp.h is *broken*.  The integer type should never have been there
> in the first place.  A pointer is not - and never will be, an
> integer.

Yes.  That's why i think your fix is broken.

> My fix corrects this obvious flaw in the header, replacing addresses
> (pointers) with pointers.

The jmp_buf envelope contains no pointers (in the C sense), it just
contains space for saving registers.  Registers are of some integer
type (8-bit in our case).

Of course, it could as well avoid all this by using uint8_t for any of
the registers, and declaring two distinct fields for those registers
that are actually register pairs.  Would even make more sense, since
technically, setjmp.S stores them byte-by-byte (without even caring
about what is declared in jmp_buf).

Thinking even more about it, jmp_buf should probably be just an
opaque array to the luser, i. e.

#define _JBLEN 24
typedef struct _jmp_buf { unsigned char _jb[_JBLEN + 1]; } jmp_buf[1];

would do as well, and matches the assembler source.

Can you give that a try?

> This is a different case, as this file is *correct*, but not
> compatible with -mint8.

If you argue like that, the entire avr-libc is declared to be not
compatible with -mint8.  Before we can lift this restriction, as i
said, it would require a volunteer doing a code review for each and
any function, including all the assembler source files, to see what
would be the effect (and perhaps to fix some of the hard-coded types
by using int8_t vs. int16_t etc.).

If you use avr-libc with -mint8, it's basically your own risk now.
(OK, if you use a self-compiled avr-libc that has also been compiled
with -mint8, things might be a bit safer, but i wouldn't consider this
an universal option.)

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/