Re: Inconsistency about struct stat and dev_t on mips and mipsel

James Cowgill <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <[email protected]>
Hi,

On Mon, 2015-09-14 at 15:53 +0200, Thomas Schmitt wrote:
> Since quite a while the buildd logs of libisoburn on mips and
> mipsel show a riddling warning, which may actually indicate a
> serious bug in the resulting binaries:
> 
>   https://buildd.debian.org/status/fetch.php?pkg=libisoburn&arch=mips&ver=1.4.0-3&stamp=1442236259
> 
>   xorriso/iso_tree.c: In function 'Xorriso_fake_stbuf':
>   xorriso/iso_tree.c:282:47: warning: passing argument 4 of 'Xorriso_node_get_dev' from incompatible pointer type [-Wincompatible-pointer-types]
>       Xorriso_node_get_dev(xorriso, *node, path, &(stbuf->st_rdev), 0);
>                                                ^
>   xorriso/iso_tree.c:229:5: note: expected 'dev_t * {aka long long unsigned int *}' but argument is of type 'long unsigned int *'
>    int Xorriso_node_get_dev(struct XorrisO *xorriso, IsoNode *node,
> 
> The inconsistency is that "stbuf" is declared as
>   struct stat *stbuf
> and POSIX compliant man 2 stat declares 
>   struct stat {
>       ...
>       dev_t     st_rdev;        /* device ID (if special file) */
>       ...
>   };

Yes, for historical reasons mips (o32) defines struct stat with a 32
-bit dev_t even though it defines dev_t to be 64-bits. It's been
defined this way since at least 1997 when mips was added to glibc (I
expect the structure was copied from old SGI libc). This means that
what you are doing really is undefined behaviour on mips :(

There is an upstream bug about it here:
https://sourceware.org/bugzilla/show_bug.cgi?id=17786

Changing it in glibc isn't too hard except it will break the ABI of any
shared libraries which use 'struct stat *' in their interface (glibc
itself will use symbol versions).

Thanks,
James
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABCgAGBQJV9yY9AAoJEMfxZ23qLQHvoIsP/11zyTDva9SOo5UMyJWZhced
RcUX9JgLGpczL/ZHrPnOn7szHrYweGLcrftgt/UEYkM1tPRpDVNmrPec1g5QtqIZ
6iLuxy59PAN8m4HkAMoW+uQC0L3UFDvm1e1PY2nZHrmTLZBdorbOwQTsAgTZUOTh
mrRbQepUDmujOy5MQWuCmWtZHImAPponZqO/eY3z+mSIuW/o75AlrvIFp0eRFOL/
XP9nR2iLd7Ru4Wb/tIvK0il58FTx2MvmfyeXdn1jUcgSo5rJUTpIRcgeYZ2VKRef
E61CCfyVub3RGzK+gCcQPfKw6JMBnC+uiYe25FwLLJu4KEi+6uLbdjNKTbzpGZKZ
H5M3f99XKel2eh2z9lZaiEO44W4tatAmxhlhoWfMouwQUX1LxB9lD2KoNnd00ZNE
3O0Pfn2StMT3TsB/yHhYxAF1bxVrtNRo2u2RzOm8lpizaJ980L7BpnNbKInLw0X7
htoC2hnc1MIOVSU/kSy1+98UVJjmW76+mfVNy7mVUJZBZpmqeYv5KNmFelj72xx4
V/dqkUuj6mXze99/+QhFCRVciPnf51i4nIsrQmOYUoph2dBBzav0WDpfM/g7HUKm
LXpKczyATlJaTlgi8aeKEmvc2AHYrI27ScvQG4e+IUxu/1UBaVpqTMRYKWS2Xy+Q
lkpEFGUq7Yz1VQa3oWQG
=M86P
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.