Multics 2nd Generation (Multics^2):

Lehman and Belady have studied the history of successive releases in
a large operating system. They find that the total number of
modules increases linearly with release number, but that the number
of modules affected increases exponentially with release number.
All repairs tend to destroy the structure, to increase the entropy
and disorder of the system. Less and less effort is spent on fixing
original design flaws; more and more is spent on fixing flaws
introduced by earlier fixes. As time passes, the system becomes
less and less well-ordered. Sooner or later the fixing ceases to
gain any ground. Each forward step is matched by a backward one.
Although in principle usable forever, the system has worn out as a
base for progress. Furthermore, machines change, configurations
change, and user requirements change, so the system is not in fact
usable forever. A brand-new, from-the-ground-up redesign is
necessary.

-- Fred Brooks, "The Mythical Man-Month", about IBM OS/360
(but it may as well be applied to Unix too, and perhaps even the
original Multics)

We Unix people have been deceived, and are deceiving ourselves in the
worst way possible for all too long a time. One of our core
philosophies is backwards / inside out / upside down / flat-out wrong:

In unix it's not really true that "everything is a file".

Rather it is that "everything is an I/O channel, even including
files"

We may as well still be computing with all our data accessed via
magnetic tape!

In Multics the filesystem is merely a logical map of all memory segments
stored in the system, each of which may be mapped into a process'
address space (assuming appropriate access rights). Meanwhile real I/O
in Multics is done via a unified, universal, streams-oriented, and
hardware-independent, interface that even works transparently with files
as the "device". Multics even allows easy interchange of devices while
programs are executing.

In Unix everything is a file descriptor (but a file descriptor is not
necessarily a file, especially not for sockets and pipes),
i.e. everything (except memory) in Unix is I/O, even files. Files must
be accessed as if they are I/O streams (though they are seek-able, so
somewhat randomly accessible, but that the extreme cost of extra system
calls and far more complex algorithms). Unix file I/O is no better than
ancient magnetic tape storage, at least w.r.t. algorithm design. (I'm
ignoring mmap() because it is far too hobbled to be truly useful as a
proper replacement for file access via I/O streams.)

Of course in Multics everything is also a file(name), effectively, since
files are just segments (the I/O subsystem plays tricks with names that
could easily be bound into the same namespaces as data files, though at
the time that didn't seem so important in the Multics world). However
in Multics the data in a file is just more address space: data is
directly addressable and thus randomly accessible, and it appears on
demand in the process address space without any thought as to where it
was stored. We only think in terms of linear streams of data in Multics
when we are forced to communicate with the world outside the process
execution space. But that's OK because it doesn't limit what the
underlying communications hardware can do, and it fits exactly with the
paradigms implied by the underlying hardware and how it links to the
outside world. Trying to think of a serial port as an array of data can
get you into trouble and it leaves out some extremely critical concepts
about the very nature of communications. (Hmmmm.... this probably means
Multics with DMA hardware could be made more secure too!)

Paging vs. Segments

The purpose of paging is to make the allocation of physical memory
easier. One may think of paging as the intermediate ground between a
fully associative memory, having each word addressed by means of some
part of its contents, and a normal memory, having each memory location
addressed by a specific integer forever fixed to that physical location.
In paging, blocks of memory are assigned differing base addresses.
Addressing within a block is relative to the beginning of the block.
Thus if association and relative addressing are handled with a break
occurring within a normal break of the word (viz. in a binary machine
block size is a power of 2), then a number of noncontiguous blocks of
memory can be made to look contiguous through proper association. The
association between a block and a specific base address can be
dynamically changed by program during the execution of appropriate parts
of the executive routine.

Segments are used not for the allocation of physical memory, but for the
allocation of address space. A segment defines some object such as a
data area, a procedure (program) or the like. In a sense, each segment
corresponds to a part of virtual memory whose size is whatever size, up
to a maximum limit, that is required for its content and which can
expand or contract as that size changes. In theory, as many such
segments can be available to a programmer as necessary. Observe that
although segments and pages are two distinctly different entities, they
work together to facilitate the allocation of physical memory and
virtual memory. Although a large number of segments may be defined,
each one having a large number of words, only the currently referenced
pages of pertinent segments need to be loaded in physical memory at any
time.

(The above section is paraphrased from "System Design of a Computer for
Time Sharing Applications" by E. L. Glaser, J. F. Couleur, and
G. A. Oliver. This paper gives a good abstract overview of the rational
and design of the "extension" features required to support Multics on
the GE-635 -- i.e. the creation of the GE-645.)

Multics securty: The 1970's is the 2020's

The high-assurance, military security, mainframe oriented model of the
Orange Book is oriented toward the problems of the 1970's. One can
assume that Multics systems ran on trusted hardware that was maintained
and administered by trained and trusted people. Users didn't buy
graphics cards on Canal Street and plug them into the mainframe. In
many ways, the security design of Multics-based systems pushed a lot of
hard-to-solve issues off onto Operations and Field Engineering. Multics
hardware originated from a trusted manufacturer and was shipped on
trusted trucks, installed by trusted FEs, and kept in a locked room.

(above paraphrased from http://www.multicians.org/b2.html, "4.5
Relevance to current and future security needs")

Well what do you know! Those same needs and assumptions can be applied
to modern Internet SaaS platforms.

Multics and its security as a precursor and model for "cloud computing"

In terms of past examples, the substantial Multics efforts over
a number of years by Honeywell (initially General Electric) is
one of the few. Decades in advance of widespread commercial
need Multics addressed the challenge of creating a "computing
utility" for which security was a central value proposition.
Many decades later essentially this vision has been given the
new name of "cloud computing" â€“ unfortunately without
significant attention to security.

https://intelligence.org/2014/06/23/roger-schell/

Original Multics Goals:

- Avoid multiple copies of the same information in memory

- Avoid copying or processing each word of memory repeatedly

- Control sharing at the segment level

- Link subroutines incrementally on demand

- Support symmetric shared-memory multiprocessing

- Support programming in multiple languages

Multics^2 should have:

* Single Level Store with a hierarchical filesystem.

- Einstein inspired Peter G. Neumann to think in terms of hierarchical
systems, which in turn begat the Multics filesystem, and thus Unix
and all subsequent similar hierarchical filesystems.

- block/page level de-duplication with copy-on-write semantics for all
file copies

- memory segments are files and vice-versa -- one-to-one with only a
hackish streams-based method for accessing segments as an I/O stream
for external "serial" communications (and perhaps the benefit of
silly old POSIX-compatibility).

- All information stored in memory must be directly addressable by any
process. I.e. everything that is "just" data, should be accessed
directly via pointers into memory. Only interfaces where data must
be serialized for some reason, e.g. network communications, ttys,
etc. should be done via some I/O stream mechanism.

- Access control can be performed at each reference to memory, or at
least at each mapping of a page of memory.

- abstractions such as buffering in STDIO are pure overhead!

* Extensions to C that work similar to the old extensions to PL/1 for
multics? Or just stick to pointers? We already depend almost
entirely on malloc() and mmap() which return bounded regions, and we
even expect that if we have to grow them that they may move.

* also possibly offer a tagged, search-based filesystem overlay

- http://eecs.harvard.edu/margo/papers/hotos09/paper.pdf

* natural dynamic linking with a search path handled by the link(call)
trap handler, and pure shareable compiled code (i.e. no modification
of code segments is allowed or required).

* ability for ALL programs to make all non-basic dynamically linked
libraries and "frameworks" entirely optional! The most basic
functionality MUST NOT require installing all possible bloatware that
a program might want to use to implement all of its options.

* designed for real-world general purpose use, as well as for research

- fully POSIX-compatible runtime emulation with fread() and fwrite()
being effectively memcpy().

* in general it should try to fix or avoid all the "stupid" things in
various systems APIs

In general the purpose is not to be a research OS, but rather to be a
re-implementation of ideas that have fallen by the wayside.

BTW, Chris offers a good discussion of what "success" means for a
research OS:

https://utcc.utoronto.ca/~cks/space/blog/tech/SuccessForResearchOSes

Ideas:

In many ways Multics^2 is very similar to The Amber Operating System:

http://www.mit.edu/~cbf/thesis.htm

Transform Xen into, or otherwise use a hypervisor to implement, Multics^2

- idea from MirageOS (http://queue.acm.org/detail.cfm?id=2566628)

- maybe each process is a whole virtual machine

- you run either a small runtime, or a whole user-dedicated OS, in
each VM

- threads are always virtual-CPUs in the VM?

- use unix-like job control to have multiple threads running in one
process?

- the hypervisor implements an emulation of segments for a slightly
enhanced virtual-CPU+MMU even if the underlying CPU doesn't do
segments

- this is, perhaps unfortunately, much more in keeping with the
heavy-weight nature of the original Multics processes, though if
multiple vCPUs can be assigned to each domain then threading is
available and good inter-thread communications, e.g. like
goroutines and channels, could ease the pressure on having
multiple processes for a given task.

- See also EthOS:

http://www.ethos-os.org/
https://www.cs.uic.edu/~spopuri/ethos.html

Or maybe just use hypervisor technology to implement rings?

On the other hand Jonathan Shapiro said:

"The idea of adapting paravirtualization to a microkernel for
use within an operating system is, frankly, silly. Several
existing microkernels, including L4.sec (though not L3 or L4),
KeyKOS, EROS, Coyotos, and CapROS, have isolation and
communication mechanisms that are already better suited to this
task."

http://www.coyotos.org/docs/misc/linus-rebuttal.html

- but then Shapiro isn't known for being open-minded about some OS
concepts. :-)

Rings have a huge advantage when there's hardware ring protection:

Multics can do a direct procedure call to a higher privilege
level, with the full generality of high-level language argument
passing, without taking a trap or invoking mediation code. The
return from higher privilege (lower ring) to lower privilege
(higher ring) is also direct.

- the kernel code is directly shared with all processes, i.e. kernel
code segments are mapped into the address space of each process --
just another segment, or several.

- A process can call kernel functions directly using normal function
call mechanisms -- there are no "system calls" as in the unix sense.

For a practical experiment a 64-bit address space should suffice, even
if rings are in software (though we would need multi-segment files):

2 bits ring #
30 bits segment #
32 bits segment address

(are there any modern large-scale data apps that expect more than
32-bits of address space for individual arrays? yes, but not many)

If we want to avoid multi-segment files and we can do rings in hardware:

24 bits segment # (16 million segments per process)
40 bits segment address (1,099,511,627,776, 1 terabyte)

or even:

4 bits ring #
20 bits segment # (1 million segments per process)
40 bits segment address (1,099,511,627,776, 1 terabyte)

or:

2 bits ring #
22 bits segment # (4 million segments per process)
40 bits segment address (1,099,511,627,776, 1 terabyte)

We can also split the address space into regions using "flag" bits in
pointers, and thus also avoid needing multi-segment files at the same
time!:

Highest bit 63: 0 = regular address, 1 = memory mapped files
(i.e. is this a "segment" address?)

next highest 62: very large files (or just if any one of
the VLF# bits is non-zero -- requires
masking and testing for non-zero as
opposed to testing just one bit)

next 8 bits 54-61: VLF file number (256 very large files open)
2^52 byte max (4,503,599,627,370,496) 4 petabyte

next 21 bits 33-53 regular file numbers (1,048,576 files)
2^32 byte max (4,294,967,296) 4 gigabyte

1 2 3 4 5 6
0123456789 123456789 123456789 123456789 123456789 123456789 123
R V VF
E L LI
G F FL
# # ?E
?

Mask off the flags and file number and you have the index (offset).

Take 2 bits from the regular file numbers to do rings in software.

Get rid of ordinary file descriptors, have open(2) return a pointer ala
mmap(), and have socket(2) be the only call that returns a file
descriptor.

So, how do we do dynamic linking with this scheme?

Notes about 80386:

I've been doing an awful lot of reading and research about Multics again
recently, including looking at the x86 segmentation and protection model
in view of how it could work for Multics.

So far as I can tell IA-32 is more or less _exactly_ what is needed for
Multics, or a Multics-like system, with some possible limitations.

A virtual address consists of a 16-bit (13+1 are address bits)
segment selector and a 32-bit segment offset. The selector is used
to fetch a segment descriptor from a table (actually, there are two
tables and so the "plus one" of the bits of the selector is used to
choose which table) (and the other two bits are the Requested
Privilege Level). The 64-bit descriptor itself contains the 32-bit
address of the segment (called the segment base) 21 bits indicating
its length, and miscellaneous bits indicating protections and other
options. The segment length is indicated by a 20-bit limit and one
bit to indicate whether the limit should be interpreted as bytes or
pages. (The segment base and limit "fields" are actually scattered
around the descriptor to provide compatibility with earlier version
of the hardware.) If the offset from the original virtual address
does not exceed the segment length, it is added to the base to get a
"physical" address called the linear address. If paging is turned
off, the linear address really is the physical address. Otherwise,
it is translated by a two-level page table as described previously,
with the 32-bit address divided into two 10-bit page numbers and a
12 bit offset (a page is 4KB).

Warning: Apparently the Atom processors have very sucky performance,
especially when using non-zero-based code segments.

The main addressing limitation in 32-bit x86 is the relatively small
13-bit segment index held in the segment registers. With the two
possible descriptor tables that gives an absolute maximum of 2^14-1
segments per process, though practically I'd guess the GDT is only
useful for code segments and possibly a very few truly globally needed
file segments, so that leaves just 8192 segments for stack, data, and
general file access by each process. That's still twice what the
practical limit was for packed pointers on the old Honeywell 6180, and
4-8 times the average number of open file descriptors permitted in the
average modern unix-like system, so perhaps it's not really an important
limit. Perhaps there's some convenient way for a process to switch
LDT's on demand too. Also, it's between 2 and 8 times the number of
open file descriptors generally limited to by modern Unix systems.

Obviously the x86 only has 4 rings, but I don't currently see that as a
problem.

I think all x86-64 implementations still have full compatibility modes
for x86 (IA-32, i.e. 32-bit) protected mode addressing with full
segmented addressing and paged segments. They pretty much have to in
order to run all 32-bit software. (FYI, the FS and GS registers retain
their use as segment descriptor table indexes even in 64-bit mode
(i.e. they can still have non-zero base addresses), but without any real
protection features, I think.)

Paul Green's Multics VM paper suggests another, possibly more efficient,
way to avoid multi-segment files:

Concatenating segments would be simple if incrementing the word
offset past the last word carried into the segment number. You
wouldn't want this by default, but with a bit in the SDW you could
control which segments were concatenated and which were not.

So, can we modify x86 segmentation to allow concatenated segments? This
would allow direct, trivial, access to files larger than 4GB without
having to re-invent multi-segment files again. There should still be a
bit available in a segment descriptor to indicate that it is to be
concatenated with the following descriptor. Getting pointer arithmetic
to work right might be tricky though.

- "segment" registers point into a segment descriptor table (SDT):

2 bits ring # (requestor's privilege level)
1 bit segment descriptor table indicator (global vs. local)
13 bits segment descriptor index (8192 segments per SDT)

32 bits segment address (offset)

- segment descriptors (SDT entries, or SDWs in Multics parlance):

16 bit segment limit (in either bytes or 4k pages, 4GB max)

- can a process reload its own LSDT without a ring#0 call?

Ideally though the x86_64 would have segmentation re-enabled, thus
doubling the size of index registers and hopefully also doubling the
size of segment selector registers (though maybe not increasing the
descriptor table size by the same power of two -- other flag bits might
be useful in the visible part of segment selector registers), and of
course adding at least 4 more bytes (but ideally doubling) the size of
segment descriptors.

IA-32 TSS:

- dynacube OS uses just two TSS segments in the GDT:

http://dynacube.net/

Note about Honeywell 6180 limits:

- in practice packed pointers were used with a limit of 4096 segments
per process.

Other CPUs:

CHERI

Memory Segmentation to Support Secure Applications

"A segment mechanism that implements the capability model of safe,
programmatic memory protection"

http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf

"CHERI can do anything Multics could do: segmentation, paging,
dynamic linking, ring-structured software"

-- Peter G. Neumann in "An Interview with..." by Rick Farrow in
;login:, Winter 2017 vol. 42, no. 4

More about "Capabilities"

Capability-Based Computer Systems Henry M. Levy This book was
published by Digital Press in 1984. It is still the most
thorough survey and description of early capability-based and
object-based hardware and software systems. The book is now out
of print and the copyright belongs to the author, who makes the
material available here for viewing or downloading, in Adobe
Acrobat PDF format:

https://homes.cs.washington.edu/~levy/capabook/

- see also Plessey System 250

- capabilities vs. access control lists:

J. H. Saltzer and M. D. Schroeder. 1975. The protection of
information in computer systems. Proceedings of the IEEE 63, 9 (
Sept. 1975), 1278â€“1308.

They thought revocation of access was one of the major area where
capabilities fell short.

In segmentation and with the introduction of "generation"
numbers in the segment table revocation is simply a matter of
incrementing the generation number.

See also

"Using segmentation to build a capability-based single address
space operating system", Wuyang Chung <wy-chung@outlook.com>

https://www.bsdcan.org/events/bsdcan_2023/sessions/session/129/slides/50/slides.pdf

Mill

https://millcomputing.com/

I'm also extremely interested in exploring what hypervisor support in
modern x86 CPUs might bring to the table in terms of building a new
Multics-like system. What if each process is a virtual machine or maybe
even an LPAR (but with overlapping memory, of course)? Virtual CPUs as
threads?

I think the PowerPC might work too (with software rings?), and I'm also
interested in seeing how difficult it might be to add segmentation and
ring "hardware" to an ARM, SPARC, or MIPS architecture, perhaps as an
experiment in an FPGA implementation. There's also a patent I found
about emulating segment bounds checking in a simpler RISC-style MMU:
https://www.google.com/patents/US5652872

For now IS IT possible to just do segment + offset calculations manually
on non-segmented architectures?

- how might CPU support features for a hypervisor help?

- does an MMU help emulate segments?

- segments as pages?

How did the S-1 support a variable boundary between the segment number
and the offset? (S-1 segments could take up the whole address space of
the system, apparently.)

Here's a linux extension that provided multiple global address space
mappings for files via mmap():

Srinivas Palnati, Gautam Barua, "Persistent Storage for 64-bit
Systems", International Conference on Information Technology
(CIT-2001), Gopalpur-on-the-sea, India, December 20-22, 2001.

Is there any performance advantage to loading a whole library in one
segment (when there are no adverse security implications?). Otherwise
every independent function gets its own segment (we would still have a
billion to play with on a 64-bit address even with 2-bits reserved for
rings!).

- probably yes -- at least for when the library calls lots of other
members of itself, since then internal calls won't need fixups on
the initial invocation.

MMU Paging systems can be used to implement segments. From the Amber
paper[1]:

Architectures that have the necessary hardware for demand paging
and a large address space (VAX and IBM 370 with Extended
Addressing option) can still use the techniques of segmentation
by allocating contiguous ranges of pages to represent a segment.
They will not however, have the feature of trapping references
that overflow a segments boundaries that the Multics and S-1
hardware provide. This feature is primarily a debugging aid,
but it can be an important one.

however there are problems with only having page tables:

On a segmented machine like Multics, the S-1, or the Prime 500
series, access to a segment is determined from bits in a user's
segment descriptor word. On a paged system each page table word
has access bits. (The access we are referring to here is read,
execute, or write to an area of main memory. The S-1 actually
has bits in both the segment and the page table words and it
and's them together to determine effective access.) This
unfortunately means that two users who have the same segment
mapped in with different access rights cannot share the same
page table.

Files vs. I/O -- everything is a file (descriptor) vs. SingleLevelStore

File systems have (at least) two undesirable characteristics:
both the addressing model and the consistency semantics differ
from those of memory, leading to a change in programming model
at the storage boundary. Main memory is a single flat space of
pages with a simple durability (persistence) model: all or
nothing. File content durability is a complex function of
implementation, caching, and timing. Memory is globally
consistent. File systems offer no global consistency model.
Following a crash recovery, individual files may be lost or
damaged, or may be collectively inconsistent even though they
are individually sound.

from the abstract of:
"Design Evolution of the EROS Single-Level Store"
by: Jonathan Shapiro, Jonathan Adams

Issues with using memory as storage, at least with respect to MMAP:

- note that with a Single Level Store all views of the data are
implicitly guaranteed to be unified.

- a system all similar to msync(2) could be used to "secure" (flush) all
writes to a segment, thus careful use of it (like a mutex of sorts),
combined with some effect of something akin to mlockall(2) to
guarantee that no writes happen until the msync() call, could
guarantee write order to secondary storage, though of course efficiecy
here requires that writing of a whole page is as efficient as writing
some small part of the page (normally the case if I/O is done with DMA
transfers I think) [[ how could this be made more transparent? --
perhaps by providing a write(2) like interface? ]]

- it is hard to escape from point #3, though presumably that's algorithm
dependent.

- similarly point #2, but that is in part a language problem.

From: Howard Chu via Cyrus-devel <cyrus-devel@lists.andrew.cmu.edu>
To: Cyrus Devel <cyrus-devel@lists.andrew.cmu.edu>
Message-ID: <1c46d2af-c16f-aeb3-9e32-291d3ac4e216@highlandsun.com>
Date: Fri, 30 Nov 2018 11:09:23 +0000

I've covered the reasons for/against writing thru mmap in my
LMDB design papers. I don't know how relevant all of these are
for your use case:

1. writing thru mmap loses any control over write ordering - the
OS will page dirty pages out in arbitrary order.

If you're using a filesystem that supports ordered writes, it
will preserve the ordering of data from write() calls.

2. making the mmap writable opens the possibility of
undetectable data structure corruption if any other code is
doing stray writes through arbitrary pointers. You need to
be very sure your code is bug-free.

3. if your DB is larger than RAM, writing thru mmap is slower
than using write() syscalls. Whenever you access a page for
the first time, the OS will page it in. This is a wasted I/O
if all you're doing is overwriting the page with new data.

4. you can't use mmap exclusively, if you need to grow the
output file. You can only write thru the mapping to pages
that already exist. If you need to grow the file, you must
preallocate the space, otherwise you get a SEGV when
referencing unallocated pages.

And a side note, multiple studies have shown that skiplists are
not cache-friendly, and thus have inferior performance to B+tree
organizations. A skiplist is a very poor choice for a read/write
data structure.

Obviously I would recommend you use something carefully designed
and heavily tested, like LMDB, instead of whatever you're using.

There's one point in favor of writing thru mmap - if you take
care of all the other potential gotchas, it will work on every
OS that implements mmap. Using mmap for reads, and syscalls for
writes, is only valid on OSs with a unified buffer cache. While
this isn't a problem on most modern OSs, OpenBSD is a notable
example of an OS that lacks this, and so that approach always
results in file corruption there.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

- Bron replied to say:

This is not a concern at all - twoskip is deliberately designed
such that it does a single write and then flush to "dirty" the
file, all changes made while dirty are fully revertable if it
crashes, and then it does a fsync (msync now I guess!) before a
single write which clears the dirty flag. So long as a single
256 byte write is consistent, it's safe.

hardware transactional memory

https://dl.acm.org/citation.cfm?id=2618405
https://fsgeek.ca/2018/04/27/the-future-of-synchronization-on-multicores-the-mulitcore-transformation/

Security

What are the modern threats to a Multics-like system that are different
from what it faced originally? How should it deal with bugs in programs
responsible for the interpretation of structured content such as
graphics (HTML, etc., etc., etc.)

- security sensitive processes could be prevented from mapping in new
code segments just before they start running (and of course it is an
error to try to jump to a data (or stack) segment, and the stack(s)
and heap segment(s) do not share the same address(offset) space).

- separate processes for separate functional purposes, e.g. browser in
one, mail in another, DBs each in their own, compiler is run in its
own, etc. Each network server in its own, etc. Even an editor like
Emacs could run in its own process.

How to deal with the administration issue -- i.e. how much sysadmin can
be automated to the degree that a non-expert can own and run a machine?

Jonathan S. Shapiro argues against segments in:

http://seclists.org/risks/2014/q2/1

How distributed can it all be?

- e.g.: like Apollo Domain/OS and/or Amoeba

- full virtual cloud for all computing devices?

- any computer can join the cloud, local resources can be shared or
private, some other resources (filesystem and CPU, etc.) can be
"more trusted" than the whole cloud.

- use something like Apple's security processor to make one device the
only thing that can decrypt some segments

- additionally be able to store keys into it to allow identities to
share devices, migrate between devices, make devices "disposable"

What to write it all in?

- some "safe" C? with modules

- see ~notes/C

- why not plain C? "Undefined behaviour". It is a thing "defined" for
C, for one:

... we have C compiler maintainers who assert that any behavior not
defined in the C standard is not something where they have to pick
one behavior and stick with it, but can instead declare it an
impossible situation, that code which relies upon common assumptions
is [therefore] buggy, and proceed to optimize away the security checks.

If I program in C, I need to defend against the compiler maintainers.
If I program in Go, the language maintainers defend me from my mistakes.

Phil Pennock
https://bridge.grumpy-troll.org/2017/04/golang-ssh-radix/

A better language would not define anything as "undefined behaviour", ever!

So, not Standard C as defined by modern standards.

- Hare, https://harelang.org/

- "Hare definitely does not have is the same kind of 'undefined
behavior' that C compilers use as a license to do whatever they want
to your program"

- "all strings are always valid UTF-8. We also store the length
alongside the string, allowing NUL to appear in the string contents,
and for len(str) to be an O(1) operation."

- can be useful everywhere C is useful, BUT...

- it lacks multithreading in the standard library

- Go, with extensions and a different runtime?

- can a Go-like language automatically and reliably detect when, e.g.,
features are used which might depend on a hosted runtime (as opposed
to the bare metal runtime), e.g. garbage collection.

- see GO-OSe and bootgo

https://github.com/boomshroom/goose
https://github.com/jjyr/bootgo

- V https://vlang.io/ https://github.com/vlang/v

- hmmm.... this V language is very simple, much like Go, but without
(currently) a garbage collector -- cleanup is done dynamically when
functions return, etc.

V is a statically typed compiled programming language designed
for building maintainable software.

It's similar to Go and is also influenced by Oberon, Rust, Swift.

- Has enums! (and even generics!)

- super-safe:

- No undefined values
- No undefined behavior
- Bounds checking

There's no garbage collection or reference counting. V cleans
everything up during compilation. If your V program compiles,
it's guaranteed that it's going to be leak free.

- there's a C to V translator and C interoperability is easy

- claims compiled binaries have no dependencies (but don't seem to be
static-linked -- they're too small, for one)

- currently implements concurrency with system threads, but claims to
be adding a coroutines and a scheduler

- "V"ery interesting! Extremely good candidate!

- possible drawbacks: difficult to manage pointers?

- there's also Jai: imperative static/strongly typed C-style language
by Jonathan Loom

https://inductive.no/jai/
https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

No implicit type conversions
No header files
Jai code can be built on top of existing C libraries

- need to know more about its runtime

- Nim

https://nim-lang.org/

- it's a bit/very annoyingly python-like in look

- it has no runtime compiler library -- executables are stand-alone!

* Nim generates native dependency-free executables, not dependent on
a virtual machine, which are small and allow easy redistribution.

* Fast deferred reference counting memory management that supports
real-time systems.

* Nim is self-contained: the compiler and the standard library are
implemented in Nim.

- Zig -- http://ziglang.org/ (by Andrew Kelley)

ready and running, apparently. BUT oh, gawd -- it's currently written
in C++ and requires CMake to build the compiler (because it is a thin
front-end to LLVM) (though apparently comes with its own built-in
build system so that Zig programs don't need anything like CMake,
etc.)

BUT, this may be changing (divorce from LLVM):

https://kristoff.it/blog/zig-new-relationship-llvm/