X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Message-ID: <5553A43B.5070802@iki.fi>
Date: Wed, 13 May 2015 22:21:31 +0300
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: bad pragma in dir.h? (and our structrure packing)
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>
In-Reply-To: <CAA2C=vAEKFUktuYXGN_eYUEY0JuHQgXR_-q-N8xox=7PHPEqqw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

On 05/13/2015 10:14 PM, Ozkan Sezer (sezeroz AT gmail DOT com) wrote:
> 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
>
>
>
I guess it would be a good idea to have small test in build process to verify that offsets of 
members are correct for structures intended for DOS calls. So build would fail if something is 
wrong with member packing

Andris