Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
libisofs/builder.c:209: warning: passing
argument 2 of 'aaip_cleanout_st_mode' from
incompatible pointer type
Is stat.st_mode not of type mode_t ?
The line in question is:
aaip_cleanout_st_mode(a_text, (info.st_mode), 4 | 16);
Argument number two is a component of
struct stat info;
The function prototype is
int aaip_cleanout_st_mode(char *acl_text, mode_t *st_mode, int flag);
Can somebody please have a look into
sys/stat.h
whether
struct stat.st_mode
is of different size than mode_t ?
The warning appears on amd64 and on i386.
Unfortunately yes:
/* Structure describing file characteristics. */
struct stat
{
__dev_t st_dev; /* Device containing the file. */
__ino_t st_ino; /* File serial number. */
__uint32_t st_mode; /* File mode. */
__uint32_t st_nlink;/* Link count. */
__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group. */
__dev_t st_rdev;/* Device number, if device. */
struct timespec st_atim;/* Time of last access. */
struct timespec st_mtim;/* Time of last modification. */
struct timespec st_ctim;/* Time of last status change. */
__off_t st_size;/* Size of file, in bytes. */
__blkcnt_t st_blocks; /* Number of 512-byte blocks allocated. */
__blksize_t st_blksize; /* Optimal block size for I/O. */
__uint32_t st_flags;/* User defined flags. */
__uint32_t st_gen; /* Generation number. */
__quad_t __unused1[2];
};
Similar problem might be with nlink_t (16 bit also). Both are mandated by POSIX
http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
IMO, we should fix our headers, but retain binary compatibility
which on little endian should be doable by
-__uint32_t st_mode;/* File mode. */
-__uint32_t st_nlink; /* Link count. */
+__mode_t st_mode; /* File mode. */
+__mode_t __pad_mode; /* __mode_t is 16 bit, align to 32 bit to
retain previous ABI */
+__nlink_t st_nlink;/* Link count. */
+__nlink_t __pad_nlink; /* __nlink_t is 16 bit, align to 32 bit to
retain previous ABI */
And the stat16_to_stat() should zero __pad_mode and __pad_nlink.
Aurelien, Cyril do you agree with this (eglibc) change ?
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
Petr Salinger petr.salin...@seznam.cz (04/01/2010): Aurelien, Cyril do you agree with this (eglibc) change? I'm really not the person to talk to about those kind of things. But speaking of eglibc, I guess you already know about the build failures we're facing with the latest upload (2.10.2-3)? Mraw, KiBi. signature.asc Description: Digital signature
Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
That looks fine given that the kernel syscall is using 16 bits. For big endian targets, given we have none of them, it should not be a problem, they can use the same definition. Committed in glibc-bsd SVN. I will also add to pkg-glibc SVN, just after testsuite finishes. It's a pitty we have such an ABI, as after this change stat16 and stat looks really similar (unless I have missed a difference), modulo the padding. In some time in the past, glibc-bsd used to use syscalls with struct nstat. But the n comes from NetBSD not new. But we have to carry the ABI ... Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Request for advise with struct stat, ACL, xattr, zlib (2nd try)
Hi, Sorry for sending the same old mail again. It should have been this one: I had a look at the buildd logs of our libisofs https://buildd.debian.org/fetch.cgi?pkg=libisofs;ver=0.6.24-1;arch=kfreebsd-amd64;stamp=1255540287 https://buildd.debian.org/fetch.cgi?pkg=libisofs;ver=0.6.24-1;arch=kfreebsd-i386;stamp=1255540772 I am puzzled by this warning: libisofs/builder.c:209: warning: passing argument 2 of 'aaip_cleanout_st_mode' from incompatible pointer type Is stat.st_mode not of type mode_t ? The line in question is: aaip_cleanout_st_mode(a_text, (info.st_mode), 4 | 16); Argument number two is a component of struct stat info; The function prototype is int aaip_cleanout_st_mode(char *acl_text, mode_t *st_mode, int flag); Can somebody please have a look into sys/stat.h whether struct stat.st_mode is of different size than mode_t ? The warning appears on amd64 and on i386. Another unexplainable warning on both and also on Linux i386: libisofs/tree.c:917: warning: 'brk_info' may be used uninitialized in this function I see in http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/scdbackup/annotate/head%3A/libisofs/tree.c line 917: char *ptr, *brk_info, *component; ... no goto , no open blocks ... component = strtok_r(ptr, /, brk_info); and understand from man 3 strtok_r that brk_info is to be initialized by that function. Looking into my local /usr/include/string.h brings no insight either. Does anybody have an idea what the compiler wants to tell me ? None of the optional libraries and system features is used in the buildd compile runs: - libacl - support for Extended Attributes - zlib At least on Linux this astonishes me. I'll have to ask George for exploring the reason. Nevertheless, the aspects of ACL and xattr are also porting issues. It might be that a Linux-centric configure test prevents the use of the prepared ACL adapter for FreeBSD even on the original system. checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no Do the buildd machines have ACL support installed ? Are there any header files like sys/acl.h to include ? To test ACL on Debian kfreebsd would require a little hack in ./configure, an #ifdef __FreeBSD_kernel__, and somebody who has files with non-trivial ACLs. (The reward would be a backup engine which can record and restore ACLs in ISO images. The images are mountable but OS kernels show no ACLs in them.) Anybody bored enough to volunteer ? Are there Extended Attributes with any of the kfreebsd filesystems ? See on Linux: man 1 getfattr, setfattr. If yes, then i would have to de-Linuxify ./configure checking attr/xattr.h usability... no checking attr/xattr.h presence... no checking for attr/xattr.h... no and i would need documentation of functions like Linux man 2 listxattr, getxattr, removexattr, setxattr. The lack of zlib is a bit pity: checking zlib.h usability... no checking zlib.h presence... no checking for zlib.h... no as it would allow to write compressed files into the image on-the-fly. Is there zisofs support in the FreeBSD kernel ? (Linux can uncompress zisofs formatted files by its read-only isofs filesystem code. So one can mount ISO images with compressed files and sees them uncompressed.) There is also portable intransparent compression if zlib is available. This produces *.gz files inside the ISO image. You unpack them from mounted images by gunzip. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
