Ian Collins wrote: > Roland Mainz wrote: > >Mike Kupfer wrote: > > > >>As for libc, I only see a variable-length array used in one place, which > >>is the new wordexp() code. I think the workaround there is to change > >>the new wordexp() not to use a variable-length array. > > > >Grumpf... that's unfortunate since it adds some complexity to the code > >and ruines the idea to exploit exactly this feature in the OS/Net > >codebase. The OS/Net code, both kernel (yes, I know... kernel threads > >don't have large stacks... but using the memory allocator of things like > >16byte allocations is IMO slightly silly) and userspace are extremly > >malloc()-happy and many cases could simply be avoided by a small macro > >which uses C99 dynamically-sized arrays up to a fixed limit (and then > >use |malloc()| beyond this barrier). > > Are you sure it (VLA initialisation) can't fail? Probably unlikely for > a small buffer given enough stack, but there's no way to tell.
It can't fail directly but you can hit the end of the stack. However for |libc::wordexp()| there is enougth room (for the SMF process (the only comsumer of |libc::wordexp()| in OS/Net (and I strongly doubt that other consumers are low on stack memory)) multiple megabytes are still available). For other applications it is usefull to have a macro which uses C99 variable length arrays up to a fixed limit and then switches over to use |malloc()| beyond that size (and sets the size of the vla buffer to zero). > >>Speaking of which, where does "140" come from in the dynamic array > >>definition? It would be better not to have a magic number like that. > > > >It's no magic number, it is the maximum size the consumers of the buffer > >will use in any case. > > But it (140) is still a magic number, maybe make it a const size_t? Uhm... AFAIK this is just a question of style, right ? |size_t sizeofbuffer=140+string_length ; char buffer[sizeofbuffer]| or |char buffer[140+string_length]| are pretty much equivalent... but it may be a good idea to add a comment how the value "140" was calculated. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
