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:[EMAIL PROTECTED]
