[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `message' not outputting the newline "atomically"
From: |
Lars Ingebrigtsen |
Subject: |
Re: `message' not outputting the newline "atomically" |
Date: |
Mon, 24 Jun 2019 23:33:06 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Paul Eggert <address@hidden> writes:
> * The patch also needs a FIXME comment saying it fixes only "message"
> output, not the other uses of stderr in Emacs.
Well... that's kinda unusual. The commit message may say so, but
having that in the code would be odd.
> * The patched code has undefined behavior if the string length is
> INT_MAX, and messes up in other ways if the string length exceeds
> INT_MAX. This bug is unlikely but should be fixed.
Yup.
> * The second and third arguments to fwrite should be
> interchanged. This makes a difference on some non-POSIX platforms, and
> we might as well do it right here.
I agree, but I just wanted to keep the code as similar as the previous
one as possible.
> * More important, the patched code shouldn't call xmalloc. Having to
> allocate a buffer as part of an error diagnostic is a recipe for
> trouble. (Suppose the diagnostic is related to being low on memory?)
> Instead, the patched code should just use a fixed-size buffer that is
> guaranteed to exist and be big enough. This is a basic design
> principle for error diagnostics (I vaguely recall Dijkstra did this
> back in the 1960s).
It is, but the code also calls code_convert_string, so I thought one
more xmalloc didn't make much difference.
> * The buffer should contain only PIPE_BUF bytes, since writes larger
> than that can be split by the operating system anyway so any excess
> size is wasted. On POSIX platforms you can use fpathconf to calculate
> PIPE_BUF for stderr. I don't know how to calculate it on MS-Windows
> platforms, but maybe it doesn't matter and you can just pretend it's
> 1024 or whatever.
I don't think it's important -- if the buffer is larger than PIPE_BUF,
we still might get multiprocess output interleaved, but I don't think we
care that much. On modern OS-es it's 4096, and we seldom output things
that are bigger than that via `message', to put it mildly.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/24
- Re: `message' not outputting the newline "atomically", Daniele Nicolodi, 2019/06/24
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/24
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/24
- Re: `message' not outputting the newline "atomically",
Lars Ingebrigtsen <=
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/24
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/24
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/24
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/24
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/25
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/27
Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/26
Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26