httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Jones <>
Subject Re: Portability of APR.
Date Mon, 13 Sep 1999 21:03:00 GMT
In message <>,
  Ryan Bloom <> writes:
>>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.

Please spell out how the initialized file_t is supposed to indicate that the
size attribute is 'unknowable'.  Any code that uses the size field
(i.e. content-length: header generation) must also do the proper checks.

>>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

Do you mean use the last modified time as the last access time?

>> 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?

A common way to create a temporary file on Unix is to create the file
and then unlink it so when the file is closed the file system deletes it
because the inode has no references.  In VMS, to create a temporary
file you tell the file system to create a file with the 'scratch' attribute
(which has no directory entry) or create a file with the 'delete-on-close'
attribute (directory entry exists until the file is closed).  The defined 
semantics for ap_remove_file() tempt one to use it as a substitute for 
unlink() that can be used in non-portable ways.

> 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

That assumes that if the ap_sock_t type is an int, then that int must
be a file descriptor suitable for passing to the write() function.  This is
a non-portable assumption that will not be caught by the compiler if violated.

David L. Jones               |      Phone:    (614) 292-6929
Ohio State University        |      Internet:
140 W. 19th St. Rm. 231a     |     
Columbus, OH 43210           |     

Disclaimer: Dogs can't tell it's not bacon.

View raw message