lkml.org 
[lkml]   [1998]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
   From: Ulrich Drepper <drepper@cygnus.com>
Date: 12 Jun 1998 12:54:30 -0700

Did you read the test at all? I wrote test for lseek64 and if it is
not avaialble test for a usable llseek. This test is given and will
fail for glibc-2.0.x and so the mechanisms you already have in the
code will use the system call directly.

That will work in theory, but your test hard coded glibc version
numbers, which is a really bad idea. What if in the future some future
version of glibc drops lseek64, and so we fall back to the usable_llseek
test, but the __GLIBC_MINOR__ version is no longer zero? Then we'll be
screwed once again. Perhaps you can argue that you or future glibc
maintainers won't do this because you it would screw applications; but
if that was the case, why didn't you keep the llseek prototype?

In any case, having got burned this way, I'm going to keep the prototype
test around; it's the only way I can be sure that users won't get
screwed this way in the future. In fact, when I get around to adding
support for lseek64, I'll probably put a prototype on lseek64 for the
same reason, in case future glibc maintainers decide to move the
prototype to some other header file just because some standard body
decided to make the change, and they decide that standards were more
important than compatibility.

- Ted

P.S. No, I'm not going to put use lseek64 in e2fsprogs for 1.12, mainly
because I'm not using glibc 2.1 yet, and I don't want to code for
something that I can't personally test.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.087 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site