% file staticanalys-bm.tex, which is \input from bismon-doc.tex
\section{Static analysis of source code in \emph{Bismon}}
\label{sec:staticanalys}

Static analysis involves a \emph{generated} GCC plugin (whose C++ code
is generated by the \emph{bismon} persistent monitor) which
communicates with the monitor and sends to it some digested form of
the analyzed C or C++ code. Some translation-unit specific processing
can happen in that GCC plugin, but the whole program aspects of the
static code analysis should obviously be done inside the monitor, and
requires -and justifies- its persistence. The complexity and
non-stability of \emph{GCC} internal representations justify some
semi-automatic approach in extracting them (see \S\ref{subsec:analygcc}
below).

%The rest of this chapter will be written in the final D1.3\textsuperscript{v2} version.

%-A significant part of this chapter should be generated (like \emph{GCC
%-  MELT} generated its documentation, see
%-\cite{Starynkevitch-GCCMELTweb}) from the persistent state of
%-\emph{Bismon}. Perhaps this chapter should be put after the ``using
%-Bismon'' chapter (\S\ref{sec:using}).

\subsection{static analysis of \emph{GCC} code}
\label{subsec:analygcc}

The \emph{GCC} compiler has a complex (and ill-defined,
under-documented and evolving, so unstable) application programming
interface (API) which can be used by plugins. So \emph{Bismon} needs
to analyze the various \emph{GCC} plugin related \emph{header files}
to extract important information about that API, so to be later able
to generate \emph{GCC} plugin code. Such an extraction (inspired by
the approach inside \emph{Clasp}, which does similar things with the
help of \emph{Clang}, see \cite{Schafmeister:2015:CLASP} for details)
needs not to care about the \emph{Gimple} instructions, but only about
the abstract syntax tree in \emph{Tree} and \emph{Generic} forms (see
\cite{gcc-internals} \S11) to retrieve the full description of
\emph{GCC}.

This approach of extracting semi-automatically~\footnote{We are well
  aware that some work still needs to be done manually, in particular
  giving the really useful subpart of the \emph{GCC} API.} the GCC API
(of parsing GCC header files with some simple GCC plugin) is motivated
by past GCC MELT experience (where every feature of the GCC API had to
be \emph{explicitly} and manually described in MELT language; these
descriptions took a lot of time to be written and had to be manually
maintained; however, most of them could in theory be extracted
automatically from GCC headers).

A bootstrapping and incremental approach, in several ``steps'', is
worthwhile (and possible because of persistence): we will first
extract some very simple information from GCC header files, and use
them to improve the next extraction from the same GCC header
files. The \emph{slow} evolution~\footnote{GCC internals are
  \emph{slowly} evolving, because GCC itself is huge: its
  ``navigation'' is as slow as that of a supertanker which needs hours
  to turn and change directions. So for \emph{social} reasons the GCC
  community is changing the API slowly, but there is no promise of
  stability.}  of GCC API is practically relevant (most of the API of
\texttt{gcc-8.3} should stay in the next \texttt{gcc-9.0} version).

Descriptive data related to the API of a particular version of GCC
will thus stay persistently in the \emph{Bismon} monitor, but should
be updated at each release of \emph{GCC}. We care mostly about API
related to optimization passes, \emph{GENERIC}, \emph{Gimple},
\emph{SSA} and \emph{Optimized-Gimple}. We probably don't need to go
at the \emph{RTL} level. The version
\href{https://gcc.gnu.org/gcc-10/}{10 of \textsc{Gcc}} (released in
May 2020) incorporates several
\href{https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html}{static
  analysis options}, that are activated with the \texttt{-fanalyzer}
option to \texttt{g++} or \texttt{gcc}. The version
\href{http://lists.llvm.org/pipermail/llvm-announce/2020-March/000087.html}{10
  of \textsc{Clang}} (released in March 2020) contains an improved
\href{https://clang-analyzer.llvm.org/}{Clang static analyzer} and
\href{https://clang.llvm.org/extra/clang-tidy/}{\texttt{clang-tidy}}
``linter'' like tool, check both coding styles and portability
related conventions. Both compilers are open source and available
\footnote{Both recent \textsc{Gcc} and \textsc{Clang} are buildable as
cross compiler for major 32 bits or 64 bits architectures such as
PowerPC, x86, x86-64, or ARM, provided one download their source
code.} on a \textsc{Linux} desktop and both should be of interest for
advanced \emph{IoT} software developers coding in C or in C++ and
capable of using the command line. \textsc{Gcc} analysis features be
configured thru appropriate \texttt{\#pragma}-s, and \textsc{Clang}
analysis features are changeable by conventional comments such as
\texttt{// NOLINT(google-explicit-constructor, google-runtime-int)}.

%Additional content of this \S\ref{subsec:analygcc} will be written
%for the final D1.3\textsuperscript{v2}.


\subsection{static analysis of IoT firmware or application code}
\label{subsec:analysiot}

Once the API of the current version of \emph{GCC} is known to the
persistent monitor, we can generate the C++ code of \emph{GCC} plugins
for cross-compilers used by IoT developers.

A first static analysis, useful to IoT developers, will be related to
whole-program detection of \emph{stack overflow} \index{stack
  overflow} (see also \cite{Payer:2018:MSV}). By the way, such an
analysis is currently not doable by \emph{Frama-C}, because it don't
know the size of each call frame. However, \emph{GCC} is already
computing that size (see the \texttt{-fstack-usage} option which dumps
the size of the call frame of each function, and the
\texttt{-Wframe-larger-than=\emph{bytesize}} option), and we simply
need to extract and keep it. We also need to get a good approximation
of the \emph{control flow graph\index{control flow graph}}. For that
we need to extract basic blocks and just \texttt{GIMPLE\_CALL}
\emph{Gimple} statements (ignoring other kinds of \emph{Gimple}
statements). Of course, indirect calls (thru function pointers, which
are infrequently used in most IoT code) are harder to handle (and
could require interaction with the IoT developer using our monitor, to
annotate them).

A proof-of-concept GCC plugin for GCC 8 (and 9) to take advantage of
existing internal GCC passes to compute some upper approximation of
the call stack size has been developped. That hand-written GCC plugin,
coded in file \texttt{gcc8plugin-demo-chariot-2019Q2.cc} of about a
thousand lines of C++, communicate with the \texttt{bismon} monitor
using some REST HTTP protocol with ad-hoc HTTP \texttt{POST} requests
having a JSON payload, in some \textsc{Chariot} specific JSON
format. The \texttt{bismon} monitor should display that diagnostic in
a Web browser tab. It could also use the \emph{language server
  protocol}~\footnote{See \bmurl{https://langserver.org/} for more.}
which is, in 2019, understood by most free software source code
editors running on Linux, including \texttt{emacs}, or \texttt{vim},
or \texttt{VSCode}. It might even later use the new
\emph{Sarif}\footnote{See
  \bmurl{http://docs.oasis-open.org/sarif/sarif/v2.0/csprd01/sarif-v2.0-csprd01.html}
  for more.}  protocol, designed for communication between static
source code analyser.

Notice that according to
\href{https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/}{this
  webpage}, nearly 70\% of security bugs affecting the Chrome web
browser (by Google) are related to memory management issues in C++.
It is expected that junior European software developers of
non-critical IoT systems would experiment a similar bug distribution
in their IoT code. A long-term approach could be the costly training
of IoT software engineers to switch to programming languages with
better memory management, such as \href{https://golang.org/}{Go} or
\href{https://www.rust-lang.org/}{Rust}. However, rewriting an entire
IoT code base is too costly, and mixing several programming
languages\footnote{See
\href{https://softwareengineering.stackexchange.com/questions/370135/why-are-multiple-programming-languages-used-in-the-development-of-one-product-or}{this}
for a discussion of why is that interesting. Notice that recent
\href{http://gcc.gnu.org/}{GCC} compilers share some common internal
representations between several language front-ends.} in the same
software product can be worthwhile but requires some rare and
qualified labor. \href{https://gcc.gnu.org/gcc-10}{GCC 10} has a new
\href{https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html}{static
  analysis} framework (with its \texttt{-fanalyzer} compiler option)
and powerful warning options\footnote{It is helpful to pass
\texttt{-Wall -Wextra} to the \texttt{gcc} or \texttt{g++} compiler,
usually thru some
\href{https://en.wikipedia.org/wiki/Build_automation}{build
  automation} tool such as
\href{http://ninja-build.org/}{\texttt{ninja}}}. The
\href{https://clang-analyzer.llvm.org/}{\textsc{Clang} static
  analyzer} could be useful. Some coding rules (such as
\cite{Holzmann:2006:power-of-10} or \index{Misra@\textsc{Misra C}}
\href{https://www.misra.org.uk/}{\textsc{Misra C}}) are available, but
the \href{https://en.wikipedia.org/wiki/Rice's_theorem}{Rice's
  theorem} \index{Rice's theorem} forbids the possibility of a sound
and complete static analyzer: false alarms cannot be avoided, and code \index{code review}
reviews by senior programmers is still necessary.

We probably would also take as an example the analysis of some
\href{http://mqtt.org/}{MQTT library}. The insight is to trust some
existing MQTT implementation~\footnote{Our purpose is not to prove the
  correctness of a given MQTT implementation, which would require a
  formal methods approach à la \textsc{Vessedia}, but to help the
  developer using and trusting it, by checking some specific coding
  rules.}, and to help \emph{junior} developers in using it, by
checking simple coding rules relevant to MQTT.

An interesting \textsc{Chariot}-compatible approach could be to use
\emph{topological data analysis} \index{topological data analysis}
\index{data analysis!topological} (cf
\cite{Chazal:2017:topodatanalys}) techniques, combined with some
machine learning (cf \cite{flach:2012:machine-learning}) and big data
\index{big data} / data mining \index{data mining} (cf
\cite{wu:2013:big-data-mining, clarke:2016:big-data-risks,
  zuboff:2015:big-other, helbing:2019:big-data-democracy}) approaches,
on some of the several directed graphs (notably the \emph{control flow
graph}, the \emph{call graph}, the \emph{dependency graph} for
example) of the whole analyzed program. Reputable free software
libraries\footnote{See \textsc{TensorFlow} on
\bmurl{https://www.tensorflow.org/}, and \textsc{Gudhi} on
\bmurl{http://gudhi.gforge.inria.fr/}, and many other similar
libraries.} are available on Linux. In principle, such an approach
might be used in \texttt{bismon} for a \emph{semi-automatic} detection
of \index{code smell} \index{smell!code} \emph{code smells}. Sadly,
the lack of allocated human resources, and the strong focus (see
\cite{Heder:2017:TRL}) \index{TRL} on high
TRL\footnote{\emph{Technical Readiness Level} and the
\href{https://en.wikipedia.org/wiki/Technology\_readiness_level}{TRL
  wikipage} for more.} results, forbids even trying such an
interesting approach in \textsc{Chariot}, taking into account that
industrial corporations are not even dreaming of it. However, these
approaches might be tried in some other projects, perhaps
\index{decoder@\textsc{Decoder}}
\href{https://www.decoder-project.eu/}{\textsc{Decoder}}.

\medskip
\subsection{static analysis related to pointers and addresses}
\label{subsec:analysptr}

Pointers \index{pointer} are an important part of the C11 and C++11
language specifications (see \cite{C11:std, CplusPlus11:std})}, but
  are difficult to understand. They need several chapters\footnote{A
    novice programmer should be explained that after \texttt{int
      tab[4]; int* p = \&tab+1;} both \texttt{tab[2]} and
    \index{alias!pointer} \texttt{p[1]} are pointer aliases, but
    \texttt{sizeof(tab)} is not \texttt{sizeof(p-1)} even if
    \texttt{tab == p-1}.}  in C or C++ textbooks such as
  \cite{gusted:t2019:modern, Stroustrup:2014:CplusPlus}. Practically
  \index{null@\texttt{NULL} in C}
  \index{nullptr@\texttt{\textbf{nullptr}} in C++} speaking, a pointer
  is an address, with \texttt{NULL} (in C) or
  \texttt{\textbf{nullptr}} (in C++) having a special and
  distinguished meaning: it is never the same as the result of the
  \index{address} \emph{address-of} operator (unary \texttt{\&} prefix
  operator).

 From the IoT or firmware developer's point of view, pointers -viewed
 as addresses- may behave strangely in practice, and differently from
 the language specifications: in theory, the \texttt{NULL} pointer
 might not sit at address 0. In practice, IoT or firmware developers
 do know that (on most implementations) it \emph{is} at address
 0. Dereferencing the \texttt{NULL} pointer is the prototypical
 example of \emph{undefined behavior}, yet some firmware
 code\footnote{A typical example would be some \textsc{Bios} or
   \textsc{Uefi} firmware or operating system kernel on most PC
   desktop motherboards, see
   \href{https://osdev.org/}{\texttt{osdev.org}} and
   \href{http://tinyvga.com/}{\texttt{tinyvga.com}} for more} may do
 that with good reasons. For example, some
 \href{https://en.wikipedia.org/wiki/AVR_microcontrollers}{\textsc{Avr}
   microcontrollers} \index{avr@\textsc{Avr} microcontroller} (used in
 \index{arduino@\textsc{Arduino} platform}
 \href{https://arduino.cc/}{\textsc{Arduino} platforms} ``the working
 registers are mapped in as the first 32 memory addresses'' (from the
 \href{https://en.wikipedia.org/wiki/AVR_microcontrollers}{AVR
   microcontrollers} wikipage). The
 \href{https://en.wikipedia.org/wiki/MIPS_architecture}{\textsc{Mips}
   architecture} (used by some \textsc{Chariot} partners) has an
 \index{mips@\textsc{Mips} architecture} instruction set without
 proper I/O ports (see
 \href{https://www2.cs.duke.edu/courses/fall13/compsci250/MIPS32\_QRC.pdf}{this}),
 so input/output happens by accessing some dedicated memory locations:
 from the IoT programmer's point of view, physical I/O happens by
 writing into documented memory locations. The opensource
 \href{https://riscv.org/}{\textsc{Risc-V} architecture}
 \index{riscv@\textsc{Risc-V} architecture}, used in IoT (see
 \cite{lee:2020:miot, waterman:2016:riscv-design})) also has
 memory-based input/output, but admit extensions with separate
 input/output ports.

 Most IoT used operating system kernels (see
 \cite{ArpaciDusseau14-Book}, \index{Linux@\textsc{Linux} operating
   system} \index{kernel!operating system} \index{operating system}
 \index{FreeBSD@\textsc{FreeBSD} operating system}
 \index{FreeRTOS@\textsc{FreeRTOS} kernel}
 \href{https://osdev.org}{\texttt{osdev.org}}) such as the
 \textsc{Linux} \href{http://kernel.org/}{kernel} (see also
 \href{https://kernelnewbies.org}{\texttt{kernelnewbies.org}} and
 \href{https://stackoverflow.com/}{\texttt{stackoverflow.com}}),
 \href{https://www.freebsd.org/}{\textsc{FreeBSD}} and
 \href{https://freertos.org/}{\textsc{FreeRTOS}} are managing
 \href{https://en.wikipedia.org/wiki/Process_(computing)}{processes}
 having each their own
 \href{https://en.wikipedia.org/wiki/Virtual_address_space}{virtual
   address space}and provide the
 \href{https://en.wikipedia.org/wiki/Virtual_memory}{virtual memory}
 abstraction, with some
 \href{https://en.wikipedia.org/wiki/File_system}{file systems} to
 application code.

 \medskip

 In most C or C++ source programs, either in some \emph{freestanding
 environment} (like operating system kernels, low-end embedded
 software without any \texttt{main}, e.g. cheap
 \index{arduino@\textsc{Arduino} platform} \textsc{Arduino}-like
 devices) or in a \emph{hosted environment} (so using the standard C
 or C++ libraries and started thru their \texttt{main} function), for
 example some web server running under \textsc{Linux} on something
 similar to a \index{raspberrypi@\textsc{RaspBerryPi} system}
 \textsc{RaspBerryPi} board), dynamically allocated memory is very
 important in practice. See also \cite{karvinen:2014:make} and
 \href{https://www.raspberrypi.org/}{\texttt{raspberrypi.org}} and
 \href{https://www.arduino.cc/}{\texttt{arduino.cc}} websites.

 In hosted environments, dynamic memory allocation often uses
 functions like
 \href{https://man7.org/linux/man-pages/man3/malloc.3.html}{\texttt{malloc}}
 or its friends \texttt{calloc} with \texttt{realloc} and
 \texttt{free}. On some operating systems, it could happen thru
 lower-level system calls such as
 \href{https://man7.org/linux/man-pages/man2/mmap.2.html}{\texttt{mmap}}
 or
 \href{https://man7.org/linux/man-pages/man2/sbrk.2.html}{\texttt{sbrk}}. Deallocation
 would use other system calls such as
 \href{https://man7.org/linux/man-pages/man2/munmap.2.html}{\texttt{munmap}}.

 Many freestanding environments provide more or less equivalent memory
 allocation facilities. For instance,
 \index{FreeRTOS@\textsc{FreeRTOS} kernel} the \textsc{FreeRTOS}
 kernel has in some cases a \texttt{pvPortMalloc} function with a
 behavior close to \texttt{malloc}, and the
 \index{Linux@\textsc{Linux} kernel} the \textsc{Linux} kernel
 \href{http://www.jikos.cz/jikos/Kmalloc_Internals.html}{uses
   \texttt{kmalloc}}, with other deallocating functions close in
 behavior to \texttt{free}. But on \index{arduino@\textsc{Arduino}
   platform} \textsc{Arduino} devices using \texttt{malloc} is indeed
 \href{https://arduino.stackexchange.com/q/682/12068}{discouraged}.

 Dynamic memory allocation is often used but relevant for two
 important concerns: \index{buffer overflow} \index{call stack}
 \index{stack overflow}
 \href{https://en.wikipedia.org/wiki/Buffer_overflow}{buffer
   overflows} and \href{https://en.wikipedia.org/wiki/Call_stack}{call
   stack} management, including avoidance of
 \href{https://en.wikipedia.org/wiki/Stack_overflow}{stack
   overflow}. Call stacks are needed for any multi-threading or
 multi-tasking approach. Junior developers may easily write code that
 blows them up (e.g. with a too naive recursion in C, or by having
 huge automatic variables). A rule of thumb is to avoid needing, in
 hosted environments, call stacks above a megabyte, or call frames
 bigger than a few kilobytes. With recent \texttt{gcc} compilers,
 \index{wstackusage@\texttt{-Wstack-usage} warning option} passing
 something like \texttt{-Wstack-usage=2048} to the \texttt{gcc}
 compilation command is practically helpful.

 Of course, call stacks are a scare resource, and even on Linux it is
 generally unreasonable to have many thousands of them in the same
 process. This explains why \index{thread} \emph{thread}-s are
 expensive, and why the \index{pthread@\textsc{Pthread} library}
 \href{https://computing.llnl.gov/tutorials/pthreads/}{\textsc{Pthread}}
 function \texttt{pthread\_create} (or C++11 \texttt{std::thread}-s)
 should be used with caution. See also
 \href{https://man7.org/linux/man-pages/man7/pthreads.7.html}{\texttt{pthreads(7)}},
   \href{https://man7.org/linux/man-pages/man7/nptl.7.html}{\texttt{nptl(7)}}
     and the source code of \index{glibc@\textsc{Glibc} library}
     \index{musl@\textsc{Musl libc} library}
     \href{https://www.gnu.org/software/libc/}{GNU \textsc{Glibc}} and
     of \href{https://musl.libc.org/}{\texttt{musl libc}}.

 Depending on the development efforts (so costs) available and on the
 criticity of the IoT software,
 \href{https://en.wikipedia.org/wiki/Out_of_memory}{out of memory
   conditions} \index{out of memory} are handled differently. A lot of
 C code incorrectly assumes that \index{malloc@\texttt{malloc}}
 \texttt{malloc} always\footnote{See
 \href{https://stackoverflow.com/a/8460584/841108}{this
   joke-implementation of \texttt{malloc}}, conforming to the letter
 but not the spirit of the C standard.} succeed. In practice, this
 assumption is generally\footnote{On Linux, be aware of
 \href{http://www.etalabs.net/overcommit.html}{memory overcommit}
 which could \href{https://unix.stackexchange.com/q/441364/50557}{be
   disliked}.}  correct, so for non-critical IoT software\footnote{As
 a consumer, I guess that most consumer rented Internet boxes -
 generally running some Linux - do have some system-wide memory leaks,
 and that observation could explain why rebooting them weekly improve
 the user experience.} it does have some economical sense.


 Most non-critical IoT software (e.g. inside consumer devices, perhaps
 \index{raspberrypi@\textsc{RaspBerryPi} system} \textsc{RaspBerryPi}
 based, or wifi routers based upon \index{openwrt@\textsc{OpenWrt}
   router} \href{https://openwrt.org/}{\textsc{OpenWrt} router}
 software) won't care about and won't even handle (or even try to
 cleverly detect and report) rare error conditions or failures
 \index{failure!of standard C functions} such as :

 \begin{itemize}

 \item rare out of memory conditions \index{memory} (e.g. \texttt{malloc} failures)

 \item file system \index{file system} errors (e.g. \texttt{fopen}
   failure on some \index{configuration file} \index{file system}
   \index{etc@\texttt{/etc/} configuration directory} configuration
   file under \texttt{/etc/}), including I/O errors \index{I/O error}
   \index{fscanf@\texttt{fscanf} function} \index{fread@\texttt{fread}
     function} (e.g. \texttt{fscanf} or \texttt{fread} failures) due
   \index{USB storage} to hardware failure (like malfunctioning USB
   storage keys).

     \item floating point \index{floating point!precision} precision
       issues. \index{precision} See the \index{stance@\textsc{Stance}
         project} \href{http://www.stance-project.eu/}{\textsc{Stance}
         European project} (grant 317753), the
       \href{https://floating-point-gui.de/}{\texttt{floating-point-gui.de}}
       website, and \cite{Kiss:2015:combining, goubault:2011:static}.

     \item losing \index{time} time. See the
       \index{time7@\texttt{time(7)}}
       \href{https://man7.org/linux/man-pages/man7/time.7.html}{\texttt{time(7)}}
       \texttt{man} page for an interesting overview. A battery
       powered \index{clock!real-time}
       \href{https://en.wikipedia.org/wiki/Real-time_clock}{real-time
         clock} chip is cheap, but in most IoT consumer devices
       (typically routers or printers) it is not useful enough, since
       they are often connected to some distant
       \index{ntp@\textsc{NTP} - network time protocol}
       \href{https://en.wikipedia.org/wiki/Ntpd}{\textsc{NTPd}
         service}

       \item synchronization bugs related to multi-threading or
         concurrent systems, e.g. with \textsc{Posix threads}, See
         \cite{goubault:2005:practical, sangiorgi:2003:pi,
           david:2013:everything,
           guerraoui:2018:concurrent-systems}. Concurrency is also a
         concern of client-server architectures, including
         \href{https://en.wikipedia.org/wiki/Web_service}{Web
           services} \index{web service} using
         \href{https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol}{HTTP}
         \index{http@\emph{HTTP} (web protocol)},
         \href{https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol}{SMTP}
         \index{smtp@\emph{SMTP} (mail sending protocol)},
         \href{https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol}{IMAP}
         \index{imap@\emph{IMAP} (email retrieval protocol)}
         \index{email} (perhaps mixed with
         \href{https://en.wikipedia.org/wiki/Transport_Layer_Security}{TLS}
         \index{tls@\emph{TLS} cryptographic protocol}
         \index{cryptographic protocol}).
         
 \end{itemize}

 Pragmatically good reasons to avoid testing such error conditions
 \index{error condition} include: 1. cost of additional development
 efforts for extra C code which is difficult to test in a reproducible
 way \index{test} \index{fault injection} \index{reproducing!faults}
 without fault injections; 2. scarse code memory space \index{code}
 \index{memory!code} (e.g. in some read-only memory) \index{read-only
   memory} on cheap devices.

 Please notice that above error conditions are related: for example, a
 loss of time may corrupt an entire file system,
 \index{corruption!file system} and timing information (or meta-data)
 \index{timing} \index{meta-data} is quite often kept and needed in
 small \href{http://sqlite.org/}{\textsc{Sqlite} databases}.
 \index{sqlite@\textsc{Sqlite} database library}. The remote backup
 \index{database} \index{remote backup} \index{backup!remote} of such
 small or large databases (see \cite{Date:2005:Database-in-Depth,
   kornacker:2015:impala}) could happen on a periodical basis (see
 \href{https://man7.org/linux/man-pages/man5/crontab.5.html}{\texttt{crontab(5)}}
 and \index{crontab@\texttt{crontab(5)}}
 \index{rsync@\texttt{rsync(1)}}
 \href{https://man7.org/linux/man-pages/man1/rsync.1.html}{\texttt{rsync(1)}}
 for
 more). \href{https://softwareengineering.stackexchange.com/a/332071/40065}{Large}
 relational databases are practically needed for most machine learning
 \index{machine learning} algorithms (see
 \cite{flach:2012:machine-learning}), which are usually concurrent
 \index{concurrency} programs. So a non-critical machine-learning
 distributed IoT system would probably be made of cheap IoT devices
 communicating with some powerful, semi-centralized, database
 \index{weather prediction} \index{meteorological!computing grids}
 \index{computing grids} servers. Current meteorological computing
 grids for
 \href{https://en.wikipedia.org/wiki/Numerical_weather_prediction}{numerical
   weather prediction} operated by national meteorological services
 such as \href{http://meteofrance.com/}{Météo-France} require such
 continent-wide IoT networks, and so does \index{forecast!avalanche}
 \index{avalanche} avalanche detection and forecasting in European
 \index{smart cities} \index{city!smart} \index{grid!smart}
 \index{power!grid}
 mountains. \href{https://en.wikipedia.org/wiki/Smart_city}{Smart
   cities} networks and
 \href{https://en.wikipedia.org/wiki/Smart_grid}{smart grids} (see
 \cite{belarbi:2004:vehicle, mclaren:2015:sharing,
   delons:2008:pirandello, bakken:2014:smart-grids} and
 \index{\textsc{Grid4eu} project} the
 \href{https://www.enedis.fr/grid4eu}{\textsc{Grid4Eu} project}) also
 need a large grid of many communicating IoT devices.

 In \emph{some} even critical IoT devices (e.g. medical devices
 \index{medical device} such \index{Covid-19@\textsc{Covid 19}
   illness} as a \href{https://github.com/Recovid/}{Covid-19 breathing
   ventilator}), losing power or time for a few seconds is acceptable,
 as long as there is some hardware alarm (e.g. electronic bell)
 informing professional users (e.g. medical nurses).

 Most non-critical IoT devices could \emph{sometimes} access by the
 network a remote database \index{database} \index{remote!database},
 such as some \href{https://www.postgresql.org/}{\textsc{PostGreSQL}
   server}, or some \href{https://www.mongodb.com/}{\textsc{MongoDB}
   document database}. Losing the connection to such a remote database
 is generally affordable, if the connection loss don't last too
 long. On the other hand, a posteriori adding database checkpoint
 \index{checkpointing!application} \index{scientific code} \index{oil
   industry} \index{automotive crash} \index{super-compuiters}
 \index{code refactoring} \index{refactoring!code}
 \index{code!scientific} \index{code!refactoring} facilities to some
 existing large long-running scientific code (think of oil industry
 simulation software, or digital twins for automotive crash
 \index{simulation software} \index{twins!digital} simulations, both
 running for months of super computer time) requires some significant
 development efforts or code refactoring. Of course European particle
 accelerators such as
 \href{https://home.cern/science/accelerators/}{CERN \textsc{Elena} or
   \textsc{Lhc} installations} are deploying wide networks of
 heterogenous IoT devices, but probably can afford partial failure of
 some of them. Cyber-attacks on smart grids
 (e.g. \cite{lee:2016:analysis-cyberattack}) could justify an increase
 of European research funding on long-term mixed static analysis and
 dynamic machine learning based techniques, but require funding of
 projects with a time span above three years and involving tight
 cooperation thru open source projects (see \cite{Brooks:1995:MM,
   Lerner-Tirole:2000:economics-open-source,
   Tirole:2018:eco-bien-commun, hashem:2015:rise}). See also the related
 \index{softwareheritage@\textsc{SoftwareHeritage} project}
 \href{https://www.softwareheritage.org/}{\textsc{SoftwareHeritage}}
 project. See
 \href{https://en.wikipedia.org/wiki/Brooks's_law}{Brook's law} and
 observation -in 1975- that ``while it takes one woman nine months to
 make one baby, "nine women can't make a baby in one month"'' (to be
 scaled in 2020 by a factor of 10x and generalized to software
 developers of both genders, given the complexity of current software
 intensive systems).

 Notice that exact static prediction of call stack depth is in
 practice impossible, because of
 \href{https://en.wikipedia.org/wiki/Rice's_theorem}{Rice's theorem}
 \index{rice@Rice's theorem} -and usage in C code of the
 \href{https://man7.org/linux/man-pages/man3/alloca.3.html}{\texttt{alloca(3)}}
 stack allocation primitive, or of
 \href{https://en.wikipedia.org/wiki/Variable-length_array}{variable-length
   arrays} - and since compilers may put automatic variables in
 \index{asm@\texttt{asm} keyword} processor registers. For C or C++
 compilers handling the \texttt{asm} keyword (in recent \textsc{Gcc}
 compilers, it provides even
 \href{https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html}{powerful
   language extensions} to C or C++), register allocation becomes a
 nightmare for the compiler writer, since the \texttt{register}
 \index{register@\texttt{register} keyword} keyword tend to become
 obsolete or ill-defined \index{volatile@\texttt{volatile} keyword}
 (like the \texttt{volatile} one). So it is strongly tied to the
 \href{https://en.wikipedia.org/wiki/Register_allocation}{register
   allocation} issue, which is a difficult sub-problem inside most
 optimizing compilers (see \cite{eisl:2016:traceregalloc,
   Chaitin:1981:regalloc, Aho:2006:DragonBook}).  \index{register
   allocation} \index{alloca@\texttt{alloca} stack-allocation
   primitive}. In recent C++ language dialects, the \texttt{auto} and
 \index{auto@\texttt{auto} keyword} \index{decltype@\texttt{decltype}
   keyword} \texttt{decltype} keywords are enabling some \emph{type
 inference} \index{type inference} (see \cite{pierce:2002:types,
   Stroustrup:2014:CplusPlus, Stroustrup:2020:thriving,
   CplusPlus11:std}). In practice, industrial compilers don't even try
 to find the best register allocation possible, but just a good enough
 one (otherwise compilation time could be prohibitive). Be aware that
 \href{https://en.wikipedia.org/wiki/Flexible_array_member}{flexible
   array members} are also a C language feature, which, combined with
 \index{cast!pointer} \index{union@\texttt{union}} pointer casts (or
 equivalently used in \texttt{union} of pointers), permit compilers to
 do arbitrarily sophisticated optimizations.
 
\bigskip


%Additional content of this \S\ref{subsec:analysiot} will be written for the final D1.3\textsuperscript{v2}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Local Variables: ;;
%% compile-command: "cd ..; ./build-bismon-doc.sh" ;;
%% End: ;;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
