nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 01:48:00 +00:00
Code Issues Projects Releases Wiki Activity

Mention 'no VLAs' in the C-standards UDP section.

Browse Source 
Now we're enforcing it in the build, it ought to be documented as
well.
This commit is contained in:
Simon Tatham 2019-01-02 22:04:57 +00:00
parent 8d6d7a3615
commit 2af10ee8d1
1 changed files with 20 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/udp.but
View File

@ -42,18 +42,27 @@ to do endianness-dependent operations, and so on.
some of these portability issues. The Windows front end compiles on some of these portability issues. The Windows front end compiles on
both 32- and 64-bit x86 and also Arm.) both 32- and 64-bit x86 and also Arm.)
Our current choice of C standards version is C99: you can assume that Our current choice of C standards version is \e{mostly} C99. With a
C99 features are available (in particular \cw{<stdint.h>}, couple of exceptions, you can assume that C99 features are available
\cw{<stdbool.h>} and \c{inline}), but you shouldn't use things that (in particular \cw{<stdint.h>}, \cw{<stdbool.h>} and \c{inline}), but
are new in C11 (such as \cw{<uchar.h>} or \cw{_Generic}). you shouldn't use things that are new in C11 (such as \cw{<uchar.h>}
or \cw{_Generic}).
One small exception to that: for historical reasons, we still build in The exceptions to that rule are due to the need for Visual Studio
one configuration which lacks \cw{<inttypes.h>}. So that file is compatibility:
included centrally in \c{defs.h}, and has a set of workaround
definitions for the \cw{PRIx64}-type macros we use. If you need to use \b Don't use variable-length arrays. Visual Studio doesn't support
another one of those macros, you need to add a workaround definition them even now that it's adopted the rest of C99. We use \cw{-Wvla}
in \c{defs.h}, and don't casually re-include \cw{<inttypes.h>} when building with gcc and clang, to make it easier to avoid
anywhere else in the source file. accidentally breaking that rule.
\b For historical reasons, we still build with one older VS version
which lacks \cw{<inttypes.h>}. So that file is included centrally in
\c{defs.h}, and has a set of workaround definitions for the
\cw{PRIx64}-type macros we use. If you need to use another one of
those macros, you need to add a workaround definition in \c{defs.h},
and don't casually re-include \cw{<inttypes.h>} anywhere else in the
source file.
Here are a few portability assumptions that we \e{do} currently allow Here are a few portability assumptions that we \e{do} currently allow
(because we'd already have to thoroughly vet the existing code if they (because we'd already have to thoroughly vet the existing code if they