can we separate the ksh vs dynamic local array issues?
do we really want to tie ksh stability to external bug fixes
for a hunk of code that is not even part of ksh?
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Tue, 14 Nov 2006 03:03:27 +0100 Roland Mainz wrote:
> 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;)
> _______________________________________________
> ksh93-integration-discuss mailing list
> [EMAIL PROTECTED]
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
