Comment 1:

xml.Escape also has this problem.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 2:

This isn't easy. NUL bytes are forbidden, as are surrogates and some other code points.
It's easy to detect them; the problem is what to do?  Escape, for instance, has no error
return. The only solution I can see is to panic, which is heavy-handed.

Comment 3:

yeah, that's why i didn't fix it.
Marshal can return error, but the Escape case is difficult.
If we fix Escape by allowing it to panic, does it break the Go 1 compatibility promise?

Comment 4:

I agree, it's heavy handed. However keep in mind this is actually a pretty serious bug,
as many heavy-hitting XML framework/super-libraries are pedantic about checking that
characters are valid. So the result of Marshal and Escape will cause errors in some
other process down the line. The case I have is in a SAX parser in some Java process I
don't control which abrubtly explodes when reading an attribute with a '\0' in it.
At least Marshal could return an error, and a CheckedEscape or something to that effect
could be used that allows returning an error.
Another idea is to add a function that will check a string for valid codepoints, which
could be used either before or after Escape, or whenever user code feels like it.

Comment 5:

1. Internally we will need the routine to know whether it is being called from something
that can return errors.
2. Bad characters result in an error if we're returning errors; otherwise they turn into
U+FFFD (best we can do).
3. Add EscapeText, a version of Escape that returns an error (issue #4112).

Comment 6:

Labels changed: added size-m.

Comment 7:

Labels changed: added suggested.

Comment 8 by osaingre:

Hi, I'm working on this.

Comment 9:

This issue was closed by revision f74eb6d.

Status changed to Fixed.