Date: Mon, 13 Nov 2006 22:19:29 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Farfeleder <stefanf@FreeBSD.org> Cc: Joseph Koshy <jkoshy@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/include ar.h Message-ID: <20061113220031.V76443@delplex.bde.org> In-Reply-To: <20061113094311.GC97460@wombat.fafoe.narf.at> References: <200611130428.kAD4ST0U093715@repoman.freebsd.org> <20061113173927.Q75708@delplex.bde.org> <20061113094311.GC97460@wombat.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Nov 2006, Stefan Farfeleder wrote:
> On Mon, Nov 13, 2006 at 07:30:11PM +1100, Bruce Evans wrote:
>> On Mon, 13 Nov 2006, Joseph Koshy wrote:
>>
>>> jkoshy 2006-11-13 04:28:29 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>> include ar.h
>>> Log:
>>> Attempt to improve application portability by marking `struct ar_hdr'
>>> as `packed'.
>>> ...
>> I don't see how this can be more portable. It uses an unportable
>> extension, but packing is automatic on all compilers that are known
>> to support this extension. On compilers that are not known to support
>> ...
>> In <ar.h>, all struct members are char arrays so there will be no
>> padding in practice.
>
> You seem to have missed the discussion on -current. GCC pads "struct foo
> { char c; };" to 4 bytes on ARM. I agree on __packed not being
> portable.
I don't read -current. Peharps I shouldn't comment on it.
I think it is a bug for ARM to do that. If __packed actually gives a size
of 1, then the padding must be only an optimization for time.
struct ar's natural size is 60, so __packed is unnecessary for ARM too
(unless there is internal padding which would cause more problems).
Apparently, struct ar was manually packed to a multiple of the word
size back when the largest word size was 32 bits. It has already been
changed at least once without leaving enough space for expansion. In
V7 it was "char ar_name[14]; long ar_date; char ar_uid; ..." so it had
bad packing starting at its second member and really bad packing
starting at its third member.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061113220031.V76443>