Skip to content

ext/intl: introduce SpoofChecker::areBidiConfusable. - #13469

Closed
devnexen wants to merge 1 commit into
php:masterfrom
devnexen:ext_intl_spoof_arebidirectionalconfusable
Closed

ext/intl: introduce SpoofChecker::areBidiConfusable.#13469
devnexen wants to merge 1 commit into
php:masterfrom
devnexen:ext_intl_spoof_arebidirectionalconfusable

Conversation

@devnexen

Copy link
Copy Markdown
Member

Adding a new more refined spoofchecker method in addition of the existing SpoofChecker::areConfusable which takes in account the text direction
left to right and right to left.
Adding UBIDI_LTR, UBIDI_RTL, UBIDI_MIXED and UBIDI_NEUTRAL.

@devnexen
devnexen force-pushed the ext_intl_spoof_arebidirectionalconfusable branch 2 times, most recently from b2f7b85 to 740f0df Compare February 22, 2024 06:44
@devnexen
devnexen marked this pull request as ready for review February 22, 2024 17:12
@devnexen
devnexen requested a review from kocsismate as a code owner February 22, 2024 17:12
}
if (U_FAILURE(SPOOFCHECKER_ERROR_CODE(co))) {
php_error_docref(NULL, E_WARNING, "(%d) %s", SPOOFCHECKER_ERROR_CODE(co), u_errorName(SPOOFCHECKER_ERROR_CODE(co)));
RETURN_TRUE;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we return true in case on failures? Is this behavior OK? Shouldn't we rather throw?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was being consistent with the existing areConfusable method. I may adjust spoofchecker class behavior in a separate commit like I m doing with IntlTimeZone

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the failures are related to programmatic errors, then it's surely better to throw. The one error case I can immediately see is however related to string length, which seems like a user-related one, but I guess it should be quite rare to exceed the limit. that's why I'm not really sure what to do. If we threw an exception, then the ugly reference param could also be avoided, which would be a nice advantage.

cc. @Girgias Do you have any opinion about this?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ehhhh not really, but shouldn't this go through the "normal" intl extension error handling mechanism so user can set if they want it to be silent/warning/error?

@LamentXU123

Copy link
Copy Markdown
Member

@devnexen Are you still interested in this? I'd be happy to supersede this because the code base has changed a lot since this PR was made and I think we need to rewrite this.

@devnexen
devnexen force-pushed the ext_intl_spoof_arebidirectionalconfusable branch from 740f0df to c20ae74 Compare August 3, 2026 09:58
@devnexen
devnexen requested a review from LamentXU123 as a code owner August 3, 2026 09:58

@LamentXU123 LamentXU123 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add this function to the following tests?

  • /ext/intl/tests/spoofchecker_self_references.phpt
  • /ext/intl/tests/spoofchecker_typed_references.phpt

Looks good otherwise!

Adding a new more refined spoofchecker method in addition of the existing
Spoofchecker::areConfusable which takes in account the text direction
left to right and right to left, along with the Spoofchecker::LTR and
Spoofchecker::RTL constants.

The self and typed references tests are extended accordingly, guarded at
runtime rather than through a SKIPIF, so that the older ICU releases keep
their coverage.
@devnexen
devnexen force-pushed the ext_intl_spoof_arebidirectionalconfusable branch from c20ae74 to 721167e Compare August 3, 2026 10:55
@devnexen devnexen closed this in f985f77 Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants