Garrett D'Amore wrote:
>
> -- Garrett
>
> Don Cragun wrote:
> > I am sponsoring this case for Roland Mainz (an OpenSolaris contributor)
> > and April Chin (acting as sponsor for this work).
> >
> > I believe it qualifies for closed approved automatic status. If a
> > PSARC member disagrees, let me know and I will upgrade it to a
> > fast-track case.
> >
> > Sincerely,
> > Don
> >
> > Template Version: @(#)sac_nextcase %I% %G% SMI
> > This information is Copyright 2008 Sun Microsystems
> > 1. Introduction
> > 1.1. Project/Component Working Name:
> > Remove /usr/bin/printf from PSARC case 2008 094
> > 1.2. Name of Document Author/Supplier:
> > Author: Donald Cragun
> > 1.3 Date of This Document:
> > 17 September, 2008
> > 4. Technical Description
> >
> > This case updates PSARC/2008/094 (ksh93 Update 1).
> >
> > While implementing PSARC/2008/094, which (among other things) planned
> > to replace /usr/bin/printf with a link to the AT&T AST printf, the
> > project team found some irregularities in standards conformance in both
> > the default printf() function in libc and in the behavior of
> > /usr/bin/printf.
> >
> > Since some of these issues may involve official interpretation requests
> > against the POSIX Standards and the Single UNIX Specifications, they
> > may take a long time to resolve. Therefore, this case removes the
> > changes to /usr/bin/printf that were documented in PSARC/2008/094 from
> > the deliverables provided by that case so PSARC/2008/094 changes can
> > be integrated in a timely manner.
> >
> > Since the current /usr/bin/printf will not be changed by this case,
> > there are no backwards compatibility issues.
>
> I concur that this is an automatic approval case. In fact, you probably
> could have just done it as an update to 2008/094 directly.
Erm... the idea is to defer this part to a later putback when the issues
have been resolved. The problem is that we don't have time anymore for
_any_ discussions around the /usr/bin/printf since the code for
PSARC/2008/094 must be ready by Friday (_last_ _date_).
> That said, out of curiosity, where do the implementations differ such
> that ksh93's
s/ksh93/AST/ , ksh93 only offers the AST version of "printf" as builtin
command
> version can't stand as a replacement?
It's the "precision" option of "%s" - does it count in "whole
charatcers" (where "character" means "multi-byte character" (like all
other ksh88/ksh93/bash2/bash3 string operators do)), "screen columns"
(since _some_ multibyte characters occupy more than one screen column)
or "bytes".
The ksh93 builtin originally used "whole characters" but the POSIX/SUS
standards indirectly define "bytes" (without having any "leeway" right
now to allow "whole characters") and the Solaris command seems to use
(accidently ?) "screen columns" (where I doubt whether this makes
sense).
In the meantime the ksh93 builtin has been changed to use "bytes" as
defined by POSIX/SUS and we're now trying to investigate two things:
1. Why Solaris's /usr/bin/printf uses "screen columns" ?
2. How can we get a |printf()| formatting option for "whole characters"
("%s"'s precision option counting in bytes isn't very healthy for
multibyte characters) ?
We're currently digging around to get an answer for [1] but we don't
have _any_ time anymore to hold-off the other parts of PSARC/2008/094
for that - people need the updated/fixed ksh93 _BADLY_, preferable
checked-in yesterday or the day before that.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
