[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Solaris fpurge bug
From: |
Eric Blake |
Subject: |
Solaris fpurge bug |
Date: |
Mon, 26 Apr 2010 16:41:52 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4 |
Aargh. I'm further in getting my open_memstream implementation going
(I've now verified that my temporary-file backup works on Cygwin 1.5.x,
as well as on Linux with configure primed with
ac_cv_func_open_memstream=no; while mingw encountered some C++ issues;
separate messages to come soon). But in the process of testing it, I
discovered that Solaris 10 __fpurge() is broken - the sequence
fpurge()/fputc()/ftell() gives the wrong answer. It looks like none of
our existing tests directly cover this situation, since the gnulib unit
tests for fpurge passed when run in isolation (Solaris did not need a
replacement for fclose in that situation). But once my new
open_memstream forced unconditional overrides for fflush and fclose,
then test-fpurge is now calling rpl_fclose which calls ftell() in
exactly that scenario. As proof that the bug exists independently of
gnulib:
$ cat foo.c
#include <stdio.h>
#include <stdio_ext.h>
int main() {
FILE *fp = fopen ("file", "r+");
fseek (fp, -1, SEEK_END);
if (getc (fp) != 'h') return 1;
if (getc (fp) != EOF) return 2;
__fpurge (fp);
if (putc ('!', fp) != '!') return 3;
printf ("%d\n", (int) ftell (fp));
if (fclose (fp) != 0) return 4;
return 0;
}
$ printf foogarsh > file
$ ./foo
-8183
I guess we need to beef up the unit tests to expose the Solaris bug,
then work on replacing broken __fpurge with a version that works
correctly on read-write streams.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Solaris fpurge bug,
Eric Blake <=