[osol-code] Re: [ksh93-integration-discuss] Trouble with"ERROR:ctfconvert:pics/wordexp.o: Couldn't parse stab "#vla0:(0, 14)" (source file pics/wordexp.o)" ...

[Glenn Fowler]

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.