Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?

[Marek Michalkiewicz]

> I guess we'll bit the bullet, and just use %S as well, but i
> personally feel it's stupid that commercial compiler vendors
> ship library implementations that violate the standard when there's
> no actual need to (chosing a lowercase letter would have been easy).

In addition to %S (to help people move from other compilers to GCC :),
we could support %r then (stands for "ROM string", and it's one of
the remaining few lowercase letters not taken by glibc extensions).

> But wouldn't this also constitute a case where another avr6
> architecture definition made some sense?  At least, that's the
> only way i could see how library code could ever determine whether
> RAMPZ/ELPM is needed or not.  (Library code doesn't have the detailed
> __AVR_ATmegaXXX__ macros available when compiling.)

No library code uses RAMPZ/ELPM - the libarary (so far) makes the
same assumptions as GCC: all flash constants below 64K, only 16-bit
pointers.  For these rare, special applications with >64K of flash
constants, I think it's OK to only provide some macros and/or inline
functions (no code in libc.a), in header files which do have the
detailed macros available.

For example, we could have a macro that works much like memcpy_P()
but takes a symbol_name and offset instead of source pointer.
Feel free to invent a nice, not too long name for such a macro :)
Arguments: (void *DEST, SYMBOL_NAME, size_t OFFSET, size_t LEN)
and it would copy LEN bytes from &SYMBOL_NAME[OFFSET] to DEST.

Marek