php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #78052 exif_read_data chokes on strict_types for parameter 2
Submitted: 2019-05-22 19:10 UTC Modified: 2021-07-07 12:42 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: c dot schiffler at cyberspectrum dot de Assigned: kalle (profile)
Status: Closed Package: EXIF related
PHP Version: 7.3.5 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: c dot schiffler at cyberspectrum dot de
New email:
PHP Version: OS:

 

 [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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-22 19:19 UTC] spam2 at rhsoft dot net 
param 2 is type string . period

exif_read_data ( mixed $stream [, string $sections = NULL [, bool $arrays = FALSE [, bool $thumbnail = FALSE ]]] ) : array
 [2019-05-22 19:21 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2019-05-22 19:21 UTC] requinix@php.net 
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 = ""
 [2019-05-22 22:33 UTC] cmb@php.net 
An alternative would be to actually allow passing NULL, i.e.

  Z_PARAM_STR_EX(z_sections_needed, 1, 0)
 [2019-05-23 09:20 UTC] nikic@php.net 
Agree with cmb, I think it would be better to allow an explicit null here.
 [2019-05-23 13:54 UTC] requinix@php.net 
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));
 [2019-09-12 16:16 UTC] kalle@php.net
-Status: Verified +Status: Assigned -Assigned To: +Assigned To: kalle
 [2021-07-07 12:42 UTC] cmb@php.net
-Status: Assigned +Status: Closed
 [2021-07-07 12:42 UTC] cmb@php.net 
This is fixed as of PHP 8.0.0[1], and I suggest to leave it at
this.

[1] <https://www.php.net/manual/en/function.exif-read-data.php#refsect1-function.exif-read-data-changelog>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC