php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79567 yaml_parse_url assertion
Submitted: 2020-05-05 15:58 UTC Modified: 2020-05-07 04:30 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: anrdaemon at yandex dot ru Assigned: bd808 (profile)
Status: Closed Package: yaml (PECL)
PHP Version: 7.0.8 OS: Windows/64-bit
Private report: No CVE-ID: None
 [2020-05-05 15:58 UTC] anrdaemon at yandex dot ru
Description:
------------
Yes a continuation of https://bugs.php.net/bug.php?id=79494

See attached test case.

IMO, it should at least err out if it can't represent the parsed value.

Test script:
---------------
<?php

$data = array (
  'audioEnabled' =>
  array (
    0 => 132317787432502136,
    1 => 0,
  ),
);

var_dump($data);

$yaml = yaml_emit($data);
print $yaml;

$result = yaml_parse($yaml);
var_dump($result);

print "Was the data parsed correctly? ";
print $result == $data ? "Yes!\n" : "No...\n";


Expected result:
----------------
array(1) {
  ["audioEnabled"]=>
  array(2) {
    [0]=>
    int(132317787432502136)
    [1]=>
    int(0)
  }
}
---
audioEnabled:
- 132317787432502136
- 0
...
array(1) {
  ["audioEnabled"]=>
  array(2) {
    [0]=>
    int(132317787432502136)
    [1]=>
    int(0)
  }
}
Was the data parsed correctly? Yes!

Actual result:
--------------
array(1) {
  ["audioEnabled"]=>
  array(2) {
    [0]=>
    int(132317787432502136)
    [1]=>
    int(0)
  }
}
---
audioEnabled:
- 132317787432502136
- 0
...
array(1) {
  ["audioEnabled"]=>
  array(2) {
    [0]=>
    int(2147483647)
    [1]=>
    int(0)
  }
}
Was the data parsed correctly? No...

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-06 05:23 UTC] bd808@php.net
-Summary: The 64-bit YAML ext parser uses 32-bit signed integer arithmetics +Summary: yaml_parse_url assertion -Status: Open +Status: Verified -PHP Version: 7.4.5 +PHP Version: 7.0.8 -Assigned To: +Assigned To: bd808
 [2020-05-06 05:23 UTC] bd808@php.net
detect.c is not using the macros from <Zend/zend_long.h> when converting strings to longs. Instead it is using strtol(3) directly on all platforms.
 [2020-05-06 05:28 UTC] bd808@php.net
-Summary: yaml_parse_url assertion +Summary: Parsing long long values leads to truncation on LLP64 platforms
 [2020-05-06 05:35 UTC] bd808@php.net
The following pull request has been associated:

Patch Name: Use helpers from Zend to parse strings as numbers
On GitHub:  https://github.com/php/pecl-file_formats-yaml/pull/48
Patch:      https://github.com/php/pecl-file_formats-yaml/pull/48.patch
 [2020-05-07 01:39 UTC] bd808@php.net
-Status: Verified +Status: Closed
 [2020-05-07 01:39 UTC] bd808@php.net
I have merged a patch for this that will be part of the eventual v2.2.0 release.
 [2020-05-07 03:07 UTC] bd808@php.net
-Status: Closed +Status: Re-Opened
 [2020-05-07 03:07 UTC] bd808@php.net
TEST 14/73 [C:\projects\yaml\tests\bug_74886.phpt]
========DIFF========
013+     int(2147483647)
013-     int(3735928559)
========DONE========
FAIL Test PECL bug #74886 [C:\projects\yaml\tests\bug_74886.phpt]

Still getting 32-bit truncation on a hex value.
 [2020-05-07 04:30 UTC] bd808@php.net
-Summary: Parsing long long values leads to truncation on LLP64 platforms +Summary: yaml_parse_url assertion -Status: Re-Opened +Status: Closed
 [2020-05-07 04:30 UTC] bd808@php.net
The bug_74886 failure that I reopened this for is a false positive. That particular failure is happening on an x86 (32bit) runtime. Not much my library can do to make PHP_INT_MAX longer.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 09 23:01:30 2024 UTC