Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3BE2EED1.117D70AD@phekda.freeserve.co.uk>
Date: Fri, 02 Nov 2001 19:06:57 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Patch to add st_blocks to struct stat
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000713092214 DOT 12595A-100000 AT is> <3BE2B26D DOT CA65166B AT phekda DOT freeserve DOT co DOT uk> <200111021735 DOT fA2HZFJ21434 AT envy DOT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

DJ Delorie wrote:
> Changing the size of struct stat will cause problems with pre-built
> objects, especially third party libraries.

How would we indicate with DJGPP's version that binary compatibility has
been broken? Would this kind of change be in DJGPP 3.x?

> *If* we decide to change the size of struct stat (I recommend
> against), let's add a few dummy fields at the end, so that we can
> "expand" it next time without changing its size.

Unix98 says that struct stat should contain st_blocks. This is the only
member of struct stat that we are currently missing, according to Unix98.
BTW I'm just stating facts. I understand and agree that preserving binary
compatibility is more important than this small gain in functionality,
especially as it's easy to work around not having st_blocks.

If we're not expanding the size of struct stat, I can make another patch
that at least fills in st_blksize correctly. In fact, if you ignore the
bits in the patch that refer to st_blocks (e.g. _get_blkcnt, calls to
_get_blkcnt and the extra field in the header), is the patch OK?

Thanks, bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/