This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Joel Sherrill <joel@rtems.org> writes: > This made me remember that RTEMS has a simple set of printk stdio. Would it > be possible to have a set of "kernel" stdio methods in parallel with > regular stdio. Use names like printk, sprintk, etc and have a user level > feature flag to enable macros that map stdio to those methods. That's what SDCC does as well, and it's useful as long as all you want is console output. If you want to offer any additional files, then you need something a tiny bit more complex, and that's where I'm at these days. > I am just pondering. The idea of having both in newlib sounds useful. We > use multilibs for many variants within an architecture so we have a single > toolchain for all arm variants. Being able to let an application select > when it is built if they are mapped to these would be desirable. Right, I'm building all 20 arm-none-eabi variants that the toolchain lists. I guess I wonder what arm-none-eabi user would want the larger stdio; it requires a posix syscall API, which seems like that would involve an operating system with a toolchain though? > Now the best you get is integer only methods or a rebuild for nano which > doesn't meet these smallest systems. For the AVR libc stdio, I build both fp and integer-only printf/scanf methods, with the integer-only versions named: vsnprintf vsniprintf vfprintf vfiprintf vprintf viprintf fprintf fiprintf printf iprintf sprintf siprintf snprintf sniprintf asprintf asiprintf asnprintf asniprintf vfscanf vfiscanf scanf iscanf fscanf fiscanf sscanf siscanf By selecting the compile-time option 'NEWLIB_INTEGER_PRINTF_SCANF', the user application gets the 'normal' names defined as the integer-only names so that it ends up using those functions instead. By building both into the library, you avoid needing to pick which variant you want at library build time and can leave it up to the application. It's not perfect; I'd love to have the fp-enabled versions 'replace' the integer-only ones so that another library could call iprintf and have that use printf if the application ended up needing the full-featured version. Maybe some trickery with weak symbols could solve this... -- -keith
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |