Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3BF976C8.9048342@phekda.freeserve.co.uk>
Date: Mon, 19 Nov 2001 21:16:56 +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: RESEND: Patch to computer st_blksize in struct stat
References: <200111182235 DOT XAA21129 AT father DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Martin Str|mberg wrote:
> 
> > Index: include/sys/stat.h
> > ===================================================================
> > RCS file: /cvs/djgpp/djgpp/include/sys/stat.h,v
> > retrieving revision 1.4
> > diff -p -u -3 -r1.4 stat.h
> > --- include/sys/stat.h  2000/12/05 14:05:53     1.4
> > +++ include/sys/stat.h  2001/11/18 21:46:42
> > @@ -49,9 +49,9 @@ struct stat {
> >    time_t       st_mtime;
> >    nlink_t      st_nlink;
> >    off_t                st_size;
> > -  off_t                st_blksize;
> > +  blksize_t    st_blksize;
> >    uid_t                st_uid;
> > -  dev_t                st_rdev; /* unused */
> > +  dev_t                st_rdev;
> >  };
> 
> If we are making incompitable changes to struct stat, perhaps we
> should change "off_t st_size;" to "offset_t st_size;" or change
> "typedef int off_t;" to "typedef long long off_t;" (and remove
> offset_t)?
> 
> Or perhaps we should try to keep binary compatibily for 2.04 and wait
> with incompatible change for the next release after that?

Actually the change is binary compatible, since blksize_t is defined to be
an int just like off_t. The struct should occupy as much space as it did
before. See sys/djtypes.h and the part of the patch that defines blksize_t
and blkcnt_t in sys/types.h.

Unix98 specifies that st_blksize should be a blksize_t not an off_t. Does
anyone object to this change? Will it break source compatibility? My gut
feeling is that it won't. It certainly didn't break Fileutils 4.0, when I
compiled with an earlier version of the patch.

Thanks, bye, Rich =]

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