Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
I've enabled gcc's format-string checking on dupprintf, by declaring
it in misc.h to have the appropriate GNU-specific attribute. This
pointed out a selection of warnings, which I've fixed.
[originally from svn r10084]
privileges just before dying of a fatal signal. I'm not sure what I
intended it for in the first place; it certainly isn't doing its job
properly (no setgid), it's causing compiler warnings due to not
checking the setuid return code, and we can't think of any useful
purpose for it.
[originally from svn r9766]
pty_utmp_helper_pipe _and_ the close of it if we're not going to write
should be conditionalised on the pipe existing, rather than just the
former!
[originally from svn r9729]
open("/dev/ptmx"), where the former is available. Improves
portability, since at least one OS (OpenBSD) supports the POSIX pty
functions but does it via an underlying mechanism which doesn't
involving having a /dev/ptmx.
[originally from svn r9728]
OS doesn't automatically assume it.
(It would seem faintly weird to me - surely opening the master end of
a given pty is a fairly good indication that you're _not_ a process
running inside it which wants to have it available as /dev/tty! But
you never know...)
[originally from svn r9727]
and the argument list contains only one string, try again by passing
that single string to "$SHELL -c" to be parsed as a shell command.
This matches xterm's behaviour (as of xterm 261, at least), and means
in practice that users can do _either_ of 'pterm -e some command' and
'pterm -e "some command"'.
(A quick survey suggests that the majority of X terminal programs agree
with pterm's old behaviour of only supporting '-e some command',
except that gnome-terminal only supports the other behaviour and xterm
supports both. With that disagreement, I think supporting both is
probably the sensible thing.)
[originally from svn r9575]
because (a) under that circumstance we won't be writing to utmp
anyway, and (b) if we aren't setuid, then we won't have created the
pty at the point we fork, so even if our subprocess _could_ have
written to utmp it wouldn't have done it right!
Spotted by valgrind (triggering on the access beyond the end of the
ttyname string in setup_utmp, clueing me in to it having been empty).
[originally from svn r9309]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
SIGPIPE ignored in its child processes, leading to unexpected
behaviour inside pterms. (The gnome-session I'm sitting in front of
doesn't seem to do this as far as I can tell, but I don't doubt there
are some that do.) Add SIGPIPE to the list of signals we reset to
default behaviour before launching pterm's child process.
[originally from svn r9117]
except that O_NONBLOCK is standardised and FIONBIO isn't. In consequence,
replace our only use of FIONBIO with O_NONBLOCK.
Inspired by Jonathan H N Chin, who had problems with this on Solaris.
[originally from svn r7753]
port number in the GUI when the connection type is changed if the current
port number is the standard one for the current protocol.
It's not perfect, but it should make the common case of tabbing through the
Session panel easier when starting non-SSH connections on odd ports.
[originally from svn r7635]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
subprocess. They were intended to make sure the child process didn't
inherit anything embarrassing or inconvenient from us, such as the
master end of its own pty, but now we instead do this by making sure
to set all our own fds to not-FD_CLOEXEC on creation. This should
fix Debian bug #357520.
(This doesn't seem to work _quite_ right in uxproxy.c's invocation
of a local proxy command: both ends of a GTK internal pipe end up in
the child process's fd space. This appears to be another GTK 1 bug,
inasmuch as it goes away when I build with Colin's preliminary GTK 2
patch; for the moment I think leaving that pipe lying around is
probably less harmful than hampering the proxy process's ability to
use extra fds by prior arrangement with PuTTY's parent process.)
[originally from svn r7107]
PuTTY causes the child process to inherit a lot of socket fds from
its parent, which is a pain if one of them then ends up holding open
a listening socket which the parent was using for port forwarding
after the parent itself is dead.
Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix
platform directory wherever there looks like being a long-lived fd.
[originally from svn r6917]
it's NULL. Since we already have one back end (uxpty) which doesn't
in fact talk to a network socket, and may well have more soon, I'm
replacing this TCP/IP-centric function with a nice neutral
`connected' function returning a boolean. Nothing else about its
semantics has currently changed.
[originally from svn r6810]
sufficiently large string into pterm in any circumstances in which
it's echoed back to the terminal will cause a deadlock once the
pty's write buffer fills up.
[originally from svn r6582]
X/Open and actually seems to be more common (NetBSD has it). Also use
updwtmpx() rather than directly writing to the wtmpx file, though more for
reasons of aesthetics than anything practical.
[originally from svn r5678]
_XOPEN_SOURCE. We do still need _GNU_SOURCE in order to get grantpt()
on GNU systems. This allows uxpty.c to compile on NetBSD.
[originally from svn r5675]
structure, in preparation for wanting more than one of them in a
single process. This can't be done cleanly, because the whole
business with pty_pre_init pre-allocating the pty rather assumes we
want a known number of the things before we drop privileges; so
there's a horrid hack to make pty_pre_init work on platforms that
have at most one pty instance per process, but at the same time
things ought to work sensibly with more than one per process _if_
pty_pre_init isn't required.
[originally from svn r5261]
/dev/ptyXX we can open: we must also check that we can open and use
the corresponding /dev/ttyXX, because if it's been left in the wrong
mode then we will look terribly silly when we fork and _then_
discover our pty is unusable.
[originally from svn r5257]
