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:08:46 +0300 From: "Eli Zaretskii (eliz AT gnu DOT org)" Subject: Re: bad pragma in dir.h? (and our structrure packing) In-reply-to: X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: <83bnhojnwh.fsf@gnu.org> References: <83k2wcjt8e DOT fsf AT gnu DOT org> 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 21:55:53 +0300 > From: "Ozkan Sezer (sezeroz AT gmail DOT com)" > > On 5/13/15, Eli Zaretskii (eliz AT gnu DOT org) wrote: > >> Date: Wed, 13 May 2015 18:29:39 +0300 > >> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" > >> > >> In dir.h, structs ffblk and ffblklfn are surrounded by #pragma pack(1) > >> and #pragma pack(4), obviously with purpose of having those two structs > >> at byte packing. But the restoration of the original packing by that > >> #pragma pack(4) seems wrong: do we not need a #pragma pack() in there, > >> or am I missing something? > > > > 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. > > See the DJGPP FAQ (node "Struct size"): it tells that the GNU C++ > > compiler doesn't allow having that attribute on the entire struct. > > Perhaps that's changed nowadays, I don't know. (Btw, which compiler > > versions should be supported by djdev205? That is, which versions of > > GCC are supported to compile the library?) > > > > If you are mentioning http://www.delorie.com/djgpp/v2faq/faq22_12.html No, that's a different node (compare their names). I meant http://www.delorie.com/djgpp/v2faq/faq22_11.html. It says: struct my_struct { char name[7]; unsigned long offset; double quality; } __attribute__ ((packed)); 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. > You looked at the headers I mentioned, yes? Yes, why do you ask?