-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
Misc #354
base: main
Are you sure you want to change the base?
Misc #354
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the unsafe
blocks, this looks reasonable to me
src/handlers/graphical.rs
Outdated
Line { | ||
line_number: context_data.line() + line_number + 1, | ||
offset: context_data.span().offset() | ||
+ unsafe { line.as_ptr().offset_from(context.as_ptr()) as usize }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this unsafe
block is sound, but it would be good to have a // SAFETY:
comment explaining the reasoning. I had to do a bit of digging to convince myself that it's not possible to have context.len() > isize::MAX
.
Alternatively, you could avoid the offset_from
call entirely by keeping a mutable offset
variable and doing offset += line.len()
or similar inside the map closure. That's a little ugly, but I'd personally prefer it to unsafe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the exact opposite of what I wanted to do. The whole reason I went with offset_from
is to avoid using an offset
variable, because that variable is a possible source of errors if not computed right (and indeed, such problem in the previous code is why I started to look at this piece of code in the first place).
Also, from a semantic point of view, the "offset from" meaning is what we are looking for ("the offset of line from the beginning of the data buffer"). A + line.len()
is only indirectly related to that info. It's only correct if, and only if, the various lines follow each other exactly, without gaps nor overlaps. In particular, it requires the use of split_inclusive
instead of the more common split
1, creating, IMO, an unnecessary dependency between the split and the offset computation.
And yes it's safe per design:
The theoretical upper bound on object and array size is the maximum isize value. This ensures that isize can be used to calculate differences between pointers into an object or array and can address every byte within an object along with one byte past the end.
Footnotes
-
I would have used
split
except that it causes some other issues in some corner cases (I can't remember if it was when the data terminates with a newline or when the data was empty) ↩
- Fix a panic when a 0 length span covers the end of a document - Fix incorrect `line_count` - Add new unit tests and complete existing ones - Improve readability
The first two (refactor) are simplification of the code.
On the last one (fix), regarding the default SourceCode implementations:
\r
was handled as a newline, but is not supported in other places (Graphical/Narrated). So this too, depending on how one squints, it could be a breaking change or not.