Mike Kupfer wrote:
> Roland> "I. Szczesniak" wrote:
>
> >> Roland, CTFMERGE=true CTFCONVERT=true;export CTFMERGE CTFCONVERT;
> >> dmake install fixes your problem.
>
> Roland> Well, it could be used for libast&co (assuming we find a way to
> Roland> convince the code reviewers to "ignore" this little detail
> Roland> (unlikely)) but one part which fails sits in libc itself - and
> Roland> turning CTF ("Compact Type Format") off for that is as likely as
> Roland> the hell is going to freeze).
>
> As long as a bug has been filed against the CTF tools, I think it's fair
> for the AST code to use Irek's suggestion as a workaround.
Would that be allowed by the code review ? Right now the AST code
doesn't make use of this feature but I hoped that one of the following
updates uses this feature - and then this defect in the CTF filters
would bite back badly.
> 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).
> 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.
----
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
