.. hi, i didn't any response .. but saw it nonetheless :P
(Still that old mail address, i even thought i had been
unsubscribed until September or so... Hmm.)
|* We're working on improving things, it's not gonna stay like this. :)
Of course!
Happy hacking!!
And keep on going!
(Anyway i'm really happy that Bitrig reintroduced a compiler chain
into the base system, the initial decision i didn't like. And
i don't know -- maybe another external.txz set?)
(And i don't know what you do with your git(1), my one is
cd git.git-no_reduce &&\
(for i in GETTEXT PYTHON TCLTK; do \
echo NO_$${i}=1;\
done;\
cat Makefile) > Makefile.1st &&\
$(GMAKE) -f Makefile.1st all;\
git clean -fxd; git reset --hard HEAD
|> The real hammer: once i compiled the MUA i maintain and loaded the
|> installation message i got a crash... And debugging this revealed
|> a bug that was introduced on 2007-06-16 -- in a software that is
|> in use on almost all Linux and some commercial Unix distributions,
|> even in the base system!
|>
|> It is sheer unbelievable that this bug never happened to be
|> revealed on whatever operating system the software is used on!
|
| Great to hear that! Which MUA do you maintain? I'm really
| wondering
| what bug it was. Do you happen to have a diff I can have a look
| at?
It was a readonly bound violation when (falsely) counting lines in
a buffer for statistical (display) purposes, as in
- if (stats != NULL && stats[0] != -1)
- for (cp = buf; PTRCMP(cp, <, buf + sz); ++cp)
buf is some input buffer of length "len" not sz, which in turn is
the size of an output buffer generated from the input, and
potentially much larger. I.e., whereas buf usually doesn't exceed
1024 bytes (maximum allowed line in e-mail (except with UTF8
extension)) the output is (yet still) prepared to complete lines
(terribly bad behaviour, :-().
- if (*cp == '\n')
- ++n;
- _addstats(stats, n, sz);
|I don't think we have any extras in that direction compared to OpenBSD.
|It could be due to clang vs gcc, but that's really just guessing.
Well, i am really sorry, but it turns out that i can indeed
reproduce the crash on "OpenBSD o0506-i386 5.6 GENERIC#337 i386".
But nonetheless, the mail was generated by the Bitrig installation
program (in QEMU: the version i use sometimes generates "a"
keypresses when switching windows, and no remote shell during
installation yet..), and the crash does happen! It does not on
Mac OS and ArchLinux, for example. As in
Installing toolchain...
quirks-2.10 signed on 2014-11-29T02:45:50Z
= Dquirks-2.10 (extracting)|
| 0% = Dquirks-2.10 (extracting)|***************************************
| 80%= Dquirks-2.10
(extracting)|************************************************ | 98%=
Dquirks-2.10 (installing)| | 0%
= Dquirks-2.10 (installing)|* |
2% = Dquirks-2.10 (installing)|****************************************
| 82%= Dquirks-2.10
(installing)|*************************************************|100%= D
= D=
Dquirks-2.10: ok
The line in question was finally ~12995 bytes or something along
these lines.
Note however that the Bitrig installation program also caused
another change in the MUA i maintain, because the quoted message
also uses
Content-Type: text/plain; charset=unknown-8bit
which is correct on the one hand
+\*(OP RFC 1428 specifies conditions in which internet mail gateways
+shall "upgrade" the content of a mail message by using a character set
+with the name `unknown-8bit'.
but of course
+Because of the unclassified nature of this character set \*(UA will not
+be capable to convert this character set to any other character set.
+If this variable is set any message part which uses the character set
+`unknown-8bit' is assumed to really be in the character set given in the
+value, otherwise the (final) value of
+.Va charset-8bit
+is used for this purpose.
I nonetheless and still wish you the best!
Ciao,
--steffen
