Re: [PATCH] apr escape API, portability issues seen on Windows
On 03 Oct 2013, at 1:51 AM, Jeff Trawick traw...@gmail.com wrote: I dug into the glitches seen on Windows... \e is a non-portable escape (GNU extension), and shell escaping treats \n differently on Windows and OS/2, which the testcase didn't account for. I guess the code that used \e doesn't match anything in httpd? Looking back at the code it originated from ap_escape_logitem() and ap_escape_errorlog_item() which are almost identical but for additional escape sequences. If \e is non-portable in C it can be removed, an escape character is unlikely to cause harm. Regards, Graham --
Re: [PATCH] apr escape API, portability issues seen on Windows
On 03 Oct 2013, at 1:51 AM, Jeff Trawick traw...@gmail.com wrote: escape-e-is-gnu-extension.txt Fixed in r1530786. Regards, Graham --
Re: [PATCH] apr escape API, portability issues seen on Windows
On 09 Oct 2013, at 10:34 PM, Jeff Trawick traw...@gmail.com wrote: The function is trying to escape any binary values that could conceivably cause problems when printed to the terminal, whether or not those values happen to have a C escape sequence shortcut. The escaping is done regardless IIUC. It looks like the code which uses \e is just trying to use well-known shortcuts for certain escape sequences, and if the \e code is removed then it will use the hex equivalent. This is true. I have backported the API in r1530799, would it be possible to take a look for me? Regards, Graham --
Re: [PATCH] apr escape API, portability issues seen on Windows
On Wed, Oct 9, 2013 at 5:28 PM, Graham Leggett minf...@sharp.fm wrote: On 09 Oct 2013, at 10:34 PM, Jeff Trawick traw...@gmail.com wrote: The function is trying to escape any binary values that could conceivably cause problems when printed to the terminal, whether or not those values happen to have a C escape sequence shortcut. The escaping is done regardless IIUC. It looks like the code which uses \e is just trying to use well-known shortcuts for certain escape sequences, and if the \e code is removed then it will use the hex equivalent. This is true. I have backported the API in r1530799, would it be possible to take a look for me? Work fine for me with the cmake-based build on Windows (MSVC). Thanks! Regards, Graham -- -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH] apr escape API, portability issues seen on Windows
On 10 Oct 2013, at 12:37 AM, Jeff Trawick traw...@gmail.com wrote: Work fine for me with the cmake-based build on Windows (MSVC). Thanks! That's a relief. Thanks for the review, I appreciate it. Regards, Graham --
[PATCH] apr escape API, portability issues seen on Windows
I dug into the glitches seen on Windows... \e is a non-portable escape
(GNU extension), and shell escaping treats \n differently on Windows and
OS/2, which the testcase didn't account for.
I guess the code that used \e doesn't match anything in httpd?
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: encoding/apr_escape.c
===
--- encoding/apr_escape.c (revision 1528671)
+++ encoding/apr_escape.c (working copy)
@@ -862,11 +862,6 @@
size++;
found = 1;
break;
-case '\e':
-*d++ = 'e';
-size++;
-found = 1;
-break;
case '\f':
*d++ = 'f';
size++;
@@ -931,7 +926,6 @@
switch (c) {
case '\a':
case '\b':
-case '\e':
case '\f':
case '\n':
case '\r':
Index: test/testescape.c
===
--- test/testescape.c (revision 1528671)
+++ test/testescape.c (working copy)
@@ -34,15 +34,33 @@
apr_pool_create(pool, NULL);
+src = Hello World ;`'\|*?~^()[]{}$\\;
+target = Hello World
;\\`\\'\|\\*\\?\\~\\^\\(\\)\\[\\]\\{\\}\\$;
+dest = apr_pescape_shell(pool, src);
+ABTS_ASSERT(tc,
+apr_psprintf(pool, shell escaped (%s) does not match expected
output (%s),
+ dest, target),
+(strcmp(dest, target) == 0));
+apr_escape_shell(NULL, src, APR_ESCAPE_STRING, len);
+ABTS_ASSERT(tc,
+apr_psprintf(pool, size mismatch (% APR_SIZE_T_FMT !=%
APR_SIZE_T_FMT ), len, strlen(dest) + 1),
+(len == strlen(dest) + 1));
+
+#if !(defined(OS2) || defined(WIN32))
+/* Now try with newline, which is converted to a space on OS/2 and Windows.
+ */
src = Hello World ;`'\|*?~^()[]{}$\\\n;
target = Hello World
;\\`\\'\|\\*\\?\\~\\^\\(\\)\\[\\]\\{\\}\\$\\\n;
dest = apr_pescape_shell(pool, src);
-ABTS_ASSERT(tc, shell escaped matches expected output,
+ABTS_ASSERT(tc,
+apr_psprintf(pool, shell escaped (%s) does not match expected
output (%s),
+ dest, target),
(strcmp(dest, target) == 0));
apr_escape_shell(NULL, src, APR_ESCAPE_STRING, len);
ABTS_ASSERT(tc,
apr_psprintf(pool, size mismatch (% APR_SIZE_T_FMT !=%
APR_SIZE_T_FMT ), len, strlen(dest) + 1),
(len == strlen(dest) + 1));
+#endif
src = Hello;
dest = apr_punescape_url(pool, src, NULL, NULL, 0);
@@ -196,8 +214,8 @@
dest = apr_pescape_echo(pool, src, 0);
ABTS_PTR_EQUAL(tc, src, dest);
-src = \a\b\e\f\\n\r\t\v\Hello World\;
-target = \\a\\b\\e\\fn\\r\\t\\v\Hello World\;
+src = \a\b\f\\n\r\t\v\Hello World\;
+target = \\a\\b\\fn\\r\\t\\v\Hello World\;
dest = apr_pescape_echo(pool, src, 0);
ABTS_STR_EQUAL(tc, target, dest);
apr_escape_echo(NULL, src, APR_ESCAPE_STRING, 0, len);
@@ -205,8 +223,8 @@
apr_psprintf(pool, size mismatch (% APR_SIZE_T_FMT !=%
APR_SIZE_T_FMT ), len, strlen(dest) + 1),
(len == strlen(dest) + 1));
-src = \a\b\e\f\\n\r\t\v\Hello World\;
-target = \\a\\b\\e\\fn\\r\\t\\v\\\Hello World\\\;
+src = \a\b\f\\n\r\t\v\Hello World\;
+target = \\a\\b\\fn\\r\\t\\v\\\Hello World\\\;
dest = apr_pescape_echo(pool, src, 1);
ABTS_STR_EQUAL(tc, target, dest);
apr_escape_echo(NULL, src, APR_ESCAPE_STRING, 1, len);
APR and portability issues - /usr/include gets skipped by configure when apr is external
Call it innocence, call it naive, call it whatever - but APR is an obstacle to be overcome. There is documentation, but lacks an overview of what/how apr is used. X pages long list of variables does not help prepare one (read me if you will) for proper usage. CASE: built apr, apr-util, httpd on separate system. Want to verify process used to create build on another system. Unfortunately, apr has undefined variables so cannot build in second environment - install APR and APR-UTIL packaged in previous environment. Insert extra files in /usr/include same as on original system. Start configure - runs well until zlib is needed (copy files to /usr/include, per above and compile conftest.c successfully). Run configure again, still fails. My guess, after looking at the log output is that while /usr/include/zlib.h was found and used on the original system now configure is only using the /opt/include where the files are not located. Request: please think about the basic documentation - right now if you follow the documentation link the first page is one that seems to be there is no documentation. The other navigation items show otherwise - but what are all these functions, modules, etc. And how do they explain that configure does not work. p.s. the first hint that something was wrong was the return of a static name for a compiler (was cc - xlc was better), but now working with gcc - so everything fails. -- I have learned that apr and apr-util are largely static - executable caching of variables - is that one way of describing how it works? Note: I have no idea of what is in libapr or libaprutil - but I am concerned that they are not going to be portable enough to use across different hardware/os platforms even those platforms are binary compatible. Also - maybe - the problems are limited to apr-1-config and apu-1-config. Here is hoping! Note: 6000-ibm-aix: bad number ... Is this because this is an AIX 7.1 system? It moves on, thankfully, but thought this was the cause initially. == ./configure[5865]: 6000-ibm-aix: bad number + cp conftest.c mytest.c + ac_fn_c_try_link 11027 + print -r -- configure:11035: result: not found + 1 5 + print -r -- not found + 1 6 + enable_deflate=no + INCLUDES=-I$(top_builddir)/srclib/pcre -I. -I$(top_srcdir)/os/$(OS_DIR) -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) -I$(top_srcdir)/modules/http -I$(top_srcdir)/modules/filters -I$(top_srcdir)/modules/proxy -I$(top_srcdir)/include -I$(top_srcdir)/modules/generators -I$(top_srcdir)/modules/mappers -I$(top_srcdir)/modules/database -I/opt/include -I/usr/include/openssl/include + LDFLAGS= -L/usr/include/openssl/lib + rm -f core conftest.err conftest.o conftest conftest.c + test x-lm -lz = x-lz + apr_new_bugger= + apr_removed=0 + test x-lm != x-lz + apr_new_bugger= -lm + test x-lz != x-lz + apr_removed=1 + test 1 = 1 + test x != xyes + echo removed -lz from LIBS + LIBS= -lm + CPPFLAGS= + print -r -- configure:11066: checking whether to enable mod_deflate + 1 5 + print -rn -- checking whether to enable mod_deflate... + 1 6 + test no = no + test yes = no + as_fn_error mod_deflate has been requested but can not be built due to prerequisite failures 11072 5 configure: error: mod_deflate has been requested but can not be built due to prerequisite failures + exit_status=1 + 1 5 ===
Re: APR and portability issues - /usr/include gets skipped by configure when apr is external
On 3/1/2012 6:55 PM, Michael Felt wrote: Note: I have no idea of what is in libapr or libaprutil - but I am concerned that they are not going to be portable enough to use across different hardware/os platforms even those platforms are binary compatible. Also - maybe - the problems are limited to apr-1-config and apu-1-config. Here is hoping! FWIW I've built APR on some 100 different combinations of OS major.minor vs some dozen sun/intel/ibm/hp cpu architectures at one time or another. AIX, HP/UX, Solaris, Linux, BSD, Darwin, Windows, etc etc etc. Not BS2000, and I'm missing a couple other esoteric, although I know it builds on those from others folks experiences. You need to get APR built, pay attention to ./configure output. The only AIX build I now deal with is xlc_r. Then, you need to build APR-util, depending on APR, expat, various dbm and and dbd providers, and recently openssl - which depends on zlib. You'll only know if you are succeeding or failing by studying the ./configure output, which should tell you what was detected and what detection failed. APR is entirely portable. It isn't our headache whether (in your example) zlib is installed in a consistent way. If you discover that a dependency is not predictable you may need to create yet another dependency package.
Re: APR and portability issues - /usr/include gets skipped by configure when apr is external
On Thu, Mar 1, 2012 at 7:55 PM, Michael Felt mamf...@gmail.com wrote: Call it innocence, call it naive, call it whatever - but APR is an obstacle to be overcome. There is documentation, but lacks an overview of what/how apr is used. X pages long list of variables does not help prepare one (read me if you will) for proper usage. CASE: built apr, apr-util, httpd on separate system. Want to verify process used to create build on another system. Unfortunately, apr has undefined variables so cannot build in second environment - install APR and APR-UTIL packaged in previous environment. Insert extra files in /usr/include same as on original system. Start configure - runs well until zlib is needed (copy files to /usr/include, per above and compile conftest.c successfully). Run configure again, still fails. My guess, after looking at the log output is that while /usr/include/zlib.h was found and used on the original system now configure is only using the /opt/include where the files are not located. Request: please think about the basic documentation - right now if you follow the documentation link the first page is one that seems to be there is no documentation. The other navigation items show otherwise - but what are all these functions, modules, etc. And how do they explain that configure does not work. p.s. the first hint that something was wrong was the return of a static name for a compiler (was cc - xlc was better), but now working with gcc - so everything fails. -- I have learned that apr and apr-util are largely static - executable caching of variables - is that one way of describing how it works? Note: I have no idea of what is in libapr or libaprutil - but I am concerned that they are not going to be portable enough to use across different hardware/os platforms even those platforms are binary compatible. Also - maybe - the problems are limited to apr-1-config and apu-1-config. Here is hoping! Note: 6000-ibm-aix: bad number ... Is this because this is an AIX 7.1 system? It moves on, thankfully, but thought this was the cause initially. == ./configure[5865]: 6000-ibm-aix: bad number + cp conftest.c mytest.c + ac_fn_c_try_link 11027 + print -r -- configure:11035: result: not found + 1 5 + print -r -- not found + 1 6 + enable_deflate=no + INCLUDES=-I$(top_builddir)/srclib/pcre -I. -I$(top_srcdir)/os/$(OS_DIR) -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) -I$(top_srcdir)/modules/http -I$(top_srcdir)/modules/filters -I$(top_srcdir)/modules/proxy -I$(top_srcdir)/include -I$(top_srcdir)/modules/generators -I$(top_srcdir)/modules/mappers -I$(top_srcdir)/modules/database -I/opt/include -I/usr/include/openssl/include + LDFLAGS= -L/usr/include/openssl/lib + rm -f core conftest.err conftest.o conftest conftest.c + test x-lm -lz = x-lz + apr_new_bugger= + apr_removed=0 + test x-lm != x-lz + apr_new_bugger= -lm + test x-lz != x-lz + apr_removed=1 + test 1 = 1 + test x != xyes + echo removed -lz from LIBS + LIBS= -lm + CPPFLAGS= + print -r -- configure:11066: checking whether to enable mod_deflate + 1 5 + print -rn -- checking whether to enable mod_deflate... + 1 6 + test no = no + test yes = no + as_fn_error mod_deflate has been requested but can not be built due to prerequisite failures 11072 5 configure: error: mod_deflate has been requested but can not be built due to prerequisite failures + exit_status=1 + 1 5 === That's way too much to grok :) What you're showing above is part of the httpd build, not part of apr. zlib isn't used by apr. apr and apr-util are code -- networking, management of private and shared memory, files, etc. -- but I guess if you're having trouble building it the autoconf side may seem to be the whole thing. httpd uses some autoconf macros from APR and they use the apr_ prefix. This is the apr list, so why not take the opportunity to make sure apr and apr-util are building as we expect... apr 1.4.6: CC=xlc_r ./configure --prefix=whatever make make install make test Proceed with apr-util 1.4.1: Similar to the above, but point to your apr using the --with-apr parameter to configure Does that work on all your systems, substituting the desired compiler front-end for xlc_r? Do you need to try other configure arguments for one reason or another? I don't know about the AIX level support/that error message... Does this display something reasonable? build/config.sub `build/config.guess`
Re: Porting APR to QNX4: portability problems.
Hello dev, The APR is really cool stuff - it has it's own implementation of the apr_snprintf() so that it almost works even without the underlaying int64-aware printf()|scanf(). Of the four failing tests here in the ./test/testfmt.c, three were actually from the QNX4's native snprintf(). The fourth failure is credited to the apr_snprintf() which handles well any unsigned value and breaks on the signed decimal one larger or equal to (hexadecimal) 0x8000. May be it is not even the apr_snprintf()'s fault again but my toolchain's... I cannot negotiate with these declarations: #define APR_INT64_C(val) (val##LL) #define APR_UINT64_C(val) (val##ULL) They seems, do not change anything in the OpenWATCOM v1.6RC1... The size of long long is detected to be == 8. The formatters chosen by ./configure are: lld llu respectively... Please comment! Thank you in advance. -- Best regards, Anthony mailto:[EMAIL PROTECTED]
Porting APR-UTIL to QNX4: portability problems.
Hello dev, Having a sort of ported APR v1.2.8 library I tryed to port APR-UTIL v1.2.8 testall reports 100% passage. Some tests (the testqueue and the testreslist) just report they badly need the threads to run. The testrmm does not build because of no shared memory. The testxlate complains about no UTF-8 support... The testdate blows as expected - I still could not obtain the proper version of the clib with int64-aware scanf|printf. And the testxml reports some unidentifyed internal error. It prints lots of screens of the following: 0: element mary 1: element had 1: attrs a=little 1: element lamb 1: attrs its=fleece was white as snow 1: element hmm 1: attrs for=dinner roast=lamb 1: element hmm 1: attrs for=dinner roast=lamb ...a huge snip... 1: element hmm 1: attrs for=dinner roast=lamb 1: element hmm 1: attrs for=dinner roast=lamb APR Error Internal error XML Error: XML parser error code: mismatched tag (7) (EXPECTED) This is good. The expat library passed it's own tests and also was perceived as 100%-usable in the neon's testsuite. I wonder if I'm doomed... Please comment. -- Best regards, Anthony mailto:[EMAIL PROTECTED]
Re: Porting APR to QNX4: portability problems.
генерал Пурпоз 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.
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 longs, 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:[EMAIL PROTECTED]
Re: Porting APR to QNX4: portability problems.
генерал Пурпоз wrote: With the official compiler (Watcom C v10.6B) the configuration script detects the absence of long longs, 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.
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 int2 int..4 long int.4 float4 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, Anthonymailto:[EMAIL PROTECTED]
Re[2]: Porting APR to QNX4: portability problems.
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 [EMAIL PROTECTED] //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:[EMAIL PROTECTED]
Re: Porting APR to QNX4: portability problems.
генерал Пурпоз 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 [EMAIL PROTECTED] //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.
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 [EMAIL PROTECTED] //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:[EMAIL PROTECTED]
Re: Porting APR to QNX4: portability problems.
генерал Пурпоз 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.
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 longs 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:[EMAIL PROTECTED]
Re: Porting APR to QNX4: portability problems.
On 1/28/07, генерал Пурпоз [EMAIL PROTECTED] 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 longs 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.
Portability of apr_file_writev_full?
apreq has a similar function, and some questions
came up yesterday regarding its implementation. So
I took a look at the recent apr implementation,
and I have a few questions of my own regarding this loop:
do {
apr_size_t i, amt;
status = apr_file_writev(thefile, vec, nvec, amt);
/* We assume that writev will only write complete iovec areas.
* Incomplete writes inside a single area are not supported.
* This should be safe according to SuS v2.
*/
for (i = 0; i nvec; i++) {
total += vec[i].iov_len;
if (total = amt) {
vec = vec[i+1];
nvec -= i+1;
break;
}
}
} while (status == APR_SUCCESS nvec 0);
First, this is the only implementation I could find in apr,
so I assume its being used on non-unix platforms where SuS v2
does not apply, particularly wrt writev() itself.
Second, I disagree that SuS v2 makes any guarantees about writev()
only writing complete iovec areas. I assume a conforming writev()
implementation can hand the single-iovec case off to write(). So if
there's more data in the iovec than the target device can accept,
it winds up doing a partial write, successfully.
IMO the statement in SuS: the writev() function shall always write a
complete area before proceeding to the next should be interpreted
conservatively: the implementation isn't allowed to move on to the
next iovec, unless it can write all of the current one.
--
Joe Schaefer
Re: Portability of apr_file_writev_full?
On Thu, Mar 10, 2005 at 10:01:37AM -0500, Joe Schaefer wrote: ... Second, I disagree that SuS v2 makes any guarantees about writev() only writing complete iovec areas. I assume a conforming writev() implementation can hand the single-iovec case off to write(). So if there's more data in the iovec than the target device can accept, it winds up doing a partial write, successfully. Yes it's broken as you indicate, I pointed this out when it was committed... this had dropped off my radar at least. It needs to call apr_file_write_full to complete writing any partially-written buffer, or something like that. joe
Re: Portability of apr_file_writev_full?
Joe Orton wrote: On Thu, Mar 10, 2005 at 10:01:37AM -0500, Joe Schaefer wrote: ... Second, I disagree that SuS v2 makes any guarantees about writev() only writing complete iovec areas. I assume a conforming writev() implementation can hand the single-iovec case off to write(). So if there's more data in the iovec than the target device can accept, it winds up doing a partial write, successfully. Yes it's broken as you indicate, I pointed this out when it was committed... this had dropped off my radar at least. It needs to call apr_file_write_full to complete writing any partially-written buffer, or something like that. Yep, my fault. It dropped off my radar too. I will try to fix it this weekend. -Paul
Re: portability
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void
*))dummy_worker,
(*new), 0, temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
If you let us know which compiler fails for you, we can
have a look at it. Let us know the compiler's defined()
macro signature as well.
lcc-win32
__LCC__
However there are a bunch of other things I had to add/modify to
get libapr0.93 somehwat compiled. I now fail miserable with the 1.x
version because of poll problem.
What poll problem? we use network_io/unix/select.c, not poll.c.
That's interesting, the .dsw file I had uses poll.c from the unix
subdirectory at least it was part of the project...
Howerver it was still not an easy going to get libapr compiled on
MSVC, so I either I've messed up my MSVC, Windows or libapr or the
might be another problem
You might try a clean checkout.
That is what I'm going to do again and I have to check how the build
process is supposed to work I assume I've modfied files I should not
have touched
Regards
Friedrich
portability
This may sound a bit ridicolous, however I wonder how serious you are about the portability of the code used for libapr. Is it wanted that compiler/llibrary internals of specific compilers are used? Or is that considered a bug? Regards Friedrich
Re: portability
Friedrich Dominicus wrote: This may sound a bit ridicolous, however I wonder how serious you are about the portability of the code used for libapr. Is it wanted that compiler/llibrary internals of specific compilers are used? Or is that considered a bug? It needs to be portable ;-) Seriously, if you have some way to make something a bazillion times faster by using a gcc extension then I suppose it might be considered, but you'd also have to provide a non-gcc version of the code for cases where that wasn't possible. People compile APR with all sorts of compilters. -garrett
Re: portability
sorry, it should have gone to the list. I probably just have hit reply... Regards Friedrich
Re: portability
Garrett Rooney [EMAIL PROTECTED] writes:
Friedrich Dominicus wrote:
This may sound a bit ridicolous, however I wonder how serious you are
about the portability of the code used for libapr. Is it wanted that
compiler/llibrary internals of specific compilers are used? Or is that
considered a bug?
It needs to be portable ;-)
Seriously, if you have some way to make something a bazillion times
faster by using a gcc extension then I suppose it might be considered,
but you'd also have to provide a non-gcc version of the code for cases
where that wasn't possible. People compile APR with all sorts of
compilters.
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
(*new), 0, temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
#else
*/
if (((*new)-td = CreateThread(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
(*new), 0, temp)) == 0) {
return apr_get_os_error();
}
// #endif
The latter works on Windows XP and probably others as well whereas the
first one uses a compiler specific internal symbol
Regards
Friedrich
Re: portability
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void
*))dummy_worker,
(*new), 0, temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
If you let us know which compiler fails for you, we can
have a look at it. Let us know the compiler's defined()
macro signature as well.
lcc-win32
__LCC__
However there are a bunch of other things I had to add/modify to
get libapr0.93 somehwat compiled. I now fail miserable with the 1.x
version because of poll problem.
Howerver it was still not an easy going to get libapr compiled on
MSVC, so I either I've messed up my MSVC, Windows or libapr or the
might be another problem
The point which we have trouble with are this declarations
#elif defined(APR_DECLARE_EXPORT)
#define APR_DECLARE(type)__declspec(dllexport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllexport) type
#define APR_DECLARE_DATA __declspec(dllexport)
#else
#define APR_DECLARE(type)__declspec(dllimport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllimport) type
#define APR_DECLARE_DATA __declspec(dllimport)
The declaration while building a DLL seem to be ok, but Mr Navia the
author of lcc-win32 thinks that the APR_DECLARE in the else part is
wrong. Maybe you can point us to the documentaton on where this is
required.
Regards
Friedrich
Re: portability
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void
*))dummy_worker,
(*new), 0, temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
If you let us know which compiler fails for you, we can
have a look at it. Let us know the compiler's defined()
macro signature as well.
lcc-win32
__LCC__
However there are a bunch of other things I had to add/modify to
get libapr0.93 somehwat compiled. I now fail miserable with the 1.x
version because of poll problem.
What poll problem? we use network_io/unix/select.c, not poll.c.
Howerver it was still not an easy going to get libapr compiled on
MSVC, so I either I've messed up my MSVC, Windows or libapr or the
might be another problem
You might try a clean checkout.
The point which we have trouble with are this declarations
#elif defined(APR_DECLARE_EXPORT)
#define APR_DECLARE(type)__declspec(dllexport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllexport) type
#define APR_DECLARE_DATA __declspec(dllexport)
#else
#define APR_DECLARE(type)__declspec(dllimport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllimport) type
#define APR_DECLARE_DATA __declspec(dllimport)
The declaration while building a DLL seem to be ok, but Mr Navia the
author of lcc-win32 thinks that the APR_DECLARE in the else part is
wrong. Maybe you can point us to the documentaton on where this is
required.
There is no error. You need to declare dllimport in order
to ensure these functions are mapped. If Mr Navia is certain
that all relocation stubs (ESPECIALLY data relocations!!!) don't
need special handling under lcc, he should simply recognize and
ignore that __declspec construct.
If you are trying to build STATIC .lib - you must define the
macro APR_DECLARE_STATIC when building the library. You can
also use it when compiling against the static library headers
in your own app to save the compiler lots of fixups.
Bill
APR benefits beyond portability for www.asterisk.org
Hi Over on the asterisk mailing list ([EMAIL PROTECTED]) there is a little discussion on what would be the best match for a portability layer for the core phone functions in asterisk... custom brew cygwin GTK ACS Netscape etc etc Beyond the portability are there other benefits you have noticed using APR in the last few years on the Apache Web server -maintenace -learning curve -how about performance?? -stability ?? etc thanks assming this will make it to the dev list
: APR benefits beyond portability for www.asterisk.org
Hi I posted this before I go registered for this List I am not sure if it got seen, sorry if a report .. Over on the asterisk mailing list ([EMAIL PROTECTED]) there is a little discussion on what would be the best match for a portability layer for the core phone functions in asterisk... custom brew cygwin GTK ACE NSPR ... Netscape etc etc Beyond the portability are there other benefits you have noticed using APR in the last few years on the Apache Web server -maintenace -learning curve -how about performance?? -stability ?? etc thanks assming this will make it to the dev list
Re: APR benefits beyond portability for www.asterisk.org
On Mon, 26 Aug 2002, TC wrote: Hi Over on the asterisk mailing list ([EMAIL PROTECTED]) there is a little discussion on what would be the best match for a portability layer for the core phone functions in asterisk... custom brew cygwin GTK ACS Netscape etc etc Beyond the portability are there other benefits you have noticed using APR in the last few years on the Apache Web server I would be happy to answer this. But first, let me comment on a few of the options above, and some of what we have learned. I want to be clear that I am not bad-mouthing ANY of those projects, they are all good, but we have some knowledge in this area, so I am trying to help. 1) Custom brew: Please don't. There are hundreds of custom portability projects in the world today (most of them proprietary), the portability problem will only really be solved when we all work together on it. APR (and the other projects above) have learned a lot from creating portable libraries, use an existing library, and just make it better. 2) cygwin: I like the idea of cygwin, but in practice, I have found that it doesn't work. The problem is that cygwin binaries are not native Windows binaries, so you will never get the performance you want when using cygwin. As for other advantages to APR. -maintenace -learning curve maintenance and learning curve generally go together in my mind. If the learning curve is too high, the maintenance is impossible. If the learning curve is low, the maintenance is generally easy. APR excels in both areas. People new to APR generally pick it up quickly, because the functions are easy to understand, and they mirror POSIX as closely as possible. The hardest thing to grasp is the memory pooloing. -how about performance?? Apache has not suffered from performance problems related to APR, although any portable run-time does incur some performance penalty. We have a couple of people who work very hard to ensure that our performance is the best that it can be. -stability ?? APR is stable. Code written on top of APR is stable, assuming the program is written correctly. As for the library itself, we do still make small tweaks to the API occaisionally, but we are finishing all of those up now. You are asking about APR at the best possible time, because we are about to release 1.0, and we have stated that the API will not change during major releases. Hope all of this helps you make your decision. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: APR benefits beyond portability for www.asterisk.org
At 10:45 AM 8/27/2002, Ryan Bloom wrote: On Mon, 26 Aug 2002, TC wrote: ... The hardest thing to grasp is the memory pooloing. -how about performance?? Apache has not suffered from performance problems related to APR, although any portable run-time does incur some performance penalty. We have a couple of people who work very hard to ensure that our performance is the best that it can be. -stability ?? APR is stable. Code written on top of APR is stable, assuming the program is written correctly. As for the library itself, we do still make small tweaks to the API occaisionally, but we are finishing all of those up now. You are asking about APR at the best possible time, because we are about to release 1.0, and we have stated that the API will not change during major releases. Funny that rbb mentioned pooling and then tried to cover stability and performance without bringing back up that concept :-) Memory pooling is what makes apr and pool-based applications relatively very stable over very long runs, with a huge performance win. By tying a transaction's memory and resources to it's own pool, you get very clean garbage collection for pennies on the dollar, compared to any other garbage collection schema. They are worth learning about. I'd just caution you one point about the API entry points. Unlike some other libraries built for robustness-in-spite-of-programmer-error, APR has very little argument checking for validity. If it will [safely] segfault, we leave the segfaults out there as testament to the programmer's mistake. Only when the bad-argument condition would be nearly undetected, or open a security hole do we add in argument checking. For out-of-memory conditions, we consider those fatal [which they are for nearly any application, and probably the OS is near-death as well.] We will invoke a registered callback first, but then the application will be clobbered. Bill
Re: APR benefits beyond portability for www.asterisk.org
IMHO, if you are going to be creating a GUI, then use a PR that is specifically designed to give good X-platform GUI's. APR is not that project. If you had a non-GUI project, then APR would be a much better fit for you. Ryan On Tue, 27 Aug 2002, TC wrote: Beyond the portability are there other benefits you have noticed using APR in the last few years on the Apache Web server I would be happy to answer this. But first, let me comment on a few of the options above, and some of what we have learned. I want to be clear that I am not bad-mouthing ANY of those projects, they are all good, but we have some knowledge in this area, so I am trying to help. So what types of projects are more suited to APR. right now with asterisk for example they are trying to get the functions for a basic phone up on win32, these are running in linux OS now it includes these types of functions the IAX VoIP protocol layer... phonecore which actually implements a phone, with controls for driving various aspects of its operation (i.e. adding new calls, switching between active calls, changing audio devices, conferencing, etc) so these are not like a server based process like the core asterisk PBX but more like a personal productivity app, most of this port once the phonecore is up will be about the GUI portion... getting this UI over gnophone.com/ so does it still make sense to use APR as the portability of the core then yet another portability layer for the GUI say like wxWindows or is there a better strategy .. -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Split paths portability
William A. Rowe, Jr. wrote:
While we consider Stas' ideas for a portable tmpdir, we should also
consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
If you need the implementation details look at how Perl does it. it's in
File::Spec which is a set of function working on Files/Dirs
crossplatform. In this particular case these are the functions you want
to look at:
splitpath
splitdir
catdir
catfile
and a few other useful functions.
Currently Perl includes implementations for:
/home/stas/perl.org/perl-current/lib/File/Spec/Cygwin.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Epoc.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Mac.pm
/home/stas/perl.org/perl-current/lib/File/Spec/OS2.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Unix.pm
/home/stas/perl.org/perl-current/lib/File/Spec/VMS.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Win32.pm
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Split paths portability
At 10:29 PM 4/17/2002, you wrote:
William A. Rowe, Jr. wrote:
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
If you need the implementation details look at how Perl does it. it's in
File::Spec which is a set of function working on Files/Dirs crossplatform.
Thanks. Those too would be good. I was first considering simply splitting
apart paths from a list. While a variable such as TEMP or TMP can simply be
passed to apr_filepath_merge(), you can't do that with path lists like PATH,
LIB or INCLUDE.
Split paths portability
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
Two options; the one I like best (I think) is returning an apr_array_header_t *
allocated based on a pool arg. Contrawise, we should also have a function
that returns a char* from an apr_array_header_t. Something like;
apr_array_header_t *apr_filepath_list_split(const char *pathlist,
apr_pool_t *pool);
char *apr_filepath_list_join(apr_array_header_t *paths, apr_pool_t *pool);
Any objections?
Bill
Re: Split paths portability
At 02:16 PM 4/17/2002, William A. Rowe, Jr. wrote:
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
Two options; the one I like best (I think) is returning an
apr_array_header_t *
allocated based on a pool arg. Contrawise, we should also have a function
that returns a char* from an apr_array_header_t. Something like;
apr_array_header_t *apr_filepath_list_split(const char *pathlist,
apr_pool_t *pool);
char *apr_filepath_list_join(apr_array_header_t *paths, apr_pool_t *pool);
Hmmm. While I think about this, I also suppose we aught to add the same
flags
option we pass to apr_filepath_merge and family.
We should allow the user to retrieve a list of APR_FILEPATH_NATIVE strings, or
by default, turn them into APR-recognized format (e.g. forward slashes on
Win32,
etc.) And on apr_filepath_list_join, we should allow APR_FILEPATH_NATIVE to
create platform-recognized paths for substitution as the PATH variable, etc.
Other thoughts or observations?
Bill
File permision portability
[deliberately crossposted] Hi all, Can someone give me a quick answer if file permissions are made portable in apr. Specifically, are ntfs acls mapped to the flags that show up in include/apr_file_info.h? Subversion needs to portably handle at least the execute and write permissions, which is my reason for asking. Sander
Re: File permision portability
On Friday 05 October 2001 12:24 pm, Sander Striker wrote: [deliberately crossposted] Hi all, Can someone give me a quick answer if file permissions are made portable in apr. Specifically, are ntfs acls mapped to the flags that show up in include/apr_file_info.h? Subversion needs to portably handle at least the execute and write permissions, which is my reason for asking. They aren't, but they need to be made portable. When I first wrote the file perm code, I didn't have the patience, or the knowledge to do portable perms across platforms, so I punted. If you want to take a stab, I am more than happy to help. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
