Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45BE9691.10602@rowe-clan.net>
Date: Mon, 29 Jan 2007 18:51:29 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.8 (X11/20061107)
MIME-Version: 1.0
To: =?UTF-8?B?0LPQtdC90LXRgNCw0Lsg0J/Rg9GA0L/QvtC3?= <kb2wjw@gmail.com>
CC: dev@apr.apache.org
Subject: Re: Porting APR to QNX4: portability problems.
References: <655149590.20070128175426@gmail.com>
 <cc67648e0701280758i1820a4doc1177c3a0ba0fc20@mail.gmail.com>
 <1161280414.20070129191438@gmail.com> <45BE2C08.90503@rowe-clan.net>
 <2710265977.20070129214306@gmail.com> <45BE451C.2060807@rowe-clan.net>
 <722659954.20070129225108@gmail.com> <45BE56EE.3050900@rowe-clan.net>
 <798030614.20070130022105@gmail.com>
In-Reply-To: <798030614.20070130022105@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

генерал Пурпоз wrote:
> 
>> OpenSSL is already being leveraged on our development trunk and in
>> the coming 1.3.x versions
> Does this mean, for example, that SVN would not need the "neon"
> library?

No.  Actually, there was a possible http client implementation, apr-serf.
It was booted from apr because of pushback about maintenance, and landed
(IIRC) over at google-code now shepherded by (IIRC) Justin.

Because neon is LGPL, apr folk would be unlikely to add it; apr_dbd_mysql
for example doesn't exist here.

> I've ported the GMP v4.2.1 (it's early version v2.0.2 was bundled with
> the ssh-1.2.33 to handle all the BigNum crunching), that's the perfect
> example of truely portable code!
>
> If I were to look for huge-integer representation I'd chosen GMP for
> that. (I'm sorry - I begin to rant again! :) )

:)

Again - apr was tailored to modern OS's, and in your case, especially
to a modern C compiler.  Ignoring >32 bit data in this day and age is
really pretty pathetic :)

I'm not against it if you were to revisit the places in the code that we
called for forced-64 bit representations and argue for patches that say
"this is unreasonable, apr_off_t is sufficient because we are representing
(at most) a file's worth of data" - or whatever the specific arguement is
for correcting the representation.

But I'm certain you won't be able to evict all of them, apr_time_t is the
first that comes to mind.  And data type changes break ABI, and ABI can only
break when we release APR 2.0.

That doesn't mean we shouldn't work to get this right in anticipation of
releasing a 2.0 sometime in the future.

> I've done some tests here, the 'qnx_fullpath()' is very powerfull
> stuff. It resolves even through the symlinks.
> If I have '/bin/sh' a symlink to '/bin/ksh', the full path of
> '/bin/sh' is reported as '//node-ID/bin/ksh'.
> 
> It handles inputs like the '../../bla/bla' nicely as well. The
> 'qnx_fullpath()''s output is unique and unambigiuos whithin all the
> networked QNX boxen. (Each box has unique node-ID whithin a given
> FLEET|QNET network of an enterprize.)

In *that* case, I concur, it sounds like on QNX, the proper representation
includes the node-ID; this different way of looking at the filesystem schema
is an integral element of their kernel design.

> So, to summarize, regarding the above '/bin/sh':
> - the root must be '//node-ID/'

yes.

> - the path must be 'bin/' - without the leading slash, with the
>   trailing one

yes to the first.  Uncertain without looking about the second.

> The same regarding the '/' and all it's variants:
> - the root must be '//node-ID/'
> - the path must be NULL
> Is this understanding correct?

Null means undefined - I think you are thinking of empty string on output.

> As a sidenote: can someone give me the textual description of each
> test in the "filenames.c" suite?
> Thank you in advance.

Better question, can someone document each test in filenames.c suite, with
some comments about why they need to be tested ;-)

No free cycles here for a few days.