[bug #55334] preconv fails when build with libuchardet on MS-Windows

[Ingo Schwarze]

Follow-up Comment #5, bug #55334 (project groff):

Whoa, the code in GNU make-4.2.1/output.c is also somewhat broken.  It does
correctly use open(O_CREAT|O_EXCL), but it only tries once (except for EINTR
retries), which is vulnerable to denial of service.  Even worse, lacking
fdopen(3), it falls back to totally insecure behaviour, rather than using
fopen("wx") or erroring out.  I'd call that "prior negligence" rather than
"prior art".  But that's kind of off-topic here, we should not adopt insecure
idioms here merely because others got it wrong.

You may be right that reading a fixed amount of bytes may not be good enough -
you have to keep reading until uchardet can decide, and of course keep the
data read in memory such that you can reuse it for the actual processing.  I
wouldn't worry too much about memory usage.  Text documents - even whole books
- are typically small compared to stuff like videos, so reading lots of text
is unlikely to cause memory exhaustion in this century.  Besides, the cues
needed by uchardet will hardly be Gigabytes away from the beginning of the
file; they will likely be in the first few Kiloybytes, or at worst in the
first few Megabytes.

My plea to not commit was of course intended for other groff developers; there
is always a risk that someone tests it, finds that it work (which it will, in
some cases), and goes ahead to commit, in particular when a patch comes from a
well-known free software developer.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55334>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/