Eric Blake writes:
>
> maybe it's at least worth adding a compile-time assertion that sizeof(off_t)
> ==sizeof(long) when !HAVE_FSEEKO.
Since I actually have a platform where that's not the case, I'd prefer a
run-time test that only objects when there's an actual problem:
--- fseeko.c.gnulib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Larry Jones on 12/16/2007 11:50 AM:
> Eric Blake writes:
>> 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
Eric Blake writes:
>
> 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 doc
Eric Blake writes:
>
> There are two reasons for fseeko. One is for platforms that lack it. But
> the other is for POSIX compliance for the requirement to position the
> underlying fd offset when seeking on input streams (many BSD-based
> implementations only follow the C99 rules, where such beh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Larry Jones on 12/14/2007 12:25 PM:
> Eric Blake writes:
>> maybe it's at least worth adding a compile-time assertion that sizeof(off_t)
>> ==sizeof(long) when !HAVE_FSEEKO.
>
> Since I actually have a platform where that's not the case,
Eric Blake writes:
>
> According to Larry Jones on 12/14/2007 12:25 PM:
> > Eric Blake writes:
> >> maybe it's at least worth adding a compile-time assertion that
> >> sizeof(off_t)
> >> ==sizeof(long) when !HAVE_FSEEKO.
> >
> > Since I actually have a platform where that's not the case, I'd pre
-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 <[EMAIL PROTECTED]>
>
> * lib/fseeko.c (rpl_fseeko): Don't refuse to compile when no native
> fseeko and off_t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Larry Jones on 12/14/2007 9:41 AM:
> Eric Blake writes:
>> Larry Jones siemens.com> writes:
>>> On a more general note, it looks like fseeko and ftello both need more
>>> work to be generally useful on platforms that have a wide off_t but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Larry Jones on 12/14/2007 12:25 PM:
> Eric Blake writes:
>> maybe it's at least worth adding a compile-time assertion that sizeof(off_t)
>> ==sizeof(long) when !HAVE_FSEEKO.
>
> Since I actually have a platform where that's not the case,
Eric Blake writes:
>
> Larry Jones siemens.com> writes:
> >
> > On a more general note, it looks like fseeko and ftello both need more
> > work to be generally useful on platforms that have a wide off_t but
> > don't have native fseeko/ftello.
>
> Name such a platform, then we'll worry about it
On 12/13/2007 9:40 PM, Eric Blake wrote:
off_t == long is not a problem. Only off_t > long.
Great.
- --
Don't work too hard, make some time for fun as well!
Every time I see your SIG, I feel like it's an accurate assessment of my
time management skills, so I resolve to work half as hard as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jay Levitt on 12/13/2007 5:05 PM:
>
> Stratus! We have off_t (= long) but no fseeko. But I'm the only user
> there and I haven't actually been using it yet, so that's not very
> convincing. It's more of a part-time/hobby port than anyt
On 12/13/2007 5:06 PM, Eric Blake wrote:
Larry Jones siemens.com> writes:
Looks good. You might want to consider adding tests to make sure that
any pending ungetc() data is cleared like it's supposed to be. I don't
see any code that obviously does that, so I suspect it's not.
Does this loo
Larry Jones siemens.com> writes:
> Looks good. You might want to consider adding tests to make sure that
> any pending ungetc() data is cleared like it's supposed to be. I don't
> see any code that obviously does that, so I suspect it's not.
Does this look correct? I'm checking it in.
>
> O
Eric Blake writes:
>
> Just to make sure other platforms aren't affected, I'm installing this.
Looks good. You might want to consider adding tests to make sure that
any pending ungetc() data is cleared like it's supposed to be. I don't
see any code that obviously does that, so I suspect it's no
Eric Blake byu.net> writes:
>
> Larry Jones siemens.com> writes:
>
> >
> > CVS nightly testing has been failing on BSD/OS and I've finally tracked
> > the problem down to a bug in fseeko -- it doesn't clear the EOF flag
> > after doing its magic:
>
> Just to make sure other platforms aren't
Larry Jones siemens.com> writes:
>
> CVS nightly testing has been failing on BSD/OS and I've finally tracked
> the problem down to a bug in fseeko -- it doesn't clear the EOF flag
> after doing its magic:
Just to make sure other platforms aren't affected, I'm installing this.
From: Eric Blake
Larry Jones siemens.com> writes:
>
> CVS nightly testing has been failing on BSD/OS and I've finally tracked
> the problem down to a bug in fseeko -- it doesn't clear the EOF flag
> after doing its magic:
Thanks. Since the gnulib tests-fseeko doesn't test that, we should probably
beef it up a
CVS nightly testing has been failing on BSD/OS and I've finally tracked
the problem down to a bug in fseeko -- it doesn't clear the EOF flag
after doing its magic:
Index: fseeko.c
===
RCS file: /cvsroot/cvs/ccvs/lib/fseeko.c,v
retriev
19 matches
Mail list logo
