X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=IHQXZgvJWYatGeZb45kizJ2MTvjfrJ8UURTgN7bJ1H4=;
        b=jXhlSU9lPA9OgffmSGGuDzZTPWL3xgvyFXxOjUS9qujEWxXRnjC8gl7mp4E3zQ6yp+
         VDHU4eNeIx3h7W/WYHQkUxzhyE9yLUhAGTjb3IJ/OIyrU2vXjMQbRtUqXQyC3We/EO6n
         onCiVNRgRu5U0p6UbrtAy8getqMKgDlTHuQL6ykBsmNWZ6UjGdSxuc7Tw/19pw63xXoz
         Qe2DTxa6ayTrNkSIP/o1NzqV0ZMwQv+YXs6yccgXKKd4B31nNwu5PBrwlUz/W7gTfG8L
         R8Qf+i3DJGcdlJvlRxAdOPr9AcLbYaeLqeLoRcztgbsGaVJbUB1IfGJ97HNaOBsgcyL7
         5S7Q==
MIME-Version: 1.0
X-Received: by 10.107.138.130 with SMTP id c2mr551832ioj.74.1431544498313;
 Wed, 13 May 2015 12:14:58 -0700 (PDT)
In-Reply-To: <83bnhojnwh.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>
Date: Wed, 13 May 2015 22:14:58 +0300
Message-ID: <CAA2C=vAEKFUktuYXGN_eYUEY0JuHQgXR_-q-N8xox=7PHPEqqw@mail.gmail.com>
Subject: Re: bad pragma in dir.h? (and our structrure packing)
From: "Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
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

On 5/13/15, Eli Zaretskii (eliz AT gnu DOT org) <djgpp AT delorie DOT com> wrote:
>> Date: Wed, 13 May 2015 21:55:53 +0300
>> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie DOT com>
>>
>> On 5/13/15, Eli Zaretskii (eliz AT gnu DOT org) <djgpp AT delorie DOT com> wrote:
>> >> Date: Wed, 13 May 2015 18:29:39 +0300
>> >> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie 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.
>

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()

 #define FA_RDONLY       1
 #define FA_HIDDEN       2
 #define FA_SYSTEM       4
 #define FA_LABEL        8


>> > 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.

IIRC, never had such a problem with C++, although I haven't used
g++ older than v3.0