From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:33903)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SS7bc-0005fu-NL
	for qemu-devel@nongnu.org; Wed, 09 May 2012 10:11:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SS7bS-0000hI-RJ
	for qemu-devel@nongnu.org; Wed, 09 May 2012 10:11:04 -0400
Received: from mx1.redhat.com ([209.132.183.28]:57870)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SS7bS-0000h1-J2
	for qemu-devel@nongnu.org; Wed, 09 May 2012 10:10:54 -0400
Message-ID: <4FAA7AD2.3060308@redhat.com>
Date: Wed, 09 May 2012 16:10:26 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1336488722-13120-1-git-send-email-pbonzini@redhat.com>
	<1336488722-13120-20-git-send-email-pbonzini@redhat.com>
	<4FAA73D7.3030203@redhat.com> <4FAA799B.9090606@redhat.com>
In-Reply-To: <4FAA799B.9090606@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1.1 19/22] block: implement is_allocated
 for raw
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com

Am 09.05.2012 16:05, schrieb Paolo Bonzini:
> Il 09/05/2012 15:40, Kevin Wolf ha scritto:
>>>> +#ifndef SEEK_DATA
>>>> +#define SEEK_DATA 3
>>>> +#endif
>>>> +#ifndef SEEK_HOLE
>>>> +#define SEEK_HOLE 4
>>>> +#endif
>> How is that going to be portable? You assume that on non-Linux you'll
>> get -EINVAL, but what does guarantee that 3 or 4 aren't already used for
>> the standard SEEK_* constants or for a different non-standard extension?
> 
> While SEEK_* is not guaranteed by POSIX to be 0/1/2, the values is so
> old that there may still exist programs that hard-code the values
> (similar to O_RDONLY/O_WRONLY/O_RDWR, though probably not any other O_*
> constant).  It would be quite unwise to define them to something else.
> Even MS-DOS reused the values!
> 
> AFAIK this is the only extension of lseek that's ever been added.  It
> was done on Solaris first and then in Linux and the BSDs.  It used 3/4
> there too, see for example http://bugs.python.org/msg119551 (Solaris)
> and http://mail-index.netbsd.org/tech-kern/2011/08/17/msg011231.html
> (NetBSD).

Why not simply #ifdef the whole code out and fall back to the current
"everything is allocated" behaviour when SEEK_DATA/HOLE aren't defined?

Kevin