Putty Chiark Mac Port Is

We have made some effort to make it easy to compile our code using a C compiler: notably, our snew, snewn and sresize macros explicitly cast the return values of malloc and realloc to the target type. (This has type checking advantages even in C: it means you never accidentally allocate the wrong size piece of memory for the pointer type youre assigning it to.

We recommend enabling them.

SSH.COM uses cookies to give you the best experience and most relevant marketing.

If you are planning to send code contributions, you should read this first.

Putty Chiark Mac Port Is

It has a working Unix port; a Mac port is in progress; more ports may or may not happen at a later date.

Therefore, embedding Windows-specific code in core modules such as ssh.c is not acceptable.

We went to great lengths to remove all the Windows-specific stuff from our core modules, and to shift it out into Windows-specific modules.

Adding large amounts of Windows-specific stuff in parts of the code that should be portable is almost guaranteed to make us reject a contribution.

The PuTTY source base is divided into platform-specific modules and platform-generic modules.

The Unix-specific modules are all in the unix subdirectory; the Mac-specific modules are in the mac subdirectory; the Windows-specific modules are in the windows subdirectory.

All the modules in the main source directory - notably all of the code for the various back ends - are platform-generic.

This also means you should stick to what you are guaranteed by ANSIISO C (that is, the original C89C90 standard, not C99).

Try not to make assumptions about the precise size of basic types such as int and long int; dont use pointer casts to do endianness-dependent operations, and so on.

There are one or two aspects of ANSI C portability which we dont care about.

In particular, we expect PuTTY to be compiled on 32-bit architectures or bigger; so its safe to assume that int is at least 32 bits wide, not just the 16 you are guaranteed by ANSI C.

Similarly, we assume that the execution character encoding is a superset of the printable characters of ASCII, though we dont assume the numeric values of control characters, particularly n and r.

Also, the X forwarding code assumes that timet has the Unix format and semantics, i.e.

D.2 Multiple backends treated equally PuTTY is not an SSH client with some other stuff tacked on the side.

PuTTY is a generic, multiple-backend, remote VT-terminal client which happens to support one backend which is larger, more popular and more useful than the rest.

Any extra feature which can possibly be general across all backends should be so: localising features unnecessarily into the SSH back end is a design error.

For example, we had several code submissions for proxy support which worked by hacking ssh.c.

Clearly this is completely wrong: the network.h abstraction is the place to put it, so that it will apply to all back ends equally, and indeed we eventually put it there after another contributor sent a better patch.) The rest of PuTTY should try to avoid knowing anything about specific back ends if at all possible.

To support a feature which is only available in one network protocol, for example, the back end interface should be extended in a general manner such that any back end which is able to provide that feature can do so.

If it so happens that only one back end actually does, thats just the way it is, but it shouldnt be relied upon by any code.

D.3 Multiple sessions per process on some platforms Some ports of PuTTY - notably the in-progress Mac port - are constrained by the operating system to run as a single process potentially managing multiple sessions.

Therefore, the platform-independent parts of PuTTY never use global variables to store per-session data.

The global variables that do exist are tolerated because they are not specific to a particular login session: flags defines properties that are expected to apply equally to all the sessions run by a single PuTTY process, the random number state in sshrand.c and the timer list in timing.c serve all sessions equally, and so on.

But most data is specific to a particular network session, and is therefore stored in dynamically allocated data structures, and pointers to these structures are passed around between functions.

Platform-specific code can reverse this decision if it likes.

The Windows code, for historical reasons, stores most of its data as global variables.

Thats OK, because on Windows we know there is only one session per PuTTY process, so its safe to do that.

But changes to the platform-independent code should avoid introducing global variables, unless they are genuinely cross-session.

D.4 C, not C PuTTY is written entirely in C, not in C.

Putty Chiark For Mac