httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Portability of APR.
Date Mon, 13 Sep 1999 18:26:25 GMT

> I was looking at APR file_io and see some problems with it with regard to
> VMS.  In VMS, the number of data bytes a file would return when read
> as a stream is not knowable in all cases (some text file formats are
> stored on disk with a non-stream structure which the C runtime converts
> to a LF-delimited stream as it is reading the file).  The API should specify
> a way to distinguish this case.  

I need to think about this a bit more.  But I think it can be done in the
current API just fine.

>VMS doesn't save the last access time for a 
> file, just creation and last modified time.  

I honestly think you are fine using the last modified time and the access

> I'm also leery of the
> way you define ap_remove_file()'s semantics - the unlink() semantics for
> open files don't map well to VMS.

Would youmind elaborating on this a bit?

> I'm not sure I get the purpose of the ap_os_file_t and ap_put_os_file() and
> ap_get_os_file().  It seems to me such functions are only valid to use in
> platform-specific code sections, in which case I'd rather they be named
> things like ap_get_os_unix_file()/ap_get_os_win32_file().  You can then detect
> when someone tries to use platform-specific code on the wrong platform.

The goal of the ap_(get|put)_os_* functions are to allow apr'ized programs
to interact with the rest of the world.  The must be used in platform
specific code.  (That's a lie, but I'll explain that soon).  For example,
if mod_php wants to interact with an Oracle database, it needs a non-apr
type to do so, because Oracle doesn't understand apr.  As Manoj likes to
tell me "The world doesn't use APR" (Or something to that effect).  Having
said that, with a coupld of nicely placed #defines, it is possible to
write portable code that uses these functions.  For example:

#include "apr_portable.h"
#ifdef Win32
#define SEND(x, y, z) WSASend(x, y)
#define SEND(x, y, z) write(x, y, z)

ap_status_t write_to_network(ap_sock_t *sock, char *buf)
ap_os_sock_t *temp = NULL;

ap_get_os_sock(sock, &temp); 
SEND(temp, buf, strlen(buf);

That's a really simplistic example, but it SHOULD work if for some reason,
you NEEDED to send using native types.  The compiler should be smart
enough to figure out if you are using the wrong type with
ap_(get|put)_os_*.  We shouldn't need separate functions for each


Ryan Bloom
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

View raw message