path_windows.go: sanitiseFilename is not robust about sigtop HOT 10 CLOSED

If I understand you correctly, your point is that the replacement character should not occur in sanitised filenames on Windows. Why?

from sigtop.

because the replacement character is its own, valid character. so unless a user intentionally used that in the user name, then it should be replaced in the output

from sigtop.

Again, why? You seem to assume that the output has to be unambiguous. But that's not a goal here.

from sigtop.

because its a worse representation of the original input. if you were just wanting to replace invalid UTF-8 with replacement characters, you could just do this:

runes := []rune(name) 

but you're also replacing characters:

in which case the replacement character should also be replaced, to signify something is invalid in the original input. otherwise you cant disambiguate from an intentional replacement character and one resulting from invalid UTF-8

from sigtop.

otherwise you cant disambiguate

As I've already told you, unambiguity is not a goal. That would require modifying valid filenames, too. I don't want to do that.

from sigtop.

That would require modifying valid filenames, too.

how is that? my suggestion would only impact input that contains invalid UTF-8

from sigtop.

Suppose f is an invalid filename. Let g := sanitiseFilename(f). Valid filenames are not to be modified, so sanitiseFilename(g) == g. Therefore, sanitiseFilename(f) == sanitiseFilename(g), even though f != g.

from sigtop.

I dont see how that answers the question. a filename with invalid UTF-8 is not valid, so would necessarily need replacement.

from sigtop.

I'm very sorry, but I'm going to close this.

from sigtop.

OK well I tried. if you have a justification why invalid UTF-8 is acceptable for a filename, I would be interested to hear it.

from sigtop.