issue 15645 - Prevent unsafe usage of Tuple.slice#5342
issue 15645 - Prevent unsafe usage of Tuple.slice#5342dlang-bot merged 1 commit intodlang:masterfrom
Conversation
|
|
LGTM. Deferring to @andralex for merging, though. |
andralex
left a comment
andralex
left a comment
There was a problem hiding this comment.
This is a very nice idea. Do you think you could replace the use of inout with the template this parameter? https://dlang.org/spec/template.html#TemplateThisParameter
I continue to get feedback from users that find inout inscrutably complex and difficult to understand and use. Less use of it in the standard library would be great. Thanks!
Because the return type is different from the type of I know that
I figure if we actually ship this with the next release, then either some |
|
@tsbockman I'm thinking of returning |
Because the return type is being applied by a manual, |
|
Ok thanks.
On Wed, May 17, 2017 at 10:51 AM tsbockman ***@***.***> wrote:
I'm thinking of returning ref auto
Because the return type is being applied by a manual, @System cast, the
function would still need to manually compute the correct const-ness. It
could be done, but it would be a lot more code (and possibly template
bloat).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAill_3m7aNYOkSYRy95wcPIRPMMneMOks5r6wlagaJpZM4NEuE1>
.
--
Please excuse terseness and typos
|
|
@andralex So, is this ready to merge, then? |
|
Yes, I am just afk.
On Wed, May 17, 2017 at 1:04 PM tsbockman ***@***.***> wrote:
@andralex <https://github.com/andralex> So, is this ready to merge, then?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAill7JZtYrB30KPTiYNY5gVgRFl38EMks5r6yi1gaJpZM4NEuE1>
.
--
Please excuse terseness and typos
|
|
|
||
| // Phobos issue #15645 | ||
| Tuple!(int, short, bool, double) b; | ||
| static assert(!__traits(compiles, b.slice!(2, 4))); |
There was a problem hiding this comment.
I don't know much about this code, but isn't the 4 out of bounds? Or are the arguments 1-indexed?
There was a problem hiding this comment.
From the docs:
to = A
size_tdesignating the ending position (exclusive) of the slice.
|
Thanks, guys. |
5 participants
This is a mitigation for Phobos issue 15645 - Tuple.slice() causes memory corruption.
Through several previous discussions, the community reached the conclusion that there is no good solution to this problem - that is, one which preserves all of the following desirable characteristics:
Tupleslices are just 100% normalTuples.The candidates solutions were:
A) Front-pad Tuple by-ref slices as needed to correct the alignment of the members. (Violates 4 & 5)
B) Slice by-value instead. (Violates 1 & 3)
C) Prevent unsafe usage with a
static assertat compile time. (Violates 2)I strongly favour (A), but my work was vetoed by @andralex , theoretically in favour of (B). However, no one has stepped forward to actually implement (B) and in the mean time
Tupleis still silently corrupting data.So, I offer (C) as a temporary stop-gap, either until someone implements (B), or the community decides to revisit my original proposal.
This PR is small, simple, and a strict improvement over the current situation. Replacing it with (A) or (B) at a later date should not break any code that wouldn't have been broken anyway.