[illumos-Developer] illumos_145 i386 build status

[Joerg Schilling]

ken mays <maybird1776 at yahoo.com> wrote:

> 3. Pax/Sed/tr binaries: Roland has built test binaries which are working with the merged IllumOS ON_146 binaries from Piotr - fixing everything (I think) except the locales. Possible resolution through G18n locale packages and ENV settings. Still under review by Joerg.

Let me explain what I did:

I did run one single test with ast-sed and that failed.
If ast-sed would replace sed, then you would no longer be able to compile any 
of my programy using /usr/ccs/bin/make or "dmake".
>From a view on portability issues, the usability of tr(1) in UNIX environments 
is questionable, so many scripts and programs rather use sed(1). If sed fails
on such a replacement, this is a know out criterium.


I did run three calls to ast-tr and the third test did fail.
I know that the the usability of tr(1) in portable applications is limited, but 
I am sure that there are people who have problems when ast-tr does not support
simple translitarations from uppercase to lowecase letters.


I did run aprox 10..20 different tests with ast-pax. I discovered that ast-pax 
does not evaluate numbers from POSIX.1-2001 extended headers and as a result 
does not e.g. support files >= 8 GB. I discovered a hard violation against all
POSIX versions from POSIX.1-1988 until POSIX.1-2008 (ast-pax uses the forbidden
value '8' for typeflag in tar headers). The fact that creating a listing from
an archive that makes use from the current POSIX standard takes 19x the wall 
clock time and 100x the user CPU time star takes for the same operation is 
something that needs investigation on the internal program structures in 
ast-pax.


As you can see, I did definitely not do systematic testing on ast-sed or ast-tr.
I did some rudimentary testing on ast-pax using tests that I created aprox 
10 years ago in order to test against bugs that have been reported against 
Sun tar and GNU tar and that are related to POSIX incompatibilities. The test 
that unveiled the hard POSIX violation was discovered by a test that I created
in 1994 from reading the POSIX standard and detected by the program "tartest" 
that I wrote in 2002.

Given these contraints, I recommend to start with systematic testing. I believe 
that I cannot do this kind of testing as I don't have any test suite that would 
apply to a "sed" ot "tr" implementation. Once the visible problems in ast-pax 
have been fixed, someone would need to use ast-pax on a regular base for some 
time in order to be able judge.

As long as these issues have not been resolved, it seems to be impossible to 
decide on an integration.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily