[Bug 866669] New: xdr_u_longlong_t takes u_quad_t as parameter
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c0 Summary: xdr_u_longlong_t takes u_quad_t as parameter Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: P.rehme@physik.uni-stuttgart.de QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 Try to compile a file with header <rpc/xdr.h> included. The compiler throws an error: error: invalid conversion from ‘quint64* {aka long long unsigned int*}’ to ‘u_quad_t* {aka long unsigned int*}’ when using a unsigned long long int* as second argument to xdr_u_longlong_t(). But using u_quad_t* which seems to be of unsigned long int* works. Reproducible: Always Steps to Reproduce: 1. Include <rpc/xdr.h> 2. make a call to xdr_u_longlong_t() with the 2nd argument beeing a unsigned long long int Actual Results: Compiling fails. Expected Results: Compiling does not fail. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c1 Bernhard Wiedemann <bwiedemann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwiedemann@suse.com AssignedTo|bnc-team-screening@forge.pr |schwab@suse.com |ovo.novell.com | --- Comment #1 from Bernhard Wiedemann <bwiedemann@suse.com> 2014-03-17 15:53:21 CET --- I can reproduce it here on 12.3 following the docs on http://docs.oracle.com/cd/E19683-01/816-0214/6m6nf1par/index.html #include <rpc/xdr.h> main() { XDR *xdrs; //u_quad_t ull; u_longlong_t ull; xdr_u_longlong_t(xdrs, &ull); } this is part of glibc-devel -> assigning to maintainer -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c2 --- Comment #2 from Michael Matz <matz@suse.com> 2014-03-17 15:33:07 UTC --- Where is u_longlong_t defined for you? I don't find it anywhere in glibc or the other standard headers (and accordingly the above example indeed throws "error: unknown type name ‘u_longlong_t’"). glibc's prototype of xdr_u_longlong_t simply requires u_quad_t, which is __u_quad_t from sys/types.h (via bits/types.h), so is a "standard" linux type. u_longlong_t is not. The about only thing we could do is to add a typedef of u_longlong_t to rpc/types.h (to u_quad_t, and same for signed variant), but that wouldn't solve your problem, xdr_u_longlong_t would still require a type equivalent to unsigned long*, not unsigned long long* (despite the name). We could also change the implementation of xdr_u_longlong_t to actively require a (unsigned) long long, but that would theoretically have ABI implications (though not in practice on usual 64bit platforms). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c3 --- Comment #3 from Bernhard Wiedemann <bwiedemann@suse.com> 2014-03-17 16:41:12 CET --- err. indeed example was wrong. should be #include <rpc/xdr.h> main() { XDR *xdrs; unsigned long long ull; xdr_u_longlong_t(xdrs, &ull); } -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c4 --- Comment #4 from Andreas Schwab <schwab@suse.com> 2014-03-18 13:07:14 CET --- Where is u_longlong_t defined? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c5 --- Comment #5 from Michael Matz <matz@suse.com> 2014-03-18 12:17:34 UTC --- (In reply to comment #4)
Where is u_longlong_t defined?
I believe that's exactly the problem. It's defined nowhere in linux, and xdr_u_longlong_t takes an u_quad_t in glibc. Solaris' variant takes an u_longlong_t (and presumably defines it in rpc/types.h, can't check). The problem of course is, that the name of the function suggests it takes an argument that's compatible with "unsigned long long *" (which is what Solaris' version indeed seems to do), but in fact doesn't. On 32bit machines it will also take long long * in linux, but on 64bit machine it just takes a long * (because quad_t is defined to some 64bit type, so long is enough on 64bit). So, for Solaris compatibility it would be better to change the prototype to take an u_longlong_t (and define it to unsigned long long for all platforms). But it could change behaviour of existing programs that expect u_quad_t to work (which wouldn't be compatible with u_longlong_t if it were defined as above on 64bit machines). I don't know a good solution :-/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c6 Andreas Schwab <schwab@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com --- Comment #6 from Andreas Schwab <schwab@suse.com> 2014-03-18 13:56:48 CET --- The interface was added by Thorsten Kukuk on 1999-04-01. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c7 --- Comment #7 from Andreas Schwab <schwab@suse.com> 2014-03-18 14:00:17 CET --- The manual says that xdr_u_longlong_t is identical to xdr_hyper, and the latter takes a quad_t as well on glibc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c8 --- Comment #8 from Andreas Schwab <schwab@suse.com> 2014-03-18 14:03:51 CET --- And *BSD follows glibc in this point. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c9 --- Comment #9 from Thorsten Kukuk <kukuk@suse.com> 2014-03-18 13:15:43 UTC --- I did only apply a patch somebody else posted, as written in that ChangeLog entry. The interface in this form is coming from SUN, more specific from the TI-RPC sources SUN released as open source at that time. Don't know about Solaris, but the ti-rpc sources and other BSD variants still have the same prototype today: extern bool_t xdr_u_longlong_t(XDR *, u_quad_t *); The question is, if the definition of u_quad_t is is correct. From what I could find u_quad_t should be defined as u_int64 on x86-64. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c10 --- Comment #10 from Andreas Schwab <schwab@suse.com> 2014-03-18 17:25:59 CET --- u_quad_t has the same defintion as u_int64_t, both are unsigned long. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c11 --- Comment #11 from Thorsten Kukuk <kukuk@suse.com> 2014-03-18 16:47:34 UTC --- Ok, this reminds me on one important thing: All types of xdr_*() functions need to have the same size on any system, else a 32bit system for example couldn't communicate with a 64bit system any longer. Thus u_quad_t/u_int64_t for xdr_u_longlong_t on x86-64 seems to be correct. You only need to remind when this functions where written and that no 64bit systems did exist at that time. I propose to not change anything to not break all existing RPC software out in the world. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c12 --- Comment #12 from Andreas Schwab <schwab@suse.com> 2014-03-18 17:55:36 CET --- Since long long is currently 64bit on all systems this wouldn't change anything, but 128bit long long may arrive some day. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=866669 https://bugzilla.novell.com/show_bug.cgi?id=866669#c13 Andreas Schwab <schwab@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #13 from Andreas Schwab <schwab@suse.com> 2014-03-20 09:22:00 CET --- Since glibc matches what BSD does this is not a bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com