GNOME Bugzilla – Bug 400184
_vte_pty_open declaration mismatch - breaks on Solaris
Last modified: 2007-01-24 20:41:40 UTC
The declaration of _vte_pty_open in pty.h and the definition in pty.c are no longer in sync. This breaks the build on Solaris. http://svn.gnome.org/viewcvs/vte/trunk/src/pty.c?rev=1493&r1=1430&r2=1493 In pty.c the first parameter changed from: pid_t *child to GPid *child "pty.c", line 955: identifier redeclared: _vte_pty_open current : function(pointer to int, pointer to pointer to char, pointer to const char, pointer to pointer to char, pointer to const char, int, int, int, int, int) returning int previous: function(pointer to long, pointer to pointer to char, pointer to const char, pointer to pointer to char, pointer to const char, int, int, int, int, int) returning int : "pty.h", line 31 cc: acomp failed for pty.c The attached patch syncs them again.
Created attachment 81064 [details] [review] Sync up _vte_pty_open definition and declaration
Thanks. r1513: 2007-01-24 Chris Wilson <chris@chris-wilson.co.uk> Bug 400184 – _vte_pty_open declaration mismatch - breaks on Solaris Patch by Damien Carbery. * src/pty.h: Update prototype to match new definition.
Damien, is any architecture on which Solaris defines int and long sizes of different sizes? If this is the case, we need to back up the pid_t->GPid change.
Hmm, don't think this is the case as the compiler warning says: current: ... returning int [function definition in pty.c] previous: ... returning int [function definition in pty.h]
Excuse me, completely misread that. (I was supposed to be looking at the first argument, the pointer to long)
Behdad, to be safe we should change the public functions to return pid_t once more and flag up the issue on your GLib GPid bug.
Created attachment 81089 [details] [review] Cast GPid to pid_t in public functions Unfortunately the issue if sizeof (pid_t) != sizeof (GPid) is propagated from g_spawn.
Yeah, lets back up... At least in all public interfaces.
These are the ones that need to change back: pty.h:int _vte_pty_open(GPid *child, char **env_add, reaper.h:int vte_reaper_add_child(GPid pid); vte.h:GPid vte_terminal_fork_command(VteTerminal *terminal, vte.h:GPid vte_terminal_forkpty(VteTerminal *terminal, And don't we have to include sys/types.h again?
Created attachment 81094 [details] [review] Revert to using pid_t for public functions Hmm, not sure about the reaper change as it uses GPid in 0.14.1.
And the _vte_pty_open() is private.
Oh, do we also worry about the python exports?
(In reply to comment #11) > And the _vte_pty_open() is private. Not really. The header was public, so I didn't hide those symbols: -export-symbols-regex ^vte_terminal_.*|^_vte_pty_.*|^vte_reaper_.*|_vte_debug_.*" But we probably should, and increase soname. But someone should first search on Google code and make sure they really aren't used... Yes, I think we should revert the python changes too.
Created attachment 81104 [details] [review] Revert to using pid_t for public functions, take 2 That propagates the changes back to pid_t. Though internally we now have (GPid)(pid_t)(GPid)... python/vte.defs | 4 ++-- python/vte.override | 4 ++-- src/pty.c | 15 ++++++++++----- src/pty.h | 5 ++--- src/vte.c | 14 +++++--------- src/vte.h | 6 ++++-- 6 files changed, 25 insertions(+), 23 deletions(-) Leaving reaper unchanged.
r1519: 2007-01-24 Chris Wilson <chris@chris-wilson.co.uk> Bug 400184 – _vte_pty_open declaration mismatch - breaks on Solaris actually revealed a faux-pas in the conversion of the public interfaces to GPid - that it broke the ABI. However, the intention is to remove the exposed pid_t, cf bug 400333. * python/vte.defs: * python/vte.override: * src/pty.c: (_vte_pty_open): * src/pty.h: * src/vte.c: (_vte_terminal_fork_basic), (vte_terminal_forkpty): * src/vte.h: Revert the exposed GPids back to pid_t.