Re: `message' not outputting the newline "atomically"

[Lars Ingebrigtsen]

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