[SGVLUG] "Survival At C" Discussion Thread

[Dustin Laurence]

On 06/10/2016 03:52 PM, Jess Bermudes wrote:

> Dustin: For posterity, do you have the slides available online or at
> least the link to the github repo?

I was thinking of putting them on my Linkedin profile.  They could go on
the SGVLUG website if someone wants to put them there.

I thought about creating a repo for that talk, anticipating that the
next time I'd be able to produce some examples.  That would also be a
good place for the slides.

> ...Additionally, are there any books or
> sources for more reading of a fuller exposition/example of the
> principles you outlined in the talk for those that want to see how it
> works in practice?

You know, I probably don't for most of it.  It's hard to say what I
remember subconsciously from forgotten sources, but some of it may be
original with me (at least in formalization and presentation).  Lemme
see what I can remember.

I don't think I have a reference for all the low-cost simple object
model tricks I outlined nor for the somewhat interface-oriented way I
presented them.  21st Century C may have them, but I think he rapidly
gets more fancy so trying to collect up tricks that work with the
simplest model may be somewhat original with me.  Searches for "Object
Oriented C" will tend to find much more involved schemes involving
implementing dispatch and inheritance (or maybe interfaces, but
unfortunately all the schemes I've seen follow the older interpretation
of OOP).

I know I was writing C that way by maybe 1990 or so, and I can't say
where I got it back then.  I often try to do things the Landau way (very
obscure reference) and work out details based just on a bare idea from
someone else, so perhaps I re-invented some of it.  Some of the tricks
probably came from me trying to avoid having to actually implement
dispatch and inheritance.

For more full-featured OO-C, there is some discussion in "21st Century
C," and there are many other object models people have used.  It would
be a lot of fun to survey, test, and critique as many object schemes as
can be found and try to determine if any stand out.  Even though in
practice I advocate using no more such tricks than necessary, it would
be nice to know what the best option is when your back is to the wall.

For Sole Ownership memory handling, all the ideas are fairly explicit in
the C++ community and automated and enforced in Rust (which is in many
ways an automation of certain C++ best practices).  That particular
codification and the application to C is my own, if I ever saw a formal
list of what precisely owners and borrowers can do I don't remember it.

I *think* the C exception handling pattern is more or less ripped off
the Linux kernel code, though again I think I saw a rough description
and worked out the details, and then polished by what I've seen done in
various codebases.  Again I suspect the quasi-formalization and naming
is mine.  Similar remarks for the C error reporting pattern, though
certainly variant 2 came from an argument by Steve McConnell as to the
superiority of error parameters over error returns.

Speaking of McConnell, _Code Complete_ was a big influence on me back in
grad school, so that would be a good place to look for source material
I've internalized and now think is mine.

> And coincidentally for the JPL crowd, a copy of the standards used by
> JPL for specifically flight software was posted on reddit today and it
> appears to be based on MISRA 2004 and explicitly forbids any use of
> gotos but does seem to mention some of the ownership stuff discussed
> last night:
> 
> http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Hey, thanks!  I wish I'd found that when I wrote my secure coding seminar.

The Joint Strike Fighter C++ coding standards are here:

http://www.stroustrup.com/JSF-AV-rules.pdf

It has somewhat similar aims for C++ and was written by Stroustrup.
Looks like it forbids goto except for multi-level break (not sure if the
language forbids multi-level next or not)--this is copied directly from
MISRA, so no surprise.  That's interesting because it forbids the C++
exception constructs as not being deterministic enough for realtime, so
even in C++ it should be done exactly as I described it.

Come to think of it, I may have seen the most unapologetic use of the
pattern in embedded code and hardware engineer practice.  I wonder if
that's because they don't get four years of religious indoctrination on
the subject the way software guys do?

I'm going to produce several goto-free implementations; I think
discussion of the relative merits of each will be interesting.  I've
added the first to the repo:

https://github.com/dllaurence/securec/blob/master/examples/exception-pattern1-nogoto.c

Dustin