X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Date: Wed, 13 May 2015 22:21:18 +0300
From: "Eli Zaretskii (eliz AT gnu DOT org)" <djgpp AT delorie DOT com>
Subject: Re: bad pragma in dir.h? (and our structrure packing)
In-reply-to: <CAA2C=vAEKFUktuYXGN_eYUEY0JuHQgXR_-q-N8xox=7PHPEqqw@mail.gmail.com>
X-012-Sender: halo1 AT inter DOT net DOT il
To: djgpp AT delorie DOT com
Message-id: <838ucsjnbl.fsf@gnu.org>
References: <CAA2C=vCgLHdH3BJxastGzUsJzhiRddytiYwB1MP_aaiiVpC4nA AT mail DOT gmail DOT com> <83k2wcjt8e DOT fsf AT gnu DOT org> <CAA2C=vB-YiGkyx5dJpa=hcBh0O4_NiEKh2tKm5OHyNX3vW7HsQ AT mail DOT gmail DOT com> <83bnhojnwh DOT fsf AT gnu DOT org> <CAA2C=vAEKFUktuYXGN_eYUEY0JuHQgXR_-q-N8xox=7PHPEqqw AT mail DOT gmail DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Wed, 13 May 2015 22:14:58 +0300
> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie DOT com>
> 
> >> > Wasn't that already fixed in the past?
> >>
> >> Well, obviously not. that pragma pack(4) is there in the cvs
> >
> > People make mistakes when they commit, so it could well be that the
> > problem was fixed at some point and then broken again in a subsequent
> > commit.
> >
> 
> Alright then.  OK to commit the following?
> 
> Index: dir.h
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/include/dir.h,v
> retrieving revision 1.6
> diff -U 5 -r1.6 dir.h
> --- dir.h	2 May 2015 07:31:44 -0000	1.6
> +++ dir.h	13 May 2015 19:12:02 -0000
> @@ -52,11 +52,11 @@
>    unsigned long long fd_reserved __attribute__((packed));
>    char               fd_longname[260] __attribute__((packed));
>    char               fd_name[14] __attribute__((packed));
>  };
> 
> -#pragma pack(4)
> +#pragma pack()

"pack()" or "pack(0)"?

> >   However, note that the latter will only work when you compile it as a C
> >   source; C++ doesn't allow such syntax, and you will have to fall back to
> >   declaring each struct member with the packed attribute.  Therefore, it's
> > best
> >   to only use declarations such as above if you are *certain* it won't be
> > ever
> >   compiled as a C++ source.
> >
> > Once again, a lot has changed in C++ since then, so if all the
> > versions of GCC we want to support allow the above, there's no reason
> > to keep the attribute on each member of those structs.
> 
> IIRC, never had such a problem with C++, although I haven't used
> g++ older than v3.0

If you (or someone else) can verify that the size of the structure and
the offsets of each member are the same in both C and C++ programs,
then I see no reason to keep the attribute on every member.

Thanks.