1. In stimeh.inc __timezone_ptr_t = timezone; should be changed to __timezone_ptr_t = ptimezone;
2. In pwdh.inc function getpwuid_r(..., var __resultbuf:Ppasswd; ... should be changed to function getpwuid_r(..., var __resultbuf:passwd; ...
3. In bstath.inc field __st_ino should be removed from record _stat (there already is field st_ino !)
4. Still in bstath.inc and still in the record _stat:
After __pad1 and __pad2 one should add additional 2-byte pads, i.e. record _stat should look like:
_stat = packed record
st_dev : __dev_t;
__pad1 : word;
__undocumented_pad : word; { <- ADDITIONAL PAD }
st_ino : __ino_t;
{ __st_ino : __ino_t; } { <- field removed }
st_mode : __mode_t;
st_nlink : __nlink_t;
st_uid : __uid_t;
st_gid : __gid_t;
st_rdev : __dev_t;
__pad2 : word;
__undocumented_pad_2 : word; { <- ADDITIONAL PAD }
st_size : __off_t;
st_blksize : __blksize_t;
st_blocks : __blkcnt_t;
st_atime : __time_t;
__unused1 : dword;
st_mtime : __time_t;
__unused2 : dword;
st_ctime : __time_t;
__unused3 : dword;
__unused4 : dword;
__unused5 : dword;
end;I call those fields "undocumented pads" because (on my Linux system) in C header bit/stat.h they are not listed. I have there
unsigned short int __pad1
and that's all. So this part of bit/stat.h is rather strangely written -- actually the pad takes 4 bytes (additional 2 bytes are added implicitly by gcc), not 2 !
I did not tested this but probably under FPC 1.9.3 instead of adding those "undocumented pads" one can also remove "packed" keyword from the type declaration to get the same effect. But I do not advice this as this would (probably) not work as expected with FPC 1.0.10.
5. At the end, something that probably doesn't ever cause any problems in practice (so _probably_ it may be ignored):
In sstath.inc and sstat.inc seven macros
S_ISDIR
S_ISCHR
S_ISBLK
S_ISREG
S_ISFIFO
S_ISLNK
S_ISSOCK
should take parameter mode:__mode_t, not mode:longint. __mode_t (or just mode_t) is an unsigned type and longint is signed, so this could produce false range check errors in user code (e.g. when taking value from _stat.st_mode and testing it with S_ISDIR). But I'm not sure whether it is possible, i.e. whether __mode_t can ever have so big value (with oldest bit set) that it will matter.
For consistency, __S_ISTYPE may be also changed to take __mode_t (or mode_t) instead of longint, but user should not use __S_ISTYPE anyway (so no range checks will be generated as long as Libc module will be compiled without range checking).
Regards, -- Michalis
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
