You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem here is pretty obvious based on the error message: strlen(s) is finding a NUL byte after N bytes, but $&read has actually gcallocd more than N bytes, so this assertion fails. In general, I think the shell has a rule: strings must not contain NUL bytes, except as the terminator.
The simplest way to stop the crashing would probably be to do the same thing the shell does when reading shell input in get() -- just skip over any NUL characters and warn. There could be a smarter thing to do, though. Maybe split on NUL so that $&read returns any lines containing NUL as a multiple-element list? That could compose well with the GNU xargs -0 pattern, but now it feels like we're getting back into the mire of trying to bikeshed fancy behaviors for $&read -- my vote is probably to keep it simple and just skip'n'warn.
(Oh, while I'm here, inputting echo \0 to the shell causes weird behavior: it prints "bad backslash escape" every other time, and can cause the next command to fail:
; echo \0
; ps
bad backslash escape
So that's odd.)
The text was updated successfully, but these errors were encountered:
Actually, maybe the simplest fix for now is to simply throw an error when $&read encounters a NUL. Then a crash could be turned into an exception, which is strictly an improvement, and the exception could still later be turned into a more reasonable handling.
The issue is caused by gcndup() expecting a null-terminated string of length n or greater, yet sealcountedbuffer() invoked by $&read instead provides the number of bytes stored in the Buffer, which is only a problem when the Buffer contains a NUL.
To remedy this, $&read should probably consider NUL as a newline to match the behavior of %backquote \n:
I don't like the magic behavior, but it seems like a better option than overhauling the entire codebase to internally use counted buffers at the moment.
The easiest way to repro is using
trip.es
, which already has a NUL byte in it for testing this kind of thing.The problem here is pretty obvious based on the error message:
strlen(s)
is finding a NUL byte after N bytes, but$&read
has actuallygcalloc
d more than N bytes, so this assertion fails. In general, I think the shell has a rule: strings must not contain NUL bytes, except as the terminator.The simplest way to stop the crashing would probably be to do the same thing the shell does when reading shell input in
get()
-- just skip over any NUL characters and warn. There could be a smarter thing to do, though. Maybe split on NUL so that$&read
returns any lines containing NUL as a multiple-element list? That could compose well with the GNUxargs -0
pattern, but now it feels like we're getting back into the mire of trying to bikeshed fancy behaviors for$&read
-- my vote is probably to keep it simple and just skip'n'warn.(Oh, while I'm here, inputting
echo \0
to the shell causes weird behavior: it prints "bad backslash escape" every other time, and can cause the next command to fail:So that's odd.)
The text was updated successfully, but these errors were encountered: