Too early in the morning. I just remembered fdopen() :)
Andi
At 07:14 AM 3/1/2001 +0200, Andi Gutmans wrote:
>This sounds pretty good. I'll try and look at the code this weekend. Some
>of the code is really ugly especially the legacy code.
>When you say there are places which need a FILE * do you mean they just
>need to check the id and check that it's a FILE * or do they convert
>descriptors to FILE * (can't remember if that's possible or not :).
>
>Andi
>
>At 02:12 AM 3/1/2001 +0000, Wez Furlong wrote:
>>I've just looked through the code.
>>
>>
>>
>>The current issock stuff is a bit of a nightmare, but not too much of a
>>problem.
>>
>>
>>
>>Most of the codebase seems to be fairly well behaved with FP_FGETS and
>>friends (apart from the interbase extension, where it does the same thing
>>as FP_FREAD without using FP_FREAD).
>>
>>
>>
>>The aim is to reduce three parameters to a single parameter for the FP_
>>family of macros.
>>
>>Ideally, it would be nice to do this for php_fopen_wrapper as well, and
>>have it return the "php_file" abstraction we are proposing. I'm not sure
>>how well people will like this
>>
>>in general, but thats why I'm talking about it and not changing the code
>>right now.
>>
>>
>>
>>Whenever an extension needs to open a file it also needs to complain if
>>it can't open it.
>>
>>All over the code we have the same checks to see if it is a socket or a
>>file, if it was opened, and if if wasn't complain, but first strip out a
>>password from the filename/url etc. etc.
>>
>>
>>
>>A suggestion is this:
>>
>>
>>
>>typedef struct _php_file {
>>
>> int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
>>
>> int (*write)(php_file *this_ptr, ....);
>>
>> int (*read)(php_file *this_ptr,....);
>>
>> int (*open)(php_file *this_ptr,....);
>>
>> int (*close)(php_file *this_ptr,.....);
>>
>> int (*seek)(php_file * this_ptr, ...); /* useful */
>>
>>} php_file;
>>
>>
>>
>>php_file * php_fopen_wrapper(char * filename, char * mode,
>>
>> int options,
>>
>> char ** opened_path,
>>
>> int report_error
>>
>> );
>>
>>
>>
>>Basically the same as the current implementation except that it returns
>>an abstraction rather than a bunch of alternatives.
>>
>>The report error flag will cause the fopen wrapper to display the error
>>message using the current active function name from the scripting engine,
>>saving a few lines of code for each call where error reporting is
>>required, and increasing maintainability.
>>
>>
>>
>>This is going to break code in 11 files, but that is relatively easy to fix.
>>
>>
>>
>>Some code requires that we get a FILE * back (the fopen_wrapper_for_zend
>>is one), and some requires a socket (the code in fsock.c), so we need a
>>way to get those out of the php_file:
>>
>>
>>
>>FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
>>
>>int PHP_FILE_GET_SOCKETD(php_file *)
>>
>>
>>
>>[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]
>>
>>
>>
>>These could be implemented as macros, provided that all stdio based
>>abstractions "descend" from a common structure where the FILE * lives at
>>the same structure offset, and likewise for the socketd versions. In the
>>common case, there will only be one of each of these types anyway.
>>
>>
>>
>>I don't think that any of this will have a special impact on win32
>>platforms (any more than unix), because we are too high level for that.
>>
>>
>>
>>The only real problem is cleaning up the code to use the php_file
>>abstraction instead of assuming it's getting a stdio fp back.
>>
>>
>>
>>Once all this is done, the SSL code could be written as an fopen wrapper.
>>
>>
>>
>>I'm getting tired, so I may have overlooked something glaringly obvious;
>>please let me know if
>>
>>I have, or if you have any other suggestions or improvements.
>>
>>
>>
>>--Wez.
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
