8000 The termination handling logic in the readLine method conflicts with the annotation description (line 343) · Issue #348 · vigna/fastutil · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

The termination handling logic in the readLine method conflicts with the annotation description (line 343) #348

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.

Sign up for GitHub

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

Jump to bottom
Closed
1341005547 opened this issue May 26, 2025 · 2 comments
Closed

The termination handling logic in the readLine method conflicts with the annotation description (line 343) #348

1341005547 opened this issue May 26, 2025 · 2 comments

Comments

@1341005547
Copy link

fastutil/src/it/unimi/dsi/fastutil/io/FastBufferedInputStream.java

Line 343 in ff5c6c5

array[off + read++] = '\n';

The comment clearly states that the terminator should not be included in the returned array, but the code adds CR or LF to the array when LF is not matched.
For example, when the user does not specify LF as the terminator, the code will still write LF characters to the array, which violates the design intent and may result in data errors.
@vigna
Copy link
Owner
vigna commented May 26, 2025

I think you're misreading the code.

@vigna vigna closed this as completed May 26, 2025
@1341005547
Copy link
Author
1341005547 commented May 26, 2025 •
edited
Loading

I think you're misreading the code.
Yes, the input has been restricted to LineTerminator; This 5F39 logic should be targeted at the CR_LF scenario.
I scanned the code statically using the Sophie tool. I have also discovered two other suspicious points. Can I discuss them with you?

  1. Arrays.mergeSort(final int from, final int to, final IntComparator c, final Swapper swapper)
    Using recursive implementation may result in stack overflow. When dealing with very large arrays, the recursion depth may exceed the default stack size of the Java Virtual Machine

  2. Function.getOrDefault(final Object key, final V defaultValue)
    The default implementation of the containsKey method (line 146) always returns true, which can cause the getOrDefault method (line 130) to fail to correctly determine whether the key actually exists. When get (key) returns null, even if the key does not exist, containsKey returning true will result in an incorrect return of null instead of defaultValue. This violates the standard behavior of Map.getOrDefault and is a functional logic error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vigna @1341005547
0