Fix GH-17317: ResourceBundle crash on undefined iterator key. #17318
Conversation
| --CREDITS-- | ||
| KidFlo |
There was a problem hiding this comment.
I don't think we should add a CREDIT section to new tests; see also https://qa.php.net/phpt_details.php#credits_section.
There was a problem hiding this comment.
I disagree; I often add CREDITS section. Co-authored-by doesn't allow fine-grained tracking of what a person did, so that's a downgrade in comparison to the CREDITS section.
There was a problem hiding this comment.
Then we should probably change the description accordingly. :)
| if (EXPECTED(iterator->currentkey)) { | ||
| ZVAL_STRING(key, iterator->currentkey); | ||
| } else { | ||
| ZVAL_NULL(key); | ||
| } |
There was a problem hiding this comment.
That doesn't look quite right, since the corresponding value would be Z_ISUNDEF and we (usually) don't expose these.
I have no idea, though, what to do instead when resourcebundle_iterator_read() fails with U_MISSING_RESOURCE_ERROR. Hmm, since (new ResourceBundle('', NULL))->get('calendar')->get('buddhist')->get(3) returns null, maybe we should also set the value to null.
| ZVAL_STRING(key, iterator->currentkey); | ||
| } else { | ||
| ZVAL_NULL(key); | ||
| ZVAL_NULL(&iterator->current); |
There was a problem hiding this comment.
Setting this here wouldn't have any effect when users traverse over the values only. Changing it in resourcebundle_iterator_read() would require more changes (elsewhere there are checks for Z_ISUNDEF(iterator->current)), and we might break existing semantics. Maybe resourcebundle_iterator_current() would need to return null, but we don't have a zval there. :/
And I wonder about:
$rb = (new ResourceBundle('', NULL))->get('calendar')->get('buddhist');
var_dump($rb->get(3));
var_dump($rb->getErrorMessage());
foreach ($rb as $key => $value) {
var_dump($key);
var_dump($rb->getErrorMessage());
}That reports Cannot load resource element 3: U_MISSING_RESOURCE_ERROR after the ::get() call, but U_ZERO_ERROR when traversing.
Given that value only traversal so far "worked" but returned undef values (and apparently nobody complained), maybe as bugfix we should just set the key to undef (instead of null), and try a proper fix in the master branch only.
There was a problem hiding this comment.
Given that value only traversal so far "worked" but returned undef values (and apparently nobody complained), maybe as bugfix we should just set the key to undef (instead of null), and try a proper fix in the master branch only.
I wanted to this at first but it seemed to me the more spread fashion was to set to NULL.
There was a problem hiding this comment.
Yeah, exposing undef values is certainly uncommon, while having null as iterator key is not.
There was a problem hiding this comment.
it seems to cause issue with JIT.
There was a problem hiding this comment.
Undef values should never get exposed to userland.
There was a problem hiding this comment.
Yeah, but how to solve that for the values (they are already undef)?
There was a problem hiding this comment.
I will take a look in this issue in a few hours. In general undef should be transformed into null but this is weird in this case. Possibly the undef values should be skipped, which is conceptually similar to arrays. But anyway, I will first try to understand how and why sometime later today.
| echo "VALUE: "; var_dump($value); | ||
| } | ||
| ?> | ||
| --EXPECT-- |
There was a problem hiding this comment.
Should use --EXPECTF-- here to be able to use placeholders for the specifc filenames (and line numbers) of the warnings below.
And maybe the test is overspecified; I have no idea how likely it is that the details of this resource bundle will change in ICU versions.
No description provided.