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.
>
> http://www.cs.ucla.edu/classes/spring04/cs131/hw/uniq.py

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
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
pythonrun.c:

static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
r>
fflush(stdout);
fflush(stderr);
}

I've just reported the bug via Debian's reportbug -- though it's not
Debian specific.

Here's a tiny script to illustrate:

$ cat <<\EOF > close-bug
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)

if __name__ == '__main__':
main ()
EOF

$ python close-bug
foo
$ python close-bug > /dev/full && echo unreported write failure
unreported write failure







Privacy