[fpc-devel]A few fixes for Libc unit

[Michalis Kamburelis]

Here are a few fixes for Libc unit:

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