Re: search.c clean-up
Paul Eggert <eggert@xxxxxxxxxxx> wrote:
> Aharon Robbins <arnold@xxxxxxxxxx> writes:
>> C++ is widespread enough that it might not be unreasonable to move towards
>> it, esp. for some of the smaller GNU apps.
> For low-level stuff C is fine. Otherwise, I'd far rather use Java, or
> Python, or half-a-dozen other languages. They have all benefited from
> hindsight that evolved from C++'s mistakes.
> Any major move to depart from C should be by consensus (e.g., the GNU
> Coding Standards should get revised).
> Just for fun, here's a complete implementation of POSIX uniq written
> in Python.
I remember that. I think your writing that script helped you find
a bug or two in the GNU version.
Unfortunately, python doesn't always detect write errors
(through no fault of your script):
$ echo foo |python uniq.py > /dev/full && echo whoops
It looks like stdout is flushed, but the failure is ignored.
$ strace -e write ./uniq.py a > /dev/full
write(1, "foo\n", 4) = -1 ENOSPC (No space left on device)
Adding an explicit flush does make it give a diagnostic.
This is with python-2.3.4-16.
I took a look at the python sources and found that there's a pretty
systemic problem. There are many unchecked calls to fflush, fclose,
and close, and only a handful to ferror.
This particular failure comes from the following unchecked fflush in
while (nexitfuncs > 0)
I've just reported the bug via Debian's reportbug -- though it's not
Here's a tiny script to illustrate:
$ cat <<\EOF > close-bug
def main ():
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
if __name__ == '__main__':
$ python close-bug
$ python close-bug > /dev/full && echo unreported write failure
unreported write failure