[ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments

[Joseph Kowalski]

Roland Mainz wrote:
> AFAIK this is not possible. The problem is that /usr/bin/getconf is
> compiled as normal application while ksh93 in Solaris is explicitly
> compiled as XPG6/C99 application (to enable various features and avoid
> that the ksh93 code enables workaronds for older standards functions
> (which result in both loss of features and performance)).
> The problem is that compiling a Solaris application with the XPG6 flags
> changes some "secret" libc master switches (|_xpg4| and |_xpg6|) which
> change the behaviour of many libc functions to match the XPG6 standards,
> including |sysconf()|, |pathconf()| etc. - which would make the
> "getconf" builtin command work like /usr/xpg6/bin/getconf instead of
> /usr/bin/getconf (and there is no workaround, neither running the
> "getconf" builtin in a seperate child process with |_xpg4|+|_xpg6| set
> to "0" (this doesn't work because it doesn't alter the different header
> contents (and I doubt that code review would allow such a horrible abuse
> of C64-style "poke"'ing)) or poking these values only at runtime of the
> "getconf" builtin (end reset it in an exit trap) will work (this would
> not be threadsafe)).
>   
Maybe I'm just confused, but this seems to be a good explanation why 
/usr/bin/getconf
can't be a tiny wrapper linking with the library which implements the 
builtins for ksh93
(I forgot name of said library - probably blocking it in the Freudian 
sense.)

Why couldn't the same *source* be compiled not in xpg mode to produce 
/usr/bin/getconf.
I believe the concern was about sharing source, not about sharing the 
binary implementation.

- jek3