i nuked all unneded calls to php_header() - i'm not too sure how we do
handle HEAD Requests as they were only detected via php_header(). but calling
php_header from a module makes output-buffering unusable.
NOTICE: there is some EBSDIC stuff in gd.c - i think it's obsolete.
guys, always remember that every function that *generates output* could cause a
bailout if ignore_user_abort is set to false (and the user _aborts_ the
connection). in this case a longjump will be performed and our function (in
this case readfile) will have no chance to clean-up. having said that it's a
good idea to register all opened files using REGISTER_RESOURCE - that way the
engine will make sure they get closed on request end.
and then simply write it out to the target file. That avoids switching
between user and kernel land too many times. If that does not work, we
fall back to the read/write method.
* Fixed a bug in zend_rsrc_list_get_rsrc_type()
* Switched register_list_destructors() to use
zend_register_list_destructors_ex() instead
* Updated all relevant modules to provide the resource type name
to register_list_destructors() call
* Updated var_dump() to output resource type name instead of number
@- Made resource type names visible, e.g. var_dump() and
@ get_resource_type() display "file" for file resources. (Andrei)
- Introduce php_open_temporary_file(), in place of tempnam(). Still
needs testing under UNIX (mkstemp()), works reliably under Windows now.
- Reimplement the mechanism for unlinking uploaded files at the end of the request
(was it ever tested?). Files moved with move_uploaded_file() will not be unlink()'d
again, to avoid (albeit very unlikely) race conditions.
- So here is the short version:
- a) Start moving to binary opens in Windows
- b) Give checkuid_mode() a small face lift including the fopen-wrappers.c
- The mode to this function should at least be a #define but that is for
- another day. Anyway this whole stuff should be given more face lifts in
- the future.