Mail Archives: djgpp/2015/05/13/15:21:39
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
- Raw text -