This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [patch] lockf() fix
- To: Ben Collins <bcollins at debian dot org>
- Subject: Re: [patch] lockf() fix
- From: Andreas Jaeger <aj at suse dot de>
- Date: 29 Oct 2000 09:24:14 +0100
- Cc: libc-alpha at sources dot redhat dot com
- References: <20001027185118.L10561@visi.net>
>>>>> Ben Collins writes:
> This seems to only affect sparc, sparc64 and alpha, since they are the
> only ones that define F_RDLCK to something other than 0 (1, in each case).
> Thanks to Anton Blanchard for helping me track this down.
> --- ./sysdeps/generic/lockf.c~ Fri Oct 27 18:43:40 2000
> +++ ./sysdeps/generic/lockf.c Fri Oct 27 18:34:25 2000
> @@ -32,6 +32,7 @@
> memset ((char *) &fl, '\0', sizeof (fl));
>
> /* lockf is always relative to the current file position. */
> + fl.l_type = F_RDLCK;
> fl.l_whence = SEEK_CUR;
> fl.l_start = 0;
> fl.l_len = len;
I don't understand why this is needed at all. Looking at the code
each of the switch cases sets l_type explicitly. Is l_type needed for
the fcntl (fd, F_GETLK) ?
If your patch would be right, the same patch would be needed for
lockf64.
Please explain a bit more why this is needed - or send a simple test
program that fails on those architectures.
Thanks,
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj