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

sbyte array comparison doesn't work correctly with negative values #5263

Open
manofstick opened this issue Jun 30, 2018 · 10 comments
Open

sbyte array comparison doesn't work correctly with negative values #5263

manofstick opened this issue Jun 30, 2018 · 10 comments
Labels
Area-Library Issues for FSharp.Core not covered elsewhere Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Milestone

Comments

@manofstick
Copy link
Contributor

Whilst working on the IComparable (which includes the inequality operators) version of #5112, I found that the currently implementation of sbyte[] do not work correctly when one of the operands is negative.

Repro steps

let a = -1y
let b = 0y

printfn "%b" (a < b)
printfn "%b" ([a] < [b])
printfn "%b" ([|a|] < [|b|])

Expected behavior

true
true
true

Actual behavior

true
true
false

Known workarounds

None. Well could convert the array to a list and then do a comparison there (if you can).

Related information

This was found when I was creating the alternative implementation and then running against the test suite created in #577. So presumably this has been a bug dating back prior to the creation of that regression suite (Aug 9, 2015). So probably no urgency to fix, and when the next PR that I'm working on is done then it will be cleared up.

@forki
Copy link
Contributor

forki commented Jun 30, 2018

Urgs. Can you please submit this in a pr as a separate test to fsharp.core's test suite?

Also this makes a strong case for more property based tests.

@vasily-kirichenko
Copy link
Contributor

vasily-kirichenko commented Jun 30, 2018

Look at this:

image

It results with going this route https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Core/prim-types.fs#L838, i.e. comparing sbyte arrays as byte arrays with the wrong result.

@vasily-kirichenko
Copy link
Contributor

The opposite has bug too

image

@vasily-kirichenko
Copy link
Contributor

C# has it also

image

@vasily-kirichenko
Copy link
Contributor

Fixed in #5267

manofstick added a commit to manofstick/visualfsharp that referenced this issue Jul 3, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Jul 11, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Aug 7, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Aug 7, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Aug 7, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Aug 8, 2018
manofstick added a commit to manofstick/visualfsharp that referenced this issue Aug 12, 2018
@cartermp cartermp added the Area-Library Issues for FSharp.Core not covered elsewhere label Aug 13, 2018
@cartermp
Copy link
Contributor

Labeling, though given that this is explicitly marked as "fast path" and the C# behavior, this may be by design.

@forki
Copy link
Contributor

forki commented Aug 13, 2018

It's by design to give wrong answer?

@manofstick
Copy link
Contributor Author

@cartermp

We'll the c# behaviour is not to compare array elements, so I don't think it's behaviour should be of any relevance here.

The comment re: fast path was due, I believe, to the fact that otherwise the general comparison would fall back to the array boxing comparer, not specifically to the sbyte case.

If this was by design there should have been some unit tests to show this functionality. The only tests that show the problem are the regression tests that I created to ensure backward compatibility when I was modifying equality and comparison operators - they should not be taken as truth, just regression. If there had been some generative tests in the first place they would have shown the problem sure to the inconsistency.

@cartermp
Copy link
Contributor

I'm perfectly in favor of this getting adjusted, I'm just a bit hesitant to advocate for that given the space. Lack of tests for that behavior is promising w.r.t making this change, but unfortunately there aren't always tests for intended behavior.

@dsyme dsyme added Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code. labels Sep 1, 2020
@vzarytovskii vzarytovskii moved this to Not Planned in F# Compiler and Tooling Jun 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Library Issues for FSharp.Core not covered elsewhere Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Projects
Status: New
Development

Successfully merging a pull request may close this issue.

5 participants