|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #80444 blank filled character fields..
Submitted: 2020-11-29 17:15 UTC Modified: 2021-03-16 11:14 UTC
Avg. Score:4.3 ± 0.9
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: fly_with_me at gmx dot at Assigned:
Status: Open Package: dbase (PECL)
PHP Version: Irrelevant OS: linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2020-11-29 17:15 UTC] fly_with_me at gmx dot at
Some older dbase applications stores binary data into "character" fields. Since "character" fields always use "%-2s (for two chars) the result is always a blank filled string in php. 

Now the old application treat this fields "as is". In c language is 0x0 char end of char (in the snprintf function in dbase.c line 441 (in version 7.0.1). 

db_format is always set so memcpy never comes in use..

I don't know how to fix this problem, because of some possible side effects in php? I even don't know how to treat 'binary' strings in php, means what happens, if the binary packed data in a character field starts with a zero (or contain more zeros)...

Test script:
unfortunately I cannot provid sample dbase data due to security reasons (I cannot create new data with this old applications)... 

Expected result:
php function 'dbase_get_record_with_names' should provide 'character' fields also 'as is', means store all data as chars in buffer with field-size


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-11-30 13:00 UTC]
Well, yes, I think this is a bug.  While there is no official
dBASE specification, an apparently pretty good compilation of
dBASE docs[1] says the character fields are supposed to support
"all OEM code page characters", and that would include NUL bytes.
Furthermore, I see no reason not to support them, since PHP
strings are binary safe by themselves, and depending on the
functions used for such binary strings, can be handled pretty

Of course, changing this behavior would constitute a BC break, and
might better be postponed to a new major dbase version (8.0).  Or
maybe adding an optional $flags parameter to dbase_open() and

[1] <>
 [2020-11-30 18:18 UTC] fly_with_me at gmx dot at
An optional $flags parameter to dbase_open() sounds great in this case..
(because I need to find a solution for this problem to access old data very soon, and other tools are way too bad to use).

Maybe like:
dbase_open ( string $path , int $mode [, int $flag = 0]) : resource

with a appropriate flag name for "handle char fields as binary".
 [2020-11-30 20:27 UTC]
-Assigned To: +Assigned To: cmb
 [2020-12-01 16:48 UTC] fly_with_me at gmx dot at
another solution can be a new function like:

dbase_get_raw_record ( resource $database , int $number ) : array
dbase_get_raw_record_with_names ( resource $database , int $number ) : array

while the resulting array contains all field data in sting buffers... 

This does not affect all of the data changing routines and I think this does not result in a BC break
 [2021-03-16 11:14 UTC]
-Assigned To: cmb +Assigned To:
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Oct 03 12:01:26 2023 UTC