GNOME Bugzilla – Bug 399148
Does sizeof(GPid) == sizeof(pid_t)?
Last modified: 2013-11-26 09:44:40 UTC
GLib should document that GPid and pid_t are interchangeable. Or are they? Same about gsize and gssize. They should be documented as replacement dropin of their POSIX equivalents.
By serependity, bug 400184 illustrates that on Solaris typeof (pid_t) == typeof (long), whereas GPid is defined as a bare int on UNIX. So can I second Behdad's question about whether GPid can be used as a replacement for pid_t? (Summary updated)
By inspection of configure.ac, gsize and gssize are guaranteed to be the same size as size_t, but GPid is not guaranteed to be the same size as pid_t (even on Unix). I'll add some straw-man patches.
Created attachment 198101 [details] [review] [1/2] gsize, gssize: guarantee that these are the same as size_t, ssize_t
Created attachment 198102 [details] [review] [2/2] GPid: explicitly do not guarantee equivalance with pid_t
Any opinions on these documentation improvements?
Ugh. That makes any API using GPid broken on 64-bit Solaris. I think the only plausible fix here is to fix the size of GPid; while that's theoretically an ABI break, no one could have been successfully using any GPid-based API on those platforms before, so it should only be able to break already-broken apps. Right?
(In reply to comment #6) > Ugh. That makes any API using GPid broken on 64-bit Solaris. If pid_t is 64-bit but no process is allowed to have a pid greater than G_MAXINT32, then everything's fine, even on 64-bit Solaris? I don't know whether that's the case, though. (Analogous: on Linux, pid_t is a 32-bit integer, but normally only takes 16-bit values, and can't actually be more than 2^29 without breaking futexes.)
wait, http://docs.oracle.com/cd/E19455-01/806-0477/chapter3-52/index.html says: Related to this, a number of derived types might have changed under the LP64 data model for the reason stated above. For example, pid_t remains a long in the 32-bit environment, but under the 64-bit environment, a pid_t is an int. implying that they changed the typedef to keep the type the same size... (found while googling for "solaris 64bit pid_t")
(In reply to comment #3) > [1/2] gsize, gssize: guarantee that these are the same as size_t, ssize_t Any chance of a review for this documentation clarification?
Comment on attachment 198101 [details] [review] [1/2] gsize, gssize: guarantee that these are the same as size_t, ssize_t sure
doesn't apply anymore, and we already say 'corresponding to'
The original questions were: is GPid guaranteed to be the same size as pid_t? is g(s)size guaranteed to be (s)size_t? I don't think "corresponding to" is enough to distinguish between "large enough to store all foo_t values" (i.e. sizeof (gfoo) >= sizeof (foo_t)) and "the same size as a foo_t, such that you can pass a gfoo* where a foo_t* is expected" (sizeof (gfoo) == sizeof (foo_t)).