Re: Limited RAM stdio replacement for newlib

"Keith Packard" <[email protected]> Fri, 21 Sep 2018 09:43:49 -0700
Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>
Joel Sherrill <[email protected]> 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
signature.asc (application/pgp-signature, 832 B)