bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fseeko bug


From: Eric Blake
Subject: Re: fseeko bug
Date: Sat, 15 Dec 2007 21:30:44 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Larry Jones on 12/15/2007 3:23 PM:
>> And is there a ChangeLog entry for your patch?
> 
> 2007-12-14  Larry Jones  <address@hidden>
> 
>       * lib/fseeko.c (rpl_fseeko): Don't refuse to compile when no native
>       fseeko and off_t bigger than long but fail if the offset is too big.

I don't see any copyright on file for you; would you be interested in
getting the paperwork started so we can apply your contributions?

> 
> Well, like I said before, BSD/OS, although very popular at one time, is
> now quite thoroughly defunct, so I wouldn't go to too much trouble just
> for it.

Indeed, gnulib's goals tend to focus on reasonable porting targets, rather
than museum systems; we are reluctant to add lots of overhead for systems
so old that the fixes are neither appreciated by many users nor easily
maintained.  Or, put another way, even though mingw has more than its fair
share of flaws, it is more of a viable porting target than BSD/OS based on
its current user base.

>  I don't mind not having working large file support, but I'd
> like to be able to at least build code that uses gnulib fseeko and have
> it work on regular files.

Then maybe the best course of action, for now, is just reverting the
verification I added (since with the verify in place, you can't even
compile, whereas without the verify, you at least get correct behavior on
small files), leave the silent overflow in place, and document in
doc/functions/fseeko.texi that BSD/OS is unable to handle streams larger
than 2GB and that gnulib does not fix it.

Unless anyone else speaks up on the matter (Bruno in particular, since he
did most of the stdio porting in gnulib), I'll proceed along those lines
next week.

> 
> I don't know of any good way to do that since you can't use sizeof in
> the preprocessor and there's no standard limit macro for off_t that I
> know of.  Suggestions?

Use configure-time tests to determine sizeof values that can then be used
as preprocessor constants.  For example, look at how stdint.h.in uses
precomputed information about the sizeof (uintmax_t).

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

iD8DBQFHZKn084KuGfSFAYARAjimAKDVIbCUbYAOyxvZ9rwJPiM8CPykjACgwQQt
10Etnh+OPAfDmqLkyqMObog=
=hhdW
-----END PGP SIGNATURE-----




reply via email to

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