|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2019-05-22 19:10 UTC] c dot schiffler at cyberspectrum dot de
Description:
------------
Calling exif_read_data with null as second optional parameter results in a type error.
This results in impossibility to call exif_read_data having different values for parameter 3&4 but sticking to the null default of parameter 2.
Test script:
---------------
declare(strict_types=1);
// This errors out but should not.
exif_read_data('image.jpg', null, true, false);
// This is a workaround currently in use as internal functions are not affected by strict_types per https://bugs.php.net/bug.php?id=74750
call_user_func('exif_read_data', 'image.jpg', null, true, false);
Expected result:
----------------
Data should be extracted.
Actual result:
--------------
TypeError: exif_read_data() expects parameter 2 to be string, null given
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Nov 07 07:00:02 2025 UTC |
This could be a doc bug (have the argument default to "") however the source tests specifically for null to decide if it should process the argument at all so passing an empty string loses a bit of performance. I think -if (z_sections_needed) { +if (z_sections_needed && ZSTR_LEN(z_sections_needed)) { Then the small edit to the doc for string $sections = ""Yeah, on second thought an empty string would be weird - PHP does null everywhere for optional arguments, no reason to go against that here. But since someone will be in there anyways I think adding the ZSTR_LEN check is worth it, for hypothetical code like $sections = []; if ($should_get_file) $sections[] = "FILE"; if ($should_get_thumbnail) $sections[] = "THUMBNAIL"; $return = exif_read_data($stream, implode(",", $sections));