That does not seem to affect how the code works except when creating a new
structure, in which case 'M' fields used to get created with size 9.
@Fixed bug 6852 #2. Mem fields are now 10 bytesin size, not 9. (Vlad)
Verified that the problem is real when creating new files and writing
a record. Both fixed and old versions seem to be able to somehow read
and write already existing files properly though.
@Fixed bug 6852 #1. No more null byte after terminating 0x0D. (Vlad)
than a long, dbase_get_record() and dbase_get_record_with_names() will
return a string instead.
# Need to update documentation to reflect that change
@ Fixed problem with dbase not returning very large (larger than long)
@ integers properly. (Vlad)
* 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)
Added a few RCS $Id$ tags.
# Note: I have avoided changing any .h files if the corresponding .c file
# had not already been changed as I am not sure if there are any legal
# issues here. So some extensions still have PHP 3 headers.
Draft 3 of IEEE 1003.1 200x, "2.2 The Compilation Environment"
All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use by the
implementation.
- 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.