[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: workaround ftello/fseeko on cygwin 1.5.x
From: |
Eric Blake |
Subject: |
Re: workaround ftello/fseeko on cygwin 1.5.x |
Date: |
Wed, 23 May 2007 18:04:35 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Bruno Haible on 5/23/2007 4:36 PM:
> Eric Blake wrote:
>> It overcomes the
>> fact that cygwin was creating the three std streams in 32-bit mode instead
>> of 64-bit mode, such that fseeko/ftello failed because they expected the
>> stream to be in 64-bit mode.
>
> Glad to see that you found a workaround!
>
>
> Every time fseeko or ftello is applied for the first time to a stream, this
> code will fopen /dev/null. Sounds a bit expensive. Can't you cache the
> _seek64 pointer that you found?
In my patch, /dev/null would only be opened at most three times in a
process - stdin, stdout, and stderr are the only three streams that cygwin
1.5.x can ever observe in 32-bit mode, and after the first use of
ftello/fseeko, they are thereafter in 64-bit mode. Besides, I have a
pending patch to cygwin awaiting approval that changes the signature of
FILE._seek64, so it will take some gross casts to to stash it in cygwin
1.5.x in such a way that the file still compiles with the new signature in
cygwin 1.7.0. Is it still worth caching?
> Something like this:
>
> /* Ensures that the given stream is open in 64-bit mode. */
> void
> cygfreopen64 (FILE *fp)
> {
...
> Put this into a separate compilation unit, so that fseeko and ftello can
> share the same cache.
However, the idea of cygfreopen64 has merits on its own, since I plan on
adding documentation in doc/functions/stdin.texi (and whatever happened to
stdout and stderr.texi?), so maybe making cygfreopen64 a separate module
would have other uses.
>
>> @@ -233,6 +235,11 @@ typedef int verify_fseeko_types[2 * (siz
>> (GL_LINK_WARNING ("fseeko is unportable - " \
>> "use gnulib module fseeko for portability"), \
>> fseeko (f, o, w))
>> +# undef fseek
>> +# define fseek(f,o,w) \
>> + (GL_LINK_WARNING ("fseek is artificially limited - " \
>> + "use gnulib module fseeko for portability"), \
>> + fseek (f, o, w))
>> #endif
>
> You don't need this: The warning about fseek is already contained in
> stdio_.h lines 238..246, and the one for tell is already at stdio_.h lines
> 262..270.
Yep, I noticed that after I posted; my tree was a bit dirty from abandoned
patches that I had not completely cleaned up.
>> +++ m4/fseeko.m4 23 May 2007 16:44:57 -0000
>> + AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
And that line is bogus, since I ended up with a link test instead of a run
test.
>
> This test is duplicated between fseeko.m4 and ftello.m4. Since you use
> two different cache variables, it will even be executed twice per 'configure'
> run. I would put it into a separate macro, say, in stdio_h.m4.
Good idea. I'll refactor accordingly, and change the message to something
along the lines of 'checking whether stdin is opened in 64-bit mode'.
Revised patch will come tomorrow (I forgot to bring my current draft of
the patch home to continue hacking on it tonight).
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGVNaT84KuGfSFAYARAmeYAJ9kiaYnCYYSLnLb1LmXRjeMfJXbtQCggSsl
WPsZ2q4nBhBLz2gxrZjoPHo=
=QaLS
-----END PGP SIGNATURE-----