This is the mail archive of the
mailing list for the glibc project.
Re: dup (was: Re: glibc 2.0.94, Linux, chown/lchown and non-i386) , architectures
On Sat, Jul 25, 1998 at 03:49:23PM -0700, Matt McLean wrote:
> i have been having trouble with duping in 2.0.94 (powerpc-linux). the best
> test i can think of is agetty (in util-linux, add -fsigned-char
> -DDEBUGGING). it dies shortly after trying to dup. also (i think) this is
> why dpkg-deb fails on newer kernels, after trying to use a bad file
> pointer. have you (or anybody) had any trouble like this?
On Sat, Jul 25, 1998 at 04:15:59PM -0700, Matt McLean wrote:
> OOPS! looks like getty was an ioctl problem..
Yes indeed - see my letter from a few days ago. I intend to submit a
patch for at least this case, and maybe a generic area for ioctl()
user<->kernel translation, as soon as I get a chance - which is
probably right after a base tarball gets rolled, which is this week if
I can fix the modutils inline assembly problem.
On Sun, Jul 26, 1998 at 07:01:40PM -0700, Joel Klecker wrote:
> Actually, the dpkg-deb problem was traced to fflush() moving the file
> position (It's above my head, so email firstname.lastname@example.org for a more accurate
> description of the problem).
It's wierd - that fflush() has two things wrong with it. First of all,
I have no idea why it is there; it should simply return an error code
because the FILE *ar is opened read-only. Second of all, from perusal
of the libc source code, this should cause fflush() to return -EINVAL
and do nothing. But instead, it advances the file pointer! Anyone who
wants to see this demonstrated can get a test program from
<http://mindcryme.com/~drow/test.c>. The problem oddly does not exist
when opening a file on an ISO FS, and does not exist if running a
kernel before 2.1.<mumble after 24 but before 42>.
Any ideas on that one? I imagine the fflush() was added to work around
a bug in some oddball OS under the assumption it would have no effect
on systems it was not necessary; that it has different effects based on
kernel version looks like some kind of a bug.