Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-37451: remove redundant code in _testcapimodule.c #14483

Closed
wants to merge 1 commit into from

Conversation

shihai1991
Copy link
Member

@shihai1991 shihai1991 commented Jun 30, 2019

@mangrisano
Copy link
Contributor

Hi. Thank you for the pull request. I'm not an expert, therefore, would you mind telling me why that is redundant? Just for learning. Thank you :)

Copy link
Contributor

@jdemeyer jdemeyer left a comment

Choose a reason for hiding this comment

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

I don't see why this code should be removed. It seems to be used for testing that PyUnicode_FromWideChar can deal with NULL-terminated and non-NULL-terminated buffers.

So at least, this PR needs better justification.

@shihai1991
Copy link
Member Author

I don't see why this code should be removed. It seems to be used for testing that PyUnicode_FromWideChar can deal with NULL-terminated and non-NULL-terminated buffers.

So at least, this PR needs better justification.

Jeroen, thanks for review.

PyUnicode_FromWideChar can return two kind of values of three scenarios:

  1. widechar_size + 1 if buffer is NULL or buflen > widechar_size + 1
    1.1 buffer is NULL can not happen in PyUnicode_FromWideChar because it have been judged in
    https://github.com/python/cpython/blob/master/Modules/_testcapimodule.c#L1852
    1.2 buflen > widechar_size + 1 is judged in _testcapimodule.c is ok.
  2. buflen
    2.1 the latest return value is buflen or size(buflen==size) because of
    https://github.com/python/cpython/blob/master/Objects/unicodeobject.c#L3164.

So I think the else statement in _testcapimodule.c is redundant.

@shihai1991
Copy link
Member Author

shihai1991 commented Jul 1, 2019

Hi. Thank you for the pull request. I'm not an expert, therefore, would you mind telling me why that is redundant? Just for learning. Thank you :)

Hi, Michele. Discussing process over result ;). I have answered upstairs.

@shihai1991 shihai1991 reopened this Jul 1, 2019
@brettcannon brettcannon added the type-feature A feature request or enhancement label Jul 5, 2019
Copy link
Contributor

@jdemeyer jdemeyer left a comment

Choose a reason for hiding this comment

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

OK, I see what you mean now. But given that it took me a while to understand why your PR was correct, I'm not convinced that we should merge it as-is.

@shihai1991
Copy link
Member Author

OK, I see what you mean now. But given that it took me a while to understand why your PR was correct, I'm not convinced that we should merge it as-is.

it's a small change and don't effect any functions, if core teams think it is not necessary, pls help me close this PR.
Don't waste too much time on it ;)

@zhangyangyu
Copy link
Member

Thanks for the contribution and I could understand your logic. It actually is from my point of view but it's quite tiny and doesn't affect anything so I think it's not necessary to change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting core review type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants