Hallo Jörg.
Joerg Schilling wrote in
<20201211114507.zccfs%sch...@schily.net>:
|"Steffen Nurpmeso via austin-group-l at The Open Group" <austin-group-l@\
|opengroup.org> wrote:
|> Joerg Schilling wrote in
|> <20201210004945.i3n8e%sch...@schily.net>:
|>|Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
|>|> this is an iconv(3)-related error that was fixed in later version
|>|> of the mailer you use. The very error came up on the ML this
..
|>|You are correct,
|>
|> Yep -- unfortunately.
|
|I meanwhile discovered (from a hint in another mail in this thread \
|that I canot
|answer) that the trigger may be an embedded nul character.
|
|The s-nail error message was:
|
| "Failed to prepare composed message"
So you could not fully read it .. and tried to respond to the
"half-seen" message nonetheless?
Regardless, it is fixed in the version that will become obsolete
tomorrow.
|and the mail display (before I tried to answer) stopped before the \
|line that
|contained that nul character. Again saving the mail to a file and using \
|iconv(1)
|did result in "useful" converted output.
|
|There seem to be two things that need to be handled in a way that never \
|causes
|a mail (regardless of the content) to prevent reading or answering.
|
|- EILSEQ should not result in shortened mails or errors that abort
| work completely for that mail.
|
|- Characters that cause EILSEQ should be transformed into "something"
| in the output that at least is a hint for that problem.
Ah, it is not that alone, people are playing games and inject
invalid bytes in base64 streams and such. We handle these cases
well for a remarkable long time, when viewed in context.
It is a pity that the software is not yet at a point where we can
simply log such occurrances though, even though we can join
successive error messages in the style known from syslog. (At the
beginning we did, but it could have caused hundreds of log
messages.)
|I am not sure whether that helps, but I remember from my experiences from
|mkisofs that iconv() from glibc has a bug and ignores *outbytesleft. This
|frequently results in reading or writing too much data.
In the software i maintain i found references to problems
regarding character sets and iconv(3). I have seen _very_ strange
names like (that is phantasie) western-subset-european-10646 or
something like that (that was on UnixWare). How could anyone deal
with that portably?
Decades ago i was hm foolishly prowd of my
way of generating character set names, because we normalized them
splitting at boundaries which included numbers (so utf-8 and utf8
would end up as one entry "utf 8" to test). One decade ago the
Python people did not like it (and also separate(d) with
hyphen-minus not whitespace which i found strange.
Today (what a ridiculous regress!) i have to write code like
static char const * const names[] = {"csASCII", "cp367", "IBM367", "us",
"ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986", "iso-ir-6",
"ANSI_X3.4-1968", "ASCII", "US-ASCII"};
to find out whether anything is actually defined in US-ASCII,
because no official interfaces exist which give someone a hint.
Ciao,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
