Re: cvs commit: apr/build os2_libtool.m4
I have not tested this on OS/2, but it should work assuming that the emx environment is close enough to normal unix to run configure. This is basically what Jeff was saying we should do to support platforms that don't like libtool. Roy
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
[EMAIL PROTECTED] writes: trawick 01/03/31 05:25:46 Modified:include/arch/unix networkio.h network_io/unix sendrecv.c sockets.c Log: apr_recvfrom() should only return APR_EOF if recvfrom() returned zero *AND* this is a stream socket. rc zero from a datagram socket just means that somebody sent you a zero-byte datagram. Remove the minimal parm checking from recvfrom()... better to segfault as with most of the rest of APR. The same basic change is needed for other apr_recvfrom() implementation(s)... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
From: [EMAIL PROTECTED] Sent: Saturday, March 31, 2001 7:25 AM trawick 01/03/31 05:25:46 Modified:include/arch/unix networkio.h network_io/unix sendrecv.c sockets.c Log: apr_recvfrom() should only return APR_EOF if recvfrom() returned zero *AND* this is a stream socket. ... cool (all 8 or so of your commits), and thanks for the review Jeff :-) Wanted to ask you win32 folks (now that we ought to be building again), has anyone else been using apr/test/makefile.win? With success? I'd just like to point out an opportunity for any win hackers, feel free to attack the test sources and apr-ize the unix-specific stuff. They each tend to focus on a specific API, leaving a ton of non-compileable or non-functional calls for win32 and other arcane OS's. We are further than we were, but it's still not a cross-platform suite. Bill
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
has anyone else been using apr/test/makefile.win? With success? I'd just like to point out an opportunity for any win hackers, feel free to attack the test sources and apr-ize the unix-specific stuff. They each tend to focus on a specific API, leaving a ton of non-compileable or non-functional calls for win32 and other arcane OS's. We are further than we were, but it's still not a cross-platform suite. Sorry about that. The test suite was originally just a hack to help David Reid and I port code between Unix and BeOS. I then decided to make it useful to everybody. I just never got around to making it portable. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
From: [EMAIL PROTECTED] Sent: Saturday, March 31, 2001 10:46 AM has anyone else been using apr/test/makefile.win? With success? I'd just like to point out an opportunity for any win hackers, feel free to attack the test sources and apr-ize the unix-specific stuff. They each tend to focus on a specific API, leaving a ton of non-compileable or non-functional calls for win32 and other arcane OS's. We are further than we were, but it's still not a cross-platform suite. Sorry about that. The test suite was originally just a hack to help David Reid and I port code between Unix and BeOS. I then decided to make it useful to everybody. I just never got around to making it portable. :-) And you are personally responsible for every component of apr :-? Really... as we find, we fix, and if it did it's first job, then cool. With it's new responsiblity, anyone with the gumption to make it crossplatform is welcome to jump in :-)
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
On Sat, 31 Mar 2001, William A. Rowe, Jr. wrote: From: [EMAIL PROTECTED] Sent: Saturday, March 31, 2001 10:46 AM has anyone else been using apr/test/makefile.win? With success? I'd just like to point out an opportunity for any win hackers, feel free to attack the test sources and apr-ize the unix-specific stuff. They each tend to focus on a specific API, leaving a ton of non-compileable or non-functional calls for win32 and other arcane OS's. We are further than we were, but it's still not a cross-platform suite. Sorry about that. The test suite was originally just a hack to help David Reid and I port code between Unix and BeOS. I then decided to make it useful to everybody. I just never got around to making it portable. :-) And you are personally responsible for every component of apr :-? Really... as we find, we fix, and if it did it's first job, then cool. With it's new responsiblity, anyone with the gumption to make it crossplatform is welcome to jump in :-) didn't mean to say it was my job to fix it, just trying to give a bit of history to this stuff. I feel guilty when people find problems with the stuff I did a few years ago. By explaining what happened, I am trying to lessen my guilt. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/network_io/unix sendrecv.c sockets.c
William A. Rowe, Jr. [EMAIL PROTECTED] writes: has anyone else been using apr/test/makefile.win? With success? I just used it the first time and quickly found an opportunity (run-time exception). Thanks for the perl. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/file_io/unix filepath.c Makefile.in
On Sat, Mar 31, 2001 at 06:22:38AM -, [EMAIL PROTECTED] wrote:
...
+/**
+ * Extract the rootpath from the given filepath
+ * @param rootpath the root file path returned with APR_SUCCESS or
APR_EINCOMPLETE
+ * @param filepath the pathname to parse for it's root component
+ * @param p the pool to allocate the new path string from
+ * @deffunc apr_status_t apr_filepath_root(const char **rootpath, const
char **inpath, apr_pool_t *p)
+ * @tip on return, filepath now points to the character following the root.
+ * In the simplest example, given a filepath of /foo, returns the
rootpath
+ * of / and filepath points at foo. This is far more complex on other
+ * platforms, which even changes alternate format of rootpath to canonical
+ * form. The function returns APR_ERELATIVE if filepath isn't rooted (an
+ * error), APR_EINCOMPLETE if the root path is ambigious (but potentially
+ * legitimate, e.g. / on Windows is incomplete because it doesn't specify
+ * the drive letter), or APR_EBADPATH if the root is simply invalid.
+ * APR_SUCCESS is returned if filepath is an absolute path.
+ */
I don't think it should ever return APR_EINCOMPLETE. If there is no drive
letter, then it should just return APR_ERELATIVE.
And don't say current drive because then you could say current
directory. There is no effective difference between them.
...
APR_DECLARE(apr_status_t) apr_filepath_parse_root(const char **rootpath,
const char **inpath,
apr_pool_t *p)
{
if (**inpath == '/')
{
*rootpath = apr_pstrdup(p, /);
++*inpath;
return APR_EABSOLUTE;
}
return APR_ERELATIVE;
}
Euh... I expected rootpath to be /foo/bar/ if it was passed /foo/bar/baz
Is the above function just a first hack, or was the intent to only return a
single / ??
If it *is* just a first hack, then you MUST leave a comment in there.
Otherwise, you get people (like me) wondering wtf is going on in there.
APR_DECLARE(apr_status_t) apr_filepath_merge(char **newpath,
const char *rootpath,
const char *addpath,
apr_int32_t flags,
apr_pool_t *p)
{
char path[APR_PATH_MAX];
apr_size_t rootlen; /* is the original rootpath len */
apr_size_t newseg; /* is the path offset to the added path */
apr_size_t addseg; /* is the path offset we are appending at */
addseg is more descriptive as pathlen, the current path length.
apr_size_t endseg; /* is the end of the current segment */
And this would be seglen.
apr_status_t rv;
/* Treat null as an empty path.
*/
if (!addpath)
addpath = ;
if (addpath[0] == '/')
{
/* If addpath is rooted, then rootpath is unused.
* Ths violates any APR_FILEPATH_SECUREROOTTEST and
* APR_FILEPATH_NOTABSOLUTE flags specified.
*/
if (flags APR_FILEPATH_SECUREROOTTEST)
return APR_EABOVEROOT;
if (flags APR_FILEPATH_NOTABSOLUTE)
return APR_EABSOLUTE;
/* If APR_FILEPATH_NOTABOVEROOT wasn't specified,
* we won't test the root again, it's ignored.
* Waste no CPU retrieving the working path.
*/
if (!rootpath !(flags APR_FILEPATH_NOTABOVEROOT))
rootpath = ;
}
else
{
/* If APR_FILEPATH_NOTABSOLUTE is specified, the caller
* requires a relative result. If the rootpath is
* ommitted, we do not retrieve the working path,
* if rootpath was supplied as absolute then fail.
*/
if (flags APR_FILEPATH_NOTABSOLUTE)
{
if (!rootpath)
rootpath = ;
else if (rootpath[0] == '/')
return APR_EABSOLUTE;
}
}
if (!rootpath)
{
/* Start with the current working path. This is bass akwards,
* but required since the compiler (at least vc) doesn't like
* passing the address of a char const* for a char** arg.
*/
char *getpath;
rv = apr_filepath_get(getpath, p);
rootpath = getpath;
if (rv != APR_SUCCESS)
return errno;
/* XXX: Any kernel subject to goofy, uncanonical results
* must run the rootpath against the user's given flags.
* Simplest would be a recursive call to apr_filepath_merge
* with an empty (not null) rootpath and addpath of the cwd.
*/
}
rootlen = strlen(rootpath);
Re: cvs commit: apr/test testmd5.c
What's the problem? Are you saying that we can't ever use
atexit(apr_terminate) ?? We do this in many places, so let's hear a bit more
about what is wrong...
Cheers,
-g
On Sat, Mar 31, 2001 at 07:29:06AM -, [EMAIL PROTECTED] wrote:
wrowe 01/03/30 23:29:06
Modified:test testmd5.c
Log:
This hurts on win32 at the moment, work around apr_terminate
Revision ChangesPath
1.7 +6 -1 apr/test/testmd5.c
Index: testmd5.c
===
RCS file: /home/cvs/apr/test/testmd5.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- testmd5.c 2001/02/16 04:16:09 1.6
+++ testmd5.c 2001/03/31 07:29:06 1.7
@@ -83,6 +83,11 @@
\xd1\xa1\xc0\x97\x8a\x60\xbb\xfb\x2a\x25\x46\x9d\xa5\xae\xd0\xb0}
};
+static void closeapr(void)
+{
+apr_terminate();
+}
+
static void try(const void *buf, size_t bufLen, apr_xlate_t *xlate,
const void *digest)
{
@@ -152,7 +157,7 @@
rv = apr_initialize();
assert(!rv);
-atexit(apr_terminate);
+atexit(closeapr);
rv = apr_pool_create(pool, NULL);
--
Greg Stein, http://www.lyra.org/
