fix undefined conversion

[ruquanzhao]

Signed-off-by: Ruquan Zhao ruquan.zhao@arm.com

What type of PR is this?

/kind bug

What this PR does / why we need it:

This PR fixes an uint64(f float64) convertion which is an undefined behavior when the f <= -1.
ref: https://go.dev/ref/spec#Conversions

In this testcase, thinkDuration = -1, which will eventually result in uint(-9.97e+07).

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Hi @ruquanzhao. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cici37]

/assign @MikeSpreitzer
/triage accepted

[MikeSpreitzer]

I am not sure I understand the point here.

(1) The cited doc does not assert that any numeric conversion is undefined.

(2) The behavior I find in the go playground does not match what I thought the words in the doc meant.

(3) Look at https://go.dev/play/p/_icC51O4TUO . It shows that the proposed change makes no difference.

(4) A floating point value of -9.97e+07 is well within the range that converts to ints with no surprise.

(5) Thanks for catching the typo.

[MikeSpreitzer]

/ok-to-test

[ruquanzhao]

@MikeSpreitzer Thanks for your reply!
In cited doc, there is one line:

In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent.

which means something like uint64(-100) is implementation-dependent ( because the value -100 is not in [0,2^63-1] ),
On x86-64, unit64() is implemented just like uint64(int64()), so the playground shows that they are all equal.
On some other arch, uint64() is not implement like x86-64; for example, on arm64, uint64() will return 0 if the floatNum <= -1.
Here is the issue link in golang community golang/go#43047
Below is the output on arm64:

f=-9.97e+07, u1=0 (0x0000000000000000), u2=18446744073609851616 (0xfffffffffa0eb2e0), eq=false
f=-1.844e+19, u1=0 (0x0000000000000000), u2=9223372036854775808 (0x8000000000000000), eq=false
f=-2e+19, u1=0 (0x0000000000000000), u2=9223372036854775808 (0x8000000000000000), eq=false

(4) A floating point value of -9.97e+07 is well within the range that converts to ints with no surprise.

Yes, -9.97e+07 is in range int64 but not in range uint64.

[ruquanzhao]

/retest

[MikeSpreitzer]

@ruquanzhao : thanks for the clarification and counter-example. I had interpreted those words differently.

[MikeSpreitzer]

/lgtm
Thanks!

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: cec22964a09bd09beb75777d4e66a347bc7a2210

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MikeSpreitzer, ruquanzhao

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/apiserver/pkg/util/flowcontrol/OWNERS [MikeSpreitzer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[MikeSpreitzer]

BTW, typo in the title here: it is spelled "conversion".

[MikeSpreitzer]

/release-note-none

[ruquanzhao]

TBW, typo in the title here: it is spelled "conversion".

Thanks! BTW