a src fork will serve no-one well
dgk and I examine proposed patches and roll most of them in,
most times tweaked a bit to fit the overall design
(if there is one hit by the patch)
the VLA-like patches fall into a category that requires some
study to ponder the affects on the overall design
and examination of if/why the current techniques are inadequate
and an assessment on whether the current techniques can
be tweaked to fit the intent of the patch, or if a new technique
needs to be adopted
the impact on the build system, and iffe/config code generation forks
also needs to be studied
an iffe/config fork would encompass possibly different behavior for
code compiled by two different compilation systems, even on the same
machine, one supporting a new feature, the other not -- we've seen
this with fatal VLA compilation errors for one one of the solaris
builds -- what if the bug were more subtle, only raising its head
at runtime?
e.g., with VLA there were some posts hinting at a malloc() fallback
in some cases -- are the runtime fallback tests good enough to
ensure the same behavior as the original techniques on ksh applications
that push the physical limits of a particular machine -- I don't know
surely extensive VLA usage will stress the function call stack much
more than it is now
the main point is that we have a short timeline to obtain a stable code
base for ksh-integration and need to be careful on the patches
selected to reach stability
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Wed, 15 Nov 2006 08:26:39 -0800 John Plocher wrote:
> To clarify - are you saying that, as upstream providers of
> ]ast/ksh93, you are _not_ in favor of the VLA changes that
> Roland and crew are proposing for integration into ast/ksh93
> code as a result of their ksh93-for-opensolaris efforts?
> If so, then this implies that the ksh93-for-opensolaris
> project needs to either
> justify to y'all why the specific VLA usage they
> are implementing is indeed something you should
> endorse,
> or
> back out the VLA work in favor of the original
> status quo.
> Any other path effectively forces Roland (etc) to fork a
> variant of ast/ksh, which is something that nobody wants
> to see happen.
> From my perspective, doing C99 VLAs simply because they are
> cute ("more or less as a demo usage") is a poor justification,
> especially if it adds minimal value and exposes a new class of
> bugs. Not that the bugs shouldn't get found and fixed, but
> because the design choice lacks a compelling rationale.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
