Stefan Beller <sbeller@xxxxxxxxxx> writes: >>> + lf = strchr(line, '\n'); >>> + if (lf) >>> + *lf = '\0'; >> >> packet_read_line() -> packet_read_line_generic() calls packet_read() >> with PACKET_READ_CHOMP_NEWLINE flag bit; do we need this check? > > This check was not about "option with lf at end\n", but rather we want to chop > off "option\nover\nmultiple\nlines" ? Ahh, I did misread the check. > Although as you remarked in another email, this would not pose a problem for > the shell variable, so we could also drop it to allow multi line > options. will do. One thing to note is that I do not think there is a guarantee that packet_buf[] is NUL-terminated, and when len == LAGE_PACKET_MAX, you do not have room to NUL-terminate it yourself. string_list_append(ret, line) that assumes the "string" is NUL terminated may become an issue that you need to solve by appending the result of xmemdupz() into a non-duping string list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html