apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From генерал Пурпоз <kb2...@gmail.com>
Subject Re[2]: Porting APR to QNX4: portability problems.
Date Tue, 30 Jan 2007 14:55:55 GMT
Hello William,

Tuesday, January 30, 2007, 3:51:29 AM, you 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.
OK.
By the way did Alon Barlev contact you already regarding the
PKCS#12-awareness of APR?
I meet him on every list where any SSL-related topics are discussed.

> 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.
I can't promise anything certain but I hope to try...

>> 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
OK

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

>> - the path must be 'bin/' - without the leading slash, with the
>>   trailing one
> yes to the first.  Uncertain without looking about the second.
Neither am I. Without the trailing one is even simpler, the
'qnx_fullpath()' does not append it itself.

>> 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.
Oh, yes, I just misunderstood what one of the tests in the
"filenames.c" wanted. The "/"'s "path" will be "".

> 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.
OK.

What exactly the 'apr_filepath_merge()' is supposed to do?

In the simplest case of the "rootpath" == '/foo/bar/bla', and the
"addpath" == 'baz' the "newpath" is == '/foo/bar/bla/baz' - correct?

If the "rootpath" == '/foo/bar/bla', the "addpath" == '../baz' -
should the "newpath" be == '/foo/bar/baz' ?
If the "addpath" == '../../baz' - should the "newpath" be == '/foo/baz' ?
Is this understanding correct?
Is the "addpath" of something like '../baz/../../' allowed too
(however stupid)?

So, in general, first I rectify the "rootpath" and then I crawl
up|down the resulting rooted path and try to construct a new path
according to the "addpath"'s list of elements *FROM LEFT TO RIGHT*.
After I get to the very end of the "addpath" - I copy what I got into
the "newpath". Right?

If, according to the "addpath"'s instructions, I get down to the root
I should consult the flags and either, if permitted, proceed up from
root, or return with an error. (I.e. if "rootpath" == '/foo/bar', and
the "addpath" == '../../../baz' the "newpath" is == '/baz' if flags
permit.)

Sorry for too many questions at a time! :)

-- 
Best regards,
 Anthony                   mailto:kb2wjw@gmail.com


Mime
View raw message