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.

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

Bug in display: Certain slices not working within string() #3595

Closed
jsshapiro opened this issue Dec 10, 2023 · 0 comments · Fixed by #3596
Closed

Bug in display: Certain slices not working within string() #3595

jsshapiro opened this issue Dec 10, 2023 · 0 comments · Fixed by #3596
Labels
area/cli kind/bug

Comments

@jsshapiro
Copy link

Delve Version: 1.21.2
Go Version: 1.21.5 , but this has been an issue for many many versions
MacOS/ARM

Issue:

Input is often handled as []byte, making it important to be able to display such values as strings during debugging. Given a byte slice of the form bytes[e:] (where e is an expression)

dlv -a string(bytes[5:]) // Prints expected byte slice as a string
dlv -a string(bytes[pos:])  // Always shows the empty string

That is: the expression evaluation fails if the first argument of the slice operation is non-constant.

Further, I have just noticed that string(bytes[0:40]) doesn't work either, no matter what constants are used - it shows the empty string.

Using the %s format in the display addition has no impact on this outcome. In fact, it doesn't print the string representation at al. Even more fun, display -a %s string(bytes[5:] prints no value at all, even though it works fine without the format specifier.

I haven't dug in to the code, but I'm guessing this is a deficiency or a bug within the expression evaluator.
aarzilli added a commit to aarzilli/delve that referenced this issue Dec 11, 2023
@aarzilli
proc: make some type casts less counterintuitive
71cd664 
The interaction of type casts with load configuration is sometimes
counterintuitive. This commit changes the way it is performed so that
when converting slices to strings and vice versa the maximum size
corresponding to the target type is used (i.e. MaxStringLen when
converting slices to strings and MaxArrayValues when converting slices
to strings).

This doesn't fully solve the problem (conversions to []rune are
problematic and multiple chained type casts will still be confusing)
but removes the problem for the majority of practical uses.

Fixes go-delve#3595, go-delve#3539
@aarzilli aarzilli mentioned this issue Dec 11, 2023
Merged
derekparker pushed a commit that referenced this issue Dec 12, 2023
@aarzilli
proc: make some type casts less counterintuitive
57dad93 
* proc: make some type casts less counterintuitive

The interaction of type casts with load configuration is sometimes
counterintuitive. This commit changes the way it is performed so that
when converting slices to strings and vice versa the maximum size
corresponding to the target type is used (i.e. MaxStringLen when
converting slices to strings and MaxArrayValues when converting slices
to strings).

This doesn't fully solve the problem (conversions to []rune are
problematic and multiple chained type casts will still be confusing)
but removes the problem for the majority of practical uses.

Fixes #3595, #3539
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/cli kind/bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

proc: make some type casts less counterintuitive aarzilli/delve
2 participants
@aarzilli @jsshapiro