bug-gnulib
[Top][All Lists]
Advanced

[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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]