mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
afb3dab1e9
In windows/window.c, a few variables inside functions were declared as static, with no particular purpose that I can see: they don't seem to have any reason to persist between calls to the function. So it makes more sense to have them be ordinary stack-allocated automatic variables. Static variables removed by this commit: - 'RECT ss' in reset_window. - 'WORD keys[3]' and 'BYTE keysb[3]' in TranslateKey. - several (buffer, length) pairs in do_text_internal. - keys_unicode[] in TranslateKey. All of these variables were originally introduced in patches credited to Robert de Bath, which means I can't even try to reconstruct my original thought processes, because they weren't _my_ thoughts anyway. The arrays in do_text_internal are the easiest to understand: they're reallocated larger as necessary, and making them static means the allocation from a previous call can be reused, saving a malloc (though I don't think that's a good enough reason to bother, these days). The fixed-size static arrays and RECT are harder to explain. I suspect they might originally have been that way because of 1990s attitudes to performance: in x86-32 it's probably marginally faster to give your variables constant addresses than sp-relative ones, and in the 1990s computers were much slower, so there's an argument for making things static if you have no _need_ to make them automatic. These days, the difference is negligible, and persistent state is much more widely recognised as a risk! But keys_unicode[] is by far the strangest, because there was code that clearly _did_ expect it to persist between calls, namely three assignments to keys_unicode[0] near the end of the function after it's finished being used for any other purpose, and a conditioned-out set of debug() calls at the top of the function that print its contents before anything has yet written to it. But as far as I can see, the persistent data in the array is otherwise completely unused. In any call to the function, if keys_unicode is used at all, then it's either written directly by a call to ToAsciiEx, or else (for pre-NT platforms) converted from ToAsciiEx's output via MultiByteToWideChar. In both cases, the integer variable 'r' indicates how many array elements were written, and subsequent accesses only ever read those elements. So the assignments to keys_unicode[0] at the end of the previous call will be overwritten before anything at all can depend on them - with the exception of those debug statements. I don't really understand what was going on here. It's tempting to guess that those final assignments must have once done something useful, and the code that used them was later removed. But the source control history doesn't bear that out: a static array of three elements (under its original name 'keys') was introduced in commit |
||
---|---|---|
charset | ||
cmake | ||
contrib | ||
crypto | ||
doc | ||
icons | ||
keygen | ||
otherbackends | ||
proxy | ||
ssh | ||
stubs | ||
terminal | ||
test | ||
unicode | ||
unix | ||
utils | ||
windows | ||
.gitignore | ||
aqsync.c | ||
be_list.c | ||
Buildscr | ||
Buildscr.cv | ||
callback.c | ||
cgtest.c | ||
CHECKLST.txt | ||
clicons.c | ||
CMakeLists.txt | ||
cmdgen.c | ||
cmdline.c | ||
config.c | ||
console.c | ||
console.h | ||
defs.h | ||
dialog.c | ||
dialog.h | ||
errsock.c | ||
import.c | ||
LATEST.VER | ||
ldisc.c | ||
LICENCE | ||
licence.pl | ||
logging.c | ||
marshal.h | ||
misc.h | ||
mksrcarc.sh | ||
mkunxarc.sh | ||
mpint.h | ||
network.h | ||
pageant.c | ||
pageant.h | ||
pinger.c | ||
pscp.c | ||
psftp.c | ||
psftp.h | ||
psftpcommon.c | ||
psocks.c | ||
psocks.h | ||
putty.h | ||
puttymem.h | ||
README | ||
release.pl | ||
settings.c | ||
sign.sh | ||
specials.h | ||
ssh.h | ||
sshcr.h | ||
sshkeygen.h | ||
sshpubk.c | ||
sshrand.c | ||
storage.h | ||
timing.c | ||
tree234.h | ||
version.h | ||
x11disp.c |
This is the README for PuTTY, a free Windows and Unix Telnet and SSH client. PuTTY is built using CMake <https://cmake.org/>. To compile in the simplest way (on any of Linux, Windows or Mac), run these commands in the source directory: cmake . cmake --build . Then, to install in the simplest way on Linux or Mac: cmake --build . --target install On Unix, pterm would like to be setuid or setgid, as appropriate, to permit it to write records of user logins to /var/run/utmp and /var/log/wtmp. (Of course it will not use this privilege for anything else, and in particular it will drop all privileges before starting up complex subsystems like GTK.) The cmake install step doesn't attempt to add these privileges, so if you want user login recording to work, you should manually ch{own,grp} and chmod the pterm binary yourself after installation. If you don't do this, pterm will still work, but not update the user login databases. Documentation (in various formats including Windows Help and Unix `man' pages) is built from the Halibut (`.but') files in the `doc' subdirectory. If you aren't using one of our source snapshots, you'll need to do this yourself. Halibut can be found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>. The PuTTY home web site is https://www.chiark.greenend.org.uk/~sgtatham/putty/ If you want to send bug reports or feature requests, please read the Feedback section of the web site before doing so. Sending one-line reports saying `it doesn't work' will waste your time as much as ours. See the file LICENCE for the licence conditions.