You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by генерал Пурпоз <kb...@gmail.com> on 2007/01/28 15:54:26 UTC
Porting APR to QNX4: portability problems.
Hello dev,
I'm porting the APR|APR-UTIL v1.2.8 to QNX4 - a UNIX clone.
Despite it's name - the APR is not so easily portable. The v1.2.8 is
far less friendly than the v0.9.12 (which is bundled with the SVN
v1.4.3).
My host OS (QNX v4.25G) has no support for either "threads" and
"shared objects". Is the "DSO" the "shared object"?
Am I doomed to fail without both?
Also, my toolchain has no support for "long long"s a.k.a. int64, is
this the showstoper?
Lots of too bold assumptions are made regarding the "struct tm"
contents available on a host OS...
(The similar time|date related functions found in the "neon v0.26.3"
library are very portable.)
Are there any plans to make APR|APR-UTIL a bit more portable?
Could you please make the "expat" dependency controllable?
I've ported the "expat v2.0.0" successfully (it is required for the
"neon" library as well), it would be nice to be able to link the APR
against the already installed "expat".
(By the way, are there any strict demands regarding the "expat"
library version?)
Thank you in advance.
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Re[2]: Porting APR to QNX4: portability problems.
Posted by генерал Пурпоз <kb...@gmail.com>.
Hello William,
Monday, January 29, 2007, 8:16:56 PM, you wrote:
> It can NOT have a smaller range. apr_int64_t is a contract that there
> are 64 available bits. If it had 72 bits that wouldn't be the end of
> the world. Is long double or some other type on the watcom compiler
> available?
Here's what my documentation sais:
basic type sizeof()
char.........1
short int....2
int..........4
long int.....4
float........4
double.......8
near*........4
far*.........6
What would you suggest here?
> A fullpath is the absolute path (truename is the canonical form that must
> be in the proper case).
> A root is something you must not ../ up and around. So it seems to me that
> your root is "//node-ID/".
OK, I can get it by 'strcat( qnx_prefix_getroot(), "/" )'.
But I'm tempted to see it as the "C:/" on MS-DOS, am I wrong?
> But obviously on this OS, the local node is the equivilant of "/".
Did you mean "the root"?
> If you want to use the short node ID on the local paths, that's fine
> (those roots are "/"). It's important that the paths are
> **consistent**!!! That will allow folks who test filenames for
> security purposes are comparing apples to apples.
I'm still confused. Where can I read more about it?
(I did read the "./docs/canonical-filenames.html" caveats and warnings
but that did not enlighten me yet...)
> If they pass the "//local-ID/foo" path, they better get back "/foo".
But would not it break the test suite?
Besides, there is a notion of a "default node ID": //0/some/path -
this exactly what you called "//local-ID/foo", it works on any node
and points to a local resource.
When|how the "APR_FILEPATH_TRUENAME" flag is used?
Should I return the "//node-ID/path/to/file" if APR_FILEPATH_TRUENAME
is set?
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Porting APR to QNX4: file path management.
Posted by генерал Пурпоз <kb...@gmail.com>.
Hello William,
Wednesday, January 31, 2007, 7:46:57 AM, you wrote:
> We presume rootpath **was** normalized previously. We presume
> addpath is untrusted user data. Now come up with a path that isn't
> insecure per the flags the developer passed.
I did my best to not ruin your code.
This is what I came up with, it passes all the tests I could think of:
--- filepath.c.orig 2006-09-21 11:43:54.000000000 +0400
+++ filepath.c 2007-02-04 02:28:26.000000000 +0300
@@ -14,6 +14,10 @@
* limitations under the License.
*/
+#ifdef __QNX__
+#include <string.h>
+#include <sys/prfx.h>
+#endif
#include "apr.h"
#include "apr_private.h"
#include "apr_arch_file_io.h"
@@ -66,11 +70,36 @@
apr_int32_t flags,
apr_pool_t *p)
{
+ int prefix_present = 0; /* a "//number/" is in inpath */
+
if (**inpath == '/') {
+#ifdef __QNX__
+/* Are we presented with a wellformed QNX4 full path: "//number/foo" ? */
+/* A "/8/foo"-like string does NOT qualify as one. Such a string is just */
+/* an abbreviation of a "//number/8/foo"-like on-the-current-node path. */
+ if( strlen(*inpath) >= 2 && \
+ *(*inpath+1) == '/' && \
+ isdigit(*(*inpath+2)) ) prefix_present = 1;
+#else
*rootpath = apr_pstrdup(p, "/");
+#endif
do {
++(*inpath);
} while (**inpath == '/');
+#ifdef __QNX__
+ if( !prefix_present ) /* construct the rootpath anew */
+ *rootpath = apr_pstrdup(p, qnx_prefix_getroot() );
+ else { /* inpath has had a valid prefix, move in to rootpath */
+ *rootpath = apr_pstrdup(p, "//");
+ while ( isdigit(**inpath) ) {
+ strncat( *rootpath, *inpath, 1 );
+ ++(*inpath);
+ } /* move all the decimal digits representing the node ID */
+ }
+ strncat( *rootpath, "/", 1); /* now complete rootpath properly */
+ if( 0 != strlen(*inpath) && 1 == prefix_present )
+ ++(*inpath); /* deal with the post-node-number slash */
+#endif
return APR_SUCCESS;
}
@@ -91,6 +120,9 @@
apr_size_t pathlen; /* is the length of the result path */
apr_size_t seglen; /* is the end of the current segment */
apr_status_t rv;
+#ifdef __QNX__
+ int prefix_present = 0; /* a "//number/" is in addpath */
+#endif
/* Treat null as an empty path.
*/
@@ -99,7 +131,7 @@
if (addpath[0] == '/') {
/* If addpath is rooted, then rootpath is unused.
- * Ths violates any APR_FILEPATH_SECUREROOTTEST and
+ * This violates any APR_FILEPATH_SECUREROOTTEST and
* APR_FILEPATH_NOTABSOLUTE flags specified.
*/
if (flags & APR_FILEPATH_SECUREROOTTEST)
@@ -160,11 +192,41 @@
* '/'s to a single leading '/' from the addpath,
* and leave addpath at the first non-'/' character.
*/
+#ifdef __QNX__
+ keptlen = 0;
+
+/* As with apr_filepath_root() we want to know if we deal with a wellformed */
+/* QNX4-style full path: "//number/foo" ? */
+
+ if( strlen(addpath) >= 2 && \
+ addpath[1] == '/' && \
+ isdigit(addpath[2]) ) prefix_present = 1;
+ while ( addpath[0] == '/' )
+ ++addpath; /* do your usual slash-stripping at the front end */
+
+ if( !prefix_present ) {
+ strncpy( path,qnx_prefix_getroot(),strlen(qnx_prefix_getroot()) );
+ pathlen = strlen( path );
+ } else {
+ strncpy( path, "//", 2 );
+ pathlen = strlen(path);
+ while ( isdigit( addpath[0] ) ) {
+ path[pathlen] = addpath[0];
+ ++pathlen;
+ ++addpath;
+ }
+ }
+ path[pathlen] = '/';
+ ++pathlen;
+ if( 0 != strlen(addpath) && 1 == prefix_present )
+ ++addpath; /* deal with the post-node-number slash */
+#else
keptlen = 0;
while (addpath[0] == '/')
++addpath;
path[0] = '/';
pathlen = 1;
+#endif
}
else {
/* If both paths are relative, fail early
Please comment if it is a complete lunacy... :)
By the way, on my toolchain the "ABTS_STR_EQUAL(tc, "", path);"
construct needs this hacking:
"ABTS_STR_EQUAL(tc, "\0", path);"
Unless I do this the check fails no matter that the "path" string is
empty. The report complains it extected <some_string> but saw <>.
"some_string" most often is shown as "//2/". I wonder why...
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Re: Porting APR to QNX4: portability problems.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
генерал Пурпоз wrote:
>
> 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?
Yup.
> If the "rootpath" == '/foo/bar/bla', the "addpath" == '../baz' -
> should the "newpath" be == '/foo/bar/baz' ?
Yes - UNLESS NOTABOVEROOT flag was passed.
> If the "addpath" == '../../baz' - should the "newpath" be == '/foo/baz' ?
Yes - except NOTABOVEROOT as above.
> Is this understanding correct?
> Is the "addpath" of something like '../baz/../../' allowed too
> (however stupid)?
Sure. The concept is that the root given must not change on output after
all ./ and ../ segments are reduced when they ask for NOTABOVEROOT to be
evaluated.
> So, in general, first I rectify the "rootpath"
NO :)
We presume rootpath **was** normalized previously. We presume addpath is
untrusted user data. Now come up with a path that isn't insecure per the
flags the developer passed.
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*.
Right.
> After I get to the very end of the "addpath" - I copy what I got into
> the "newpath". Right?
Yes.
> 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! :)
No - not to many - and again refer your results against testpaths.c to see
that your merge is proper.
Don't be surprised that one call to a system function won't provide the
features that the API demands ;-)
Re[2]: Porting APR to QNX4: portability problems.
Posted by генерал Пурпоз <kb...@gmail.com>.
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
Re: Porting APR to QNX4: portability problems.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
генерал Пурпоз 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.
Re[2]: Porting APR to QNX4: portability problems.
Posted by генерал Пурпоз <kb...@gmail.com>.
Hello William,
Monday, January 29, 2007, 11:19:58 PM, you wrote:
> 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.
An embedded systems may be interested in APR's features as well.
> 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?
> 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'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! :) )
>> 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.)
I believe I must look into it.
The main feature of QNX (both generations of that OS, v4 and v6) is
the native networking capability. QNX4's networking is called FLEET,
QNX6's is QNET, both are non-IP.
It is well possible to 'open("//5/path/to/a/file",...)' from any other
node. Since it is transparent - the above svn trick should come for
free (on QNXes), I believe.
>> 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
> I wouldn't want to reduce the second case, we don't do that on any other
> platform.
> 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.)
Hm...
Thinking about it more I start feeling the better way would be exacly
the opposite:
/foo =============== //node-ID/foo
//0/foo ============ //node-ID/foo
//node-ID/foo ====== //node-ID/foo
//other-node/foo === //other-node/foo
This would straighten things up (a user may input whatever he wishes
and get the valid result on *ANY* node). At some point it could evolve
into the APR_HAS_FLEET and APR_HAS_QNET features. Then the APR-based
QNX applications would use their native capabilities for all
non-IP-reachable resources (instead of the '//file:/bla/bla').
Please comment.
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.)
So, to summarize, regarding the above '/bin/sh':
- the root must be '//node-ID/'
- the path must be 'bin/' - without the leading slash, with the
trailing one
The same regarding the '/' and all it's variants:
- the root must be '//node-ID/'
- the path must be NULL
Is this understanding correct?
As a sidenote: can someone give me the textual description of each
test in the "filenames.c" suite?
Thank you in advance.
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Re: Porting APR to QNX4: portability problems.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
генерал Пурпоз 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
platform.
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.)
Bill
Re[2]: Porting APR to QNX4: portability problems.
Posted by генерал Пурпоз <kb...@gmail.com>.
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]
(Offtopic: there is hope, the OpenWATCOM is being ported too, with
full int64 support)
>> 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"...
>>> 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?
> If QNX4 is case-preserving, case-sensitive, then TRUENAME flag does
> nothing.
OK, QNX4 respects the case.
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Re: Porting APR to QNX4: portability problems.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
генерал Пурпоз wrote:
>
> With the official compiler (Watcom C v10.6B) the configuration script
> detects the absence of "long long"s, but still - int64 are all around
> the place. They are not redefined to a smaller size...
It can NOT have a smaller range. apr_int64_t is a contract that there
are 64 available bits. If it had 72 bits that wouldn't be the end of
the world. Is long double or some other type on the watcom compiler
available?
> My problem is that I do not understand what is "root" and what is
> "path" on my platform.
> Consider this:
> QNX4 is the networked OS, each machine is a node, all nodes are
> visible.
> The full path (obtained with the "qnx_fullpath()" call) looks like
> "//node-ID/path/to/some/file", for example on node 2 the full path to
> "ksh" is "//2/bin/ksh". But if one executes "getcwd()" - he will see a
> path like "/home/user".
>
> So I am all lost and confused: what should I call the "ABS_ROOT", what
> is "root" and what is "path"?
> Do I get it rigth - "bin/ksh" is the path (or is it just "bin/" ?);
> "//2" is ABS_ROOT and "/" is root?
> How should I react on the APR_FILEPATH_TRUENAME flag set?
A fullpath is the absolute path (truename is the canonical form that must
be in the proper case).
A root is something you must not ../ up and around. So it seems to me that
your root is "//node-ID/". But obviously on this OS, the local node is the
equivilant of "/". If you want to use the short node ID on the local paths,
that's fine (those roots are "/"). It's important that the paths are
**consistent**!!! That will allow folks who test filenames for security
purposes are comparing apples to apples. If they pass the "//local-ID/foo"
path, they better get back "/foo".
Re[2]: Porting APR to QNX4: portability problems.
Posted by генерал Пурпоз <kb...@gmail.com>.
Hello Jeff,
Sunday, January 28, 2007, 6:58:00 PM, you wrote:
> Start slowly and post info about the first build error you encounter.
> Since you can build 0.9, try to see why 0.9 works and 1.2 fails.
Actually I was not yet being able to port APR v0.9.12 either.
It just was smart enough to ./configure on my platform successfully.
v1.2.8 did not even ./configure - it was my fault - I did not feed the
script any "--without-*"s - they are absent in it's "--help" list.
I took v0.9.13, got it's much more detailed "./configure --help" and
then fead the same set of options to the v1.2.8 configurator.
Now I could get started.
With the official compiler (Watcom C v10.6B) the configuration script
detects the absence of "long long"s, but still - int64 are all around
the place. They are not redefined to a smaller size...
I could get to "make check" using an unofficial toolchain.
Here goes an abbridged list of my problems:
I get 4 "fmt" test failing - all int64 related, I believe I will be
able to fix those.
"apr_strftime(str, &sz, STR_SIZE, "%R %A %d %B %Y", &xt) - here I was
forced to use the %X or %T instead of %R - there is no such format
directive here.
I cannot get the "testnames.c" to succeed.
My problem is that I do not understand what is "root" and what is
"path" on my platform.
Consider this:
QNX4 is the networked OS, each machine is a node, all nodes are
visible.
The full path (obtained with the "qnx_fullpath()" call) looks like
"//node-ID/path/to/some/file", for example on node 2 the full path to
"ksh" is "//2/bin/ksh". But if one executes "getcwd()" - he will see a
path like "/home/user".
So I am all lost and confused: what should I call the "ABS_ROOT", what
is "root" and what is "path"?
Do I get it rigth - "bin/ksh" is the path (or is it just "bin/" ?);
"//2" is ABS_ROOT and "/" is root?
How should I react on the APR_FILEPATH_TRUENAME flag set?
Another QNX4 peculiarity is the mmap(), shmem() and friends - they
cannot be used to copy files - the files here cannot be memory-mapped.
The maximum amount of file descriptors for select() to use seems to be
24, if I declare LARGE_NUM_SOCKETS to be 25 - the test blows. The OS's
header declares the FD_SETSIZE to be 32.
Please comment|advise|hint.
Thank you in advance!
(More questions to come.)
--
Best regards,
Anthony mailto:kb2wjw@gmail.com
Re: Porting APR to QNX4: portability problems.
Posted by Jeff Trawick <tr...@gmail.com>.
On 1/28/07, генерал Пурпоз <kb...@gmail.com> wrote:
> I'm porting the APR|APR-UTIL v1.2.8 to QNX4 - a UNIX clone.
>
> Despite it's name - the APR is not so easily portable. The v1.2.8 is
> far less friendly than the v0.9.12 (which is bundled with the SVN
> v1.4.3).
All the particular features you mention later (long long, DSO,
threads) would have been encountered with v0.9.
> My host OS (QNX v4.25G) has no support for either "threads" and
> "shared objects". Is the "DSO" the "shared object"?
> Am I doomed to fail without both?
no
> Also, my toolchain has no support for "long long"s a.k.a. int64, is
> this the showstoper?
no
Start slowly and post info about the first build error you encounter.
Since you can build 0.9, try to see why 0.9 works and 1.2 fails.