apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Porting APR to QNX4: portability problems.
Date Mon, 29 Jan 2007 20:19:58 GMT
генерал Пурпоз wrote:
> Hello William,
> Monday, January 29, 2007, 10:03:56 PM, you wrote:
>> It looks like your QNX4 compiler isn't modern enough to support apr.
>> I don't have a clean solution to suggest :(
> [rant]
> Pity...
> I thought the "Portable" in the project's name would oblige to a some
> degree... And I'm still in APR, APR-UTIL is far less friendly...
> Consider the "tm_usec" in the "struct tm"!
> [/rant]

Yes - apr and apr-util are designed for modern operating systems.  We had
deliberately chosen not to provide full interoperability with legacy OS
and micro-OS's.  There are a number of portability solutions out there,
what distinguishes APR is (we hope) it's usefulness at authoring server
daemons and other applications that demand modern features.

For example, ACL's and interoperatibility with OpenSSL are two features
we hope to introduce in the near future (OpenSSL is already being leveraged
on our development trunk and in the coming 1.3.x versions).  These are the
sorts of features that these applications demand.

> (Offtopic: there is hope, the OpenWATCOM is being ported too, with
> full int64 support)

WOOT!  I'm glad to hear this; there are many factors in modern applications
which demand huge-integer representation (apr_time_t, for example).

>>> I'm tempted to see the "//node-ID/" as the "C:/" on MS-DOS, am I
>>> wrong?
>> Similar, yes. But I'd suggest it's more like //machine/share/ syntax
>> on MS-DOS.
> I'm yet to understand what does that interpretation mean to me on
> QNX4.
>> The root of the local node could reduce //0/ to /, yes.
> Does this mean that APR will not work across the network? On QNX4 a
> user may refer to a file|folder on another node. The porting of APR is
> the part of my attempt to port the SVN. So, it would be great to be
> able to send "svn checkout URL@REV //other-node-ID/path/to/a/working/dir"...

Well, this isn't actually a flaw since you can't accomplish this (moving
from box X to box Y and anticipating a proper representation.  C:/ isn't
represented as //thisbox/local-C-share either.)

>>>> If they pass the "//local-ID/foo" path, they better get back "/foo".
> In the light of the above - if I get the fullpath of local resource
> I'll return "/foo" but if I get non-local "//node-ID/foo" - should I
> keep it as is?
> //0/foo =========== /foo
> //my-node-ID/foo == /foo
> //other-node/foo == //other-node/foo
> Will this break anything in the APR?

I wouldn't want to reduce the second case, we don't do that on any other

But I'd DEFINITELY agree //0/ should be reduced to /.  //0/ They are
identical, and / is easier to write.  In fact, Win32 should probably learn
to reduce //?/C:/ to C:/ if we aren't doing that now (we may be doing so.)


View raw message