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.
>>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? Ian _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
