[TUHS] Comments on "C"

[TUHS] Comments on "C"

[Doug McIlroy]

I sent a similar message some time ago, but I haven't
seen it appear in the mailing list, so here goes again.
Apologies if it ends up as a duplicate.

> After about 30 years of C, there are only three things I would have liked
> to see:
> 
> 1.  Computed goto
> ...
> Computed goto's are good for interpreters.

A computed goto is an optimized switch, and that optimization
goes back to the original C compiler. Mostly driven by
considerations of size and speed of the Unix kernel, Dennis
quite early on taught the compiler to choose among three
compilation strategies for a switch: a chain of comparisons, 
a tree of comparisons, or a computed goto, depending on the
number and density of alternatives.

The compilation of the system-call dispatch table was
a perfect example of "good for interpreters."

I have always assumed that other mainline compilers behave
similarly, but I have no solid knowledge about that.

doug

[TUHS] Comments on "C"

[Mary Ann Horton]

When I was at Berkeley working on my dissertation, I wrote a tool that 
would let you edit a text file written in any language you could define 
with a grammar, with syntax and semantic error checking while you 
edited.  I had grammars for several popular (in 1980) languages.  The 
only one I couldn't properly create a grammar for was C.

There were two problems:
1) typedef, which lets you create new words with syntax implications, 
and
2) the preprocessor, which lets you get into all kinds of syntax trouble

   Mary Ann

[TUHS] Comments on "C"

[scj]

Well, I have a list too -- unfortunately, I had a hand in a couple of
these...

The first is the syntax for casts.  When we were porting Unix from the
PDP-11 to the Interdata (32-bits) we discovered we needed casts badly, but
all of the proposals for syntax sucked.  Since the C grammar was in Yacc
by then, I played around with various ideas, and hit on the "simple"
notion that you just can make a declaration and remove the variable, and
voila, you had something that was unambiguous and, in simple cases, rather
nice -- (int), (int *).  Unfortunately, the sometimes awkward syntax for
declarations got all of its grottiness magnified when condensed into a
cast.  It turned out to be one of those things that was easy to write and
impossible to read.  That said, I'm not a great fan of
static_cast<xxx>(yyy) either...

Another issue is bit fields.  The question is how to lay out the bit
fields in a word -- if you say

union {
    short ss;
    struct {
        int sgn:1;
        int man:15;
    }
};

does sgn refer to the sign bit of ss or the low-order bit?  The answer in
PCC was that it depended on whether the machine was big-endian or
little-endian...    (remember big-endian machines?).

On the one hand, we had little choice, because we wanted int a:8 to act
like char a in a structure.  But the problem was, it made it difficult to
design things, like network protocols, that might communicate between
machines with different byte orders.  Machines like the MIPS, that could
do a sex change with the press of a button, were particularly painful...

With respect to the I/O library, indeed the decision to keep I/O out of
the language was the correct one, especially because I/O in those days
meant tape drives, line printers and punched cards for most machines.  But
the basic library was already there in B, and I believe was lifted, at
least in part, from BCPL.

It tends to be forgotten, but one of the most innovative things in Unix
was the conception of files as arrays of bytes that, because of their
simplicity, could be created almost as afterthoughts.  The mainframes of
the day, and even the time sharing systems built on them, treated file
creation as a big deal.  In the Honeywell time sharing system, you created
files by entering a file-creation subsystem, where you were interactively
asked 10 questions, including the device name, initial size, maximum size,
record size, blocking factor (don't ask!) and who was allowed to write the
file and who was not allowed to read it.  After answering these questions,
the subsystem begged the OS to create a file -- much of the time, it was
allergic to one of the answers, and required you to go through all the
questions again.  If you got through the process unscathed, the system
printed out "Successful!"
(yes, the exclamation point was there).

I remember in early days showing someone Unix and typing
    echo hello >foo
and showing them that foo was now a file.  The usual response was a gasp
and a dropped jaw, followed by confusion...

Steve












>> After about 30 years of C, there are only three things I would
> have liked to see:
>

[TUHS] Comments on "C"

[Diomidis Spinellis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

On 09/09/2016 06:02, Ronald Natalie wrote:
>> On Sep 8, 2016, at 6:06 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> On Thu, 8 Sep 2016, Ron Natalie wrote:
>>> Most of my complaints about C are because it's "standard" library was
>>> awful back in the seventies and it really didn't improve much over the
>>> years.
>>
>> That "portable I/O" library was certainly atrocious, but at least STDIO
>> was an improvement.
>
> Not much.   The functions have all of their portable IO library ugliness.   Don’t get me started on fread/fwrite.
> Ane why gets and fgets have different semantics and all the various functions take the stream parameter in
> different places.

Let's put things into perspective.  A rarely talked-about innovation of 
C was that the language was separate from the libraries.  At the time 
each language came with built-in commands for performing I/O and (if you 
were lucky) handling strings.  These were part of the language's syntax 
and semantics;  any additional facilities provided through libraries 
were second class citizens.  C gave us a lean language that could be 
implemented and run without the overhead of its "library" facilities. 
This made it suitable for writing an OS kernel and later for writing 
embedded systems applications and for porting to other operating 
systems.  It also made any add-on library a first class citizen.  In a 
program there's no difference between calls to the "standard" stdio.h or 
string.h functions and calls to add-on libraries such as those in dbm.h 
or mp.h.

The C library may be deficient, but when its interfaces were devised it 
was not "The C Library", but a number of functions and headers that (I 
guess) the people at Bell Labs whipped together to simplify their life 
when writing application code.  It doesn't show the careful design that 
went into other places (the C language, the Unix system calls, the 
shell), because I think it was expected that people would quickly come 
up with better alternatives.  In the end this "good enough" design 
spread widely and then got standardized (by removing Unix-specific 
functionality and a few rough edges) into what we now call the C 
Standard Library.

My complaint is that some APIs that were designed later, such as the C++ 
STL and the Python libraries, didn't adopt more consistent naming 
conventions.

[TUHS] Comments on "C"

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]


> On Sep 8, 2016, at 6:06 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Thu, 8 Sep 2016, Ron Natalie wrote:
> 
>> Most of my complaints about C are because it's "standard" library was 
>> awful back in the seventies and it really didn't improve much over the 
>> years.
> 
> That "portable I/O" library was certainly atrocious, but at least STDIO 
> was an improvement.

Not much.   The functions have all of their portable IO library ugliness.   Don’t get me started on fread/fwrite.
Ane why gets and fgets have different semantics and all the various functions take the stream parameter in
different places.

My other C gripe is when they fixed the semantics of structure typing (somewhere between V6 and V7) that they
didn’t also make arrays full fledged types at the same time.    The silent treatment of array as a pointer to element when used as function parameters/return is just ludicrous.

[TUHS] Comments on "C"

[Dave Horsfall]

On Thu, 8 Sep 2016, Ron Natalie wrote:

> Most of my complaints about C are because it's "standard" library was 
> awful back in the seventies and it really didn't improve much over the 
> years.

That "portable I/O" library was certainly atrocious, but at least STDIO 
was an improvement.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Comments on "C"

[Ron Natalie]

Efficiency isn't always the issue.   Even with the single layer break (and
certainly with the local goto) you can break structure.
The language, in my opinion, doesn't need further ways to break structure.


I'd have settled for a more robust preprocessor language, but such is life
with what was a ground breaking language back in the  70's.

Most of my complaints about C are because it's "standard" library was awful
back in the seventies and it really didn't improve much over the years.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Tony Finch
Sent: Thursday, September 8, 2016 10:23 AM
To: Noel Chiappa
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Comments on "C"

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
>     > 1.  Computed goto
>
> Can't you make a switch statement do what you need there?

Interesting comments on how effectively CPUs and compilers handle inner
loops of interpreters:

http://article.gmane.org/gmane.comp.lang.lua.general/75426

Lots more research on interpreter efficiency:

http://www.complang.tuwien.ac.at/projects/interpreters.html

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
German Bight, Humber, Thames: Southwest 4 or 5, increasing 6 at times.
Smooth or slight, occasionally moderate. Mainly fair. Good, occasionally
poor.

[TUHS] Comments on "C"

[Tony Finch]

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
>     > 1.  Computed goto
>
> Can't you make a switch statement do what you need there?

Interesting comments on how effectively CPUs and compilers handle inner
loops of interpreters:

http://article.gmane.org/gmane.comp.lang.lua.general/75426

Lots more research on interpreter efficiency:

http://www.complang.tuwien.ac.at/projects/interpreters.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
German Bight, Humber, Thames: Southwest 4 or 5, increasing 6 at times. Smooth
or slight, occasionally moderate. Mainly fair. Good, occasionally poor.

[TUHS] Comments on "C"

[Noel Chiappa]

    > From: Blake McBride

    > After about 30 years of C, there are only three things I would have
    > liked to see:

    > 1.  Computed goto

Can't you make a switch statement do what you need there? 

The two things I really missed were:

- BCPL's ValOf/ResultIs, for making more complex macros (although with the
	latest modern compilers, which inline small functions, this is less
	of an issue)
- The ability to 'break' out of more than one level of nesting; one either
	has to stand on one's head (code-wise), or use a goto

	Noel

[TUHS] Comments on "C"

[Doug McIlroy]

> After about 30 years of C, there are only three things I would
have liked to see:

> 1.  Computed goto

...

> Computed goto's are good for interpreters.

A computed goto, of course, is merely an optimized switch.
Dennis installed this optimization early in the evolution of C. The
main driving force was the performance and size of the PDP-11 Unix
kernel. As functionality grew, resource usage was repeatedly tamped
down by improving C's code generation.

The switch optimizer chose among three strategies: naive, binary
decision tree, and computed goto, depending on the number and density
of switch alternatives. Hybrid strategies may have been used, too,
but my memory is hazy on this point. In particular the optimization
improved system-call dispatch--thus achieving the objective,
"good for interpreters". I assume (I hope not unrealistically)
that this optimization has been in the repertoire of mainline C
compilers ever since.

> (Or perhaps require C to support tail recursion.)

I can imagine making a strong recommendation in the standard for
optimizing switches and (at least direct) tail recursion.

Doug

[TUHS] Comments on "C"

[Blake McBride]

After about 30 years of C, there are only three things I would have liked
to see:

1.  Computed goto

2.  goto a line in a different function (more than setjmp/longjmp)

3.  Easy / standard access to registers

Computed goto's are good for interpreters.

Goto a line in a different function makes it easier to implement languages
with tail recursion without a trampoline.  (Or perhaps require C to support
tail recursion.)

Some sort of standard way to access registers makes it easier to implement
garbage collectors without resorting to assembler.

Blake McBride


On Sun, Aug 28, 2016 at 7:42 PM, Larry McVoy <lm at mcvoy.com> wrote:

> I'm with Marc.  I think the C syntax is really pleasant, and while I
> enjoyed
> writing PDP-11 assembler (by far my favorite out the ones I've done which
> include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want
> go back to writing assembler unless I have to.  C is a pleasant language
> that easily compiles to assembler.
>
> I happen to like it so much I made a scripting language that looks very
> C like, with some perl pleasantness tossed in (without all the dollar
> signs).  Check it out at
>
> http://www.little-lang.org
>
> 100% open source, actively developed, yada, yada.
>
> On Sun, Aug 28, 2016 at 06:37:21PM -0600, Marc Rochkind wrote:
> > Yeah, OK, another one of those clever glib UNIXy aphorisms.
> >
> > But, as anyone who's actually programmed seriously in assembly language
> > knows, C is not assembler. It is a system programming language low enough
> > to be used for things that were once done in assembler, the most
> important
> > of which is an OS.
> >
> > So, for most of us, we no longer had to write in assembler. But that
> > doesn't mean C is assembler.
> >
> > So, are we just having fun over a few beers, or talking seriously? I like
> > both!
> >
> > --Marc Rochkind
> >
> > On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall <dave at horsfall.org>
> wrote:
> >
> > > Seen on another list...  And I got quoted by Steve Bellovin :-)
> > >
> > > --
> > > Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> > > suffer."
> > >
> > > ---------- Forwarded message ----------
> > > From: Kent Borg
> > > To: cryptography at metzdowd.com
> > > Subject: Re: [Cryptography]
> > >     "NSA-linked Cisco exploit poses bigger threat than previously
> thought"
> > >
> > > On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
> > >
> > > > I first heard more or less that line from Doug McIlroy himself; he
> > > > called C the best assembler language he'd ever used.
> > >
> > > Ancient fun-fact: Years ago there was an article in Byte magazine
> > > describing how a useful subset of C could be directly assembled into
> 68000
> > > code. Not compiled, assembled.
> > >
> > > C is a stunning assembly language. When those wild-eyed nerds at AT&T
> > > decided to write Unix not in assembly but in C (where was
> management!?),
> > > it was radical. But C was up to (down to?) the task, it was pioneering
> > > then and is still doing useful things decades later: From the fastest
> > > supercomputers to some pretty slim microcontrollers (plus a hell of a
> lot
> > > of Android devices) multitudes of computers run a Linux kernel compiled
> > > from the *same* C source code, with almost no assembly. Big-endian,
> > > little-endian: no matter. Different word lengths: no matter.
> > >
> > > That is one impressive cross-platform assembly language!
> > >
> > > Unfortunately, C is also a dangerous language that mortal programmers
> > > cannot reliably wield.
> > >
> > > -kb, the Kent who knows he is pressing his luck on a moderated
> > > cryptography mailing list, but C deserves a lot of respect, as it also
> > > deserves to be efficiently sent into a dignified retirement.
> > >
> > > _______________________________________________
> > > The cryptography mailing list
> > > cryptography at metzdowd.com
> > > http://www.metzdowd.com/mailman/listinfo/cryptography
> > >
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160907/3f23527d/attachment.html>

[TUHS] Comments on "C"

[Ron Natalie]

Many of us who got started early learned that the value of nothing was p&P6.

You can write bad (I'm not going to even to begin with sustainable) code in
any language.
C's biggest defect was it dates from an era where people didn't much care.
Type 120 characters into a field expecting 10, well you deserved what you
got.
It was more the issue with C's utility functions than with the language
itself.     Most of that has been cleaned up.

One piece of aracane programming did come in handy later on.    Our
highschool didn't have any computers.   Your choices were to call the
timeshare system across the county using the Bell 103 Dataphones or punch
your cards and send them down to the county seat to run on the 370 mainframe
(me and a friend were writing a computer dating program in COBOL until
someone at the County looked at our printouts and caught what we were up to.
Still we'd joke each other by inserting random JCL commands like //OPTIONS
ASSHOLE into each other's deck.   With a two day turnaround time, that was
painful).

What we did have is a bunch of old IBM card processing machines:   401
accounting machine, 514 reproducing punch, 085 colator, 082 sorter.    On
the shelf in that room was a bunch of self-paced training manuals on how to
program these units via large punchboards full of wires.   Being a geek, I
went through these (the 402/514 was an interesting combination, it had the
ability via a big 12x80 pin plug to punch the output of calculations on
cards).

Anyway, years later I was sitting around a  university computer center and
these guys came in with a problem.    They had a whole deck of IBM cards
that had patent information on them.    What was neat about these cards is
that in addition to the punched information, there was a window in the card
with a small piece of microfilm with some imagers on it.    The problem is
that all the card readers they tried to read this deck in would spaz when
the optical sensor hit the microfilm part.    No problem.    Give me the
columns you're interested in and I set about programming the 402 to print
out what they were interested in knowing.    I believe it was the only
useful thing I ever did with that machine.

[TUHS] Comments on "C"

[Nemo]

On 2 September 2016 at 17:23, Dave Horsfall <dave at horsfall.org> wrote:
[...]
> I think I saw that in CACM: "Prepare to throw out half your code, because
> you will anyway".

There is Brook's law: Plan to throw one away, you will anyways [MMM
Chapt. 11].  (There is also Writh's advice not to be afraid of tossing
it and starting again) but I do'nt recall the 50% rule.

[TUHS] Comments on "C"

[scj]

Before I headed off to my first summer job, my mother, who was working as
a programmer, gave me some good advice: "before you throw away a deck of
cards, put a rubber band around it...".   Saved my butt twice that
summer...

Incidentally, I figured the other day that a Petabyte of data, if punched
onto punched cards, would make a deck that was 6 times higher than the
distance to the moon...

Steve


> On Thu, 1 Sep 2016, Norman Wilson wrote:
>
>> Programming well requires a lot of thought and care and careful
>> rereading, and often throwing half the code out and re-doing it better,
>> and until we can have a programming community the majority of whom are
>> up to those challenges, we will continue to have crashes and security
>> vulnerabilities and other embarrassing bugs aplenty, no matter what
>> language is used.
>
> I think I saw that in CACM: "Prepare to throw out half your code, because
> you will anyway".
>
> Then there was the time I saw a Uni student, when, ambling down the
> corridor at UNSW Comp Sci, he tripped and spilled the entire deck of
> cards; after laughing for a while, I helped him to put them through the
> reader-sorter (fortunately, they were sequenced, I think).
>
> When I think back on some of the code I wrote, I still shudder...  Mind
> you, this was back in the days of the IBM-360 and the PDP-11, and I'd only
> just graduated, m'lud.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>

[TUHS] Comments on "C"

[Dave Horsfall]

On Thu, 1 Sep 2016, Norman Wilson wrote:

> Programming well requires a lot of thought and care and careful 
> rereading, and often throwing half the code out and re-doing it better, 
> and until we can have a programming community the majority of whom are 
> up to those challenges, we will continue to have crashes and security 
> vulnerabilities and other embarrassing bugs aplenty, no matter what 
> language is used.

I think I saw that in CACM: "Prepare to throw out half your code, because 
you will anyway".

Then there was the time I saw a Uni student, when, ambling down the 
corridor at UNSW Comp Sci, he tripped and spilled the entire deck of 
cards; after laughing for a while, I helped him to put them through the 
reader-sorter (fortunately, they were sequenced, I think).

When I think back on some of the code I wrote, I still shudder...  Mind 
you, this was back in the days of the IBM-360 and the PDP-11, and I'd only 
just graduated, m'lud.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Comments on "C"

[Random832]

On Fri, Sep 2, 2016, at 03:10, Steve Simon wrote:
> I find this a very interesting conversation.
> 
> my bugbear is languages and tools that help you do the the easy stuff,
> IDEs that suggest arguments for the read() function, syntax
> highlighting that show which text comments etc.
> 
> this is not stuff I find hard, it helps me with the easy stuff!

Sure, but help with the easy [and medium - not every function's
signature is as simple as read()] stuff helps you not break your
concentration to go look at documentation if you're not 100% sure you
remember the signature correctly, so you can use your brain more
efficiently for the hard stuff.

I use a Java IDE that will, with a single command, generate a
declaration corresponding to the type of an expression I just assigned
to an undeclared variable. This saves typing [in the easy cases] and it
saves thinking about return types [in the medium cases].

[TUHS] Comments on "C"

[Steve Nickolas]

My language of choice is C, and has been for a decade and a half.

I write some really FUGLY C code when I need to get down and dirty, like 
in my emulators - though they're not OO by a longshot, they're written as 
sort-of modular, one of them has an emulation of a 6847/6883 which is 
implemented in clearly marked functions, but the functions are terribly 
coded.  Comments are sparse, and usually only mark where I needed to 
actually think about what I was doing.

I implemented a couple Unix commands as part of a never-finished project - 
I wanted to write a userland for a Unix clone, where the utilities could 
also run on MS-DOS.

(...something like "Does DOS have the Unix nature?" "Mu!" comes to 
mind...)

-uso.

[TUHS] Comments on "C"

[Steve Simon]

I find this a very interesting conversation.

my bugbear is languages and tools that help you do the the easy stuff, IDEs that
suggest arguments for the read() function, syntax highlighting that show which text
comments etc.

this is not stuff I find hard, it helps me with the easy stuff! working out what to write - I.e. reading and digesting chip data sheets and protocol specs, that is what I need help with and there is no royal road to this.

I have long felt that solving complex problems requires complex code, but a well designed program can spread a little of this complexity as a thinner layer rather than having a great clump of it in one place. some languages can encourage this practice - OO is the obvious example of this, but it is not a requirement. I still remember the versatec printer driver written in beautiful FORTRAN 4 (yes it can be done).

-Steve




-Steve


> On 2 Sep 2016, at 01:11, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> Of course it's possible to write terrible programs in powerful languages!
> 
> How else could we have the wonders of the International Obfuscated C Code Contest?
> 
> 
>> On 09/01/2016 02:47 PM, Tim Bradshaw wrote:
>>> On 1 Sep 2016, at 10:17, Norman Wilson <norman at oclsc.org> wrote:
>>> 
>>> Flon's
>>> Axiom, for 35 years my favourite one-liner about
>>> programming and languages:
>>> 
>>>  There does not now, nor will there ever, exist a
>>>  programming language in which it is the least bit
>>>  hard to write bad programs.
>> I think this is almost trivially true (in the same sense that, say, general relativity is almost trivially true once you see it): if there are complicated problems to solve, then programming languages are either powerful enough to represent the solution or they can't solve the problem.  If they are powerful enough then that power can be used to write horrid programs, if they're not then they die out, at least as general-purpose languages.
>> 
>> To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps (really, Scheme) mandate tail-call elimination as part of the language, which is clearly this lovely pure thing to do which can only make programs better.  Well, in a language with tail-call elimination, some (but, of course, not all) function calls can be treated as gotos which pass arguments, and isn't goto meant to be bad?  So now add full continuations and any half-educated person like me can write the sort of tiny opaque horror which it would take someone really deep understanding to write in C, say.
>> 
>> That being said (and note I *like* C, a lot), what proportion of security problems are undetected buffer overflows?  Less than it used to be, I hope.

[TUHS] Comments on "C"

[Mary Ann Horton]

Of course it's possible to write terrible programs in powerful languages!

How else could we have the wonders of the International Obfuscated C 
Code Contest?


On 09/01/2016 02:47 PM, Tim Bradshaw wrote:
> On 1 Sep 2016, at 10:17, Norman Wilson <norman at oclsc.org> wrote:
>
>> Flon's
>> Axiom, for 35 years my favourite one-liner about
>> programming and languages:
>>
>>   There does not now, nor will there ever, exist a
>>   programming language in which it is the least bit
>>   hard to write bad programs.
> I think this is almost trivially true (in the same sense that, say, general relativity is almost trivially true once you see it): if there are complicated problems to solve, then programming languages are either powerful enough to represent the solution or they can't solve the problem.  If they are powerful enough then that power can be used to write horrid programs, if they're not then they die out, at least as general-purpose languages.
>
> To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps (really, Scheme) mandate tail-call elimination as part of the language, which is clearly this lovely pure thing to do which can only make programs better.  Well, in a language with tail-call elimination, some (but, of course, not all) function calls can be treated as gotos which pass arguments, and isn't goto meant to be bad?  So now add full continuations and any half-educated person like me can write the sort of tiny opaque horror which it would take someone really deep understanding to write in C, say.
>
> That being said (and note I *like* C, a lot), what proportion of security problems are undetected buffer overflows?  Less than it used to be, I hope.

[TUHS] Comments on "C"

[Tim Bradshaw]

On 1 Sep 2016, at 10:17, Norman Wilson <norman at oclsc.org> wrote:

> Flon's
> Axiom, for 35 years my favourite one-liner about
> programming and languages:
> 
>  There does not now, nor will there ever, exist a
>  programming language in which it is the least bit
>  hard to write bad programs.

I think this is almost trivially true (in the same sense that, say, general relativity is almost trivially true once you see it): if there are complicated problems to solve, then programming languages are either powerful enough to represent the solution or they can't solve the problem.  If they are powerful enough then that power can be used to write horrid programs, if they're not then they die out, at least as general-purpose languages.

To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps (really, Scheme) mandate tail-call elimination as part of the language, which is clearly this lovely pure thing to do which can only make programs better.  Well, in a language with tail-call elimination, some (but, of course, not all) function calls can be treated as gotos which pass arguments, and isn't goto meant to be bad?  So now add full continuations and any half-educated person like me can write the sort of tiny opaque horror which it would take someone really deep understanding to write in C, say.

That being said (and note I *like* C, a lot), what proportion of security problems are undetected buffer overflows?  Less than it used to be, I hope.

[TUHS] Comments on "C"

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

On Thu, Sep 1, 2016 at 5:17 AM, Norman Wilson <norman at oclsc.org> wrote:

> Flon's Axiom comes from a short note On Research
> in Structured Programming, published in SIGPLAN
> Notices in October 1975.  It's just as true today.
>
​+1  (a few times) - His axiom is also one of my favorites.   Flon was
brilliant and funny.​


​Page 16 and 17.   Scanned from my copy and ocred - fair use declared ;-)

Its interesting... FORTRAN still pays my salary ;-)
It's not banks & insurance company programmers.  It's the physicist,
chemists et al running on my supercomputer that still use it.

But as Flon says, I see just as many bad Java, javascript, Python programs.


==========  Sigplan Notices October 1975 -- pages 16 and part of 17.

On Research in Structured Programming

Lawrence Flon

Department of Computer Science

Carnegie-Mellon University

Pittsburgh, PA 15213



The August issue of SIGPLAN Notices contained a rather interesting
collection of material.  Not suprisingly, I was struck with some humor at
first upon noticing the rather glaring connection between Karp's letter on
the one hand and examples of each of his objections on the other. The issue
presented, in addition, a lampoon of what has become a somewhat limited,
syntax for titles of structured programming articles, followed by yet
another member of that very class.  My mirth, unfortunately, did not last
long when I began to wonder about whether the whole thing was at all
funny.  There has been a forum going on for quite some time in an effort to
define structured programming. A number of articles have been written in
the style of Dijkstra's original goto letter in an attempt to banish
particular language constructs. Counter-articles have been written
defending these constructs. I would like to present a statement which has
needed presenting for a while.  I like to regard it as an axiom because I
firmly believe both in the statement itself and the hopelessness of trying
to prove it.



*Axiom*

*There does not now, nor will there ever, exist a programming language in
which it is the least bit hard to write bad programs. *



Not only is it possible to misuse goto's, global variables, and
conditionals, but the possibilities for misuse of block structure,
procedures, macros, pointers, and everything else are endless. Too many
textually nested blocks can make an ALGOL program hopelessly unreadable, as
can procedures or macros with too many parameters. A set of procedures
whose functions are badly partitioned are not only difficult to understand
but hard to modify. Syntax macros which do not themselves parse to
non-terminal or terminal symbols (e.g. those with unbalanced parentheses or
begin-end pairs) are prone to causing hard-to-find syntax errors.
Unrestricted pointers (as in PL/I) cause a proclivity of disastrous bugs.
These are the seeds for at least four more "considered harmful" papers
which I will not write and hope no one else does.



I would like to see the S.P. forum re-directed towards a less hopeless task
than finding the perfect programming language or formally defining S.P.
itself. If we take the definition to be simply the construction of
efficient, readable, understandable, modifiable, and verifiable programs,
we can then begin to discuss ways to *globally* reach these goals by
*educating* the people who do the programming.  Since it follows from the
axiom that no amount of construct-clipping will make the typical graduate
of a "data processing" school even a potentially good programmer, we must
find something that will: What can be said to be the *proper* use of
goto's, conditionals, and global variables (and block structure, pointers,
etc.)? What are the general guidelines to follow with respect to
procedures? How does one go about modularizing a task, anyway?



Answering these questions and so many more is what structured programming
research should be about. What good is debating the if-then-else construct
when half the world is programming in (and will continue to program in)
FORTRAN? Let us see articles on the-way-to-do-it-right in *any* language;
articles which programming managers can show their programmers which will
improve the quality of software where it is most needed - not in
universities and research centers, but in banks and insurance companies.



​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160901/60d35c3d/attachment.html>

[TUHS] Comments on "C"

[Norman Wilson]

Every time someone starts spouting about how unsafe
C is, and how all the world's problems would be solved
if only people would stop using it, I think of Flon's
Axiom, for 35 years my favourite one-liner about
programming and languages:

  There does not now, nor will there ever, exist a
  programming language in which it is the least bit
  hard to write bad programs.

Flon's Axiom comes from a short note On Research
in Structured Programming, published in SIGPLAN
Notices in October 1975.  It's just as true today.

Over the years I've seen people misinterpret the
Axiom as an argument against looking for better
programming languages at all, but that's not what
it means.  (Read the original note--it's a page
and a half--for full context; it is, alas, behind
ACM's Digital Library paywall.)  There are certainly
languages that make certain sorts of mistakes easier
or harder, or are easier or harder to read, but in
the end most of that really is up to the programmer.

Programming well requires a lot of thought and care
and careful rereading, and often throwing half the
code out and re-doing it better, and until we can
have a programming community the majority of whom
are up to those challenges, we will continue to have
crashes and security vulnerabilities and other
embarrassing bugs aplenty, no matter what language
is used.

Norman Wilson
Toronto ON

[TUHS] Comments on "C"

[John Cowan]

On Wed, Aug 31, 2016 at 9:32 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> The null pointer constant does not need a cast on ANY architecture .


Well, it's a matter of what counts as "need".  People normally expect
execl("/bin/sh", "sh", "-c", "date", NULL) to work, but it will not on
systems
that define NULL as 0 and have different sizes of integers and pointers
(or, Ghu forbid, null pointers that are not all-bits-0).  The man page is
careful to warn against this practice, but it is commonplace anyhow,
and on such architectures, defining NULL as (void *)0 will protect
users against this situation.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Clear?  Huh!  Why a four-year-old child could understand this report.
Run out and find me a four-year-old child.  I can't make head or tail
out of it.        --Rufus T. Firefly on government reports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/0de71090/attachment.html>

[TUHS] Comments on "C"

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]


> On Aug 28, 2016, at 8:37 PM, Marc Rochkind <rochkind at basepath.com> wrote:
> 
> But, as anyone who's actually programmed seriously in assembly language knows, C is not assembler. It is a system programming language low enough to be used for things that were once done in assembler, the most important of which is an OS.
> 
> So, for most of us, we no longer had to write in assembler. But that doesn't mean C is assembler.
> 

Interestingly, assembler seems to be making a come back if one gives any credence to the Tiobe index. http://www.tiobe.com/tiobe-index/ As one who has written a lot of assembler code and no small number of assemblers, I wouldn’t like to write in assembler again. The problem is the lack of redundancy to catch errors.

As you all know (preaching to the choir here) the semantic model for C is the common von Neumann architecture. With the exceptions of returning structures, the semantics map one to one with most machines. This means that I can write C code and know pretty well what instructions are going to be generated. This in turn means that I can use C for almost all cases where I would have had to use assembler. The great Niklaus Wirth demonstrated this with his Oberon and some other small languages that completely replaced the use of assembler in his systems.

Some modern compliers have broken this, however. I have never been able to figure out what clang is going to do. But I should expect 28,000,000 bytes of instructions to do weird things. There’s no reason a C compiler should ever be more than about 0.25 MB of text.

  Brantley Coile

[TUHS] Comments on "C"

[Ron Natalie]

 


> The value of nothing is 0, or on unusual architectures, (void *)0.

 

T null pointer constant does not need a cast on ANY architecture .

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/36b083ea/attachment.html>

[TUHS] Comments on "C"

[John Cowan]

On Wed, Aug 31, 2016 at 6:02 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

A C programmer knows the cost of all sufficiently simple things and the
> value of nothing


The value of nothing is 0, or on unusual architectures, (void *)0.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Today an interactive brochure website, tomorrow a global content
management system that leverages collective synergy to drive "outside of
the box" thinking and formulate key objectives into a win-win game plan
with a quality-driven approach that focuses on empowering key players
to drive-up their core competencies and increase expectations with an
all-around initiative to drive up the bottom-line. --Alex Papadimoulis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/fe96cb60/attachment.html>

[TUHS] Comments on "C"

[Tim Bradshaw]

On 29 Aug 2016, at 04:16, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> "A LISP programmer knows the value of everything and the cost of
> nothing".

A C programmer knows the cost of all sufficiently simple things and the value of nothing. No significant programs written since 1980 have been sufficiently simple.

(This isn't meant as a hostile comment!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/a7f582b2/attachment.sig>

[TUHS] Comments on "C"

[Greg 'groggy' Lehey]

On Sunday, 28 August 2016 at 18:37:21 -0600, Marc Rochkind wrote:
> Yeah, OK, another one of those clever glib UNIXy aphorisms.
>
> But, as anyone who's actually programmed seriously in assembly language
> knows, C is not assembler. It is a system programming language low enough
> to be used for things that were once done in assembler, the most important
> of which is an OS.

Agreed, calling assembler is being deliberately a little silly.  But
there is a connection: when I write C, I can envision what code is
going to be produced.  With many languages, including C++, you can't
be so sure.

"A LISP programmer knows the value of everything and the cost of
nothing".

> So, are we just having fun over a few beers, or talking seriously? I
> like both!

I'll go for the beer.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160829/22dc6a9a/attachment.sig>

[TUHS] Comments on "C"

[Steve Nickolas]

On Sun, 28 Aug 2016, Larry McVoy wrote:

> I'm with Marc.  I think the C syntax is really pleasant, and while I enjoyed
> writing PDP-11 assembler (by far my favorite out the ones I've done which
> include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want
> go back to writing assembler unless I have to.  C is a pleasant language
> that easily compiles to assembler.

Yeah, C's a really nice language.  About as high as Pascal and at the same 
time almost as low as ASM.

It's just a pity it's a horrible fit on the 6502 (my usual CPU of choice).

-uso.

[TUHS] Comments on "C"

[Larry McVoy]

I'm with Marc.  I think the C syntax is really pleasant, and while I enjoyed
writing PDP-11 assembler (by far my favorite out the ones I've done which
include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want
go back to writing assembler unless I have to.  C is a pleasant language
that easily compiles to assembler.

I happen to like it so much I made a scripting language that looks very 
C like, with some perl pleasantness tossed in (without all the dollar
signs).  Check it out at

http://www.little-lang.org

100% open source, actively developed, yada, yada.

On Sun, Aug 28, 2016 at 06:37:21PM -0600, Marc Rochkind wrote:
> Yeah, OK, another one of those clever glib UNIXy aphorisms.
> 
> But, as anyone who's actually programmed seriously in assembly language
> knows, C is not assembler. It is a system programming language low enough
> to be used for things that were once done in assembler, the most important
> of which is an OS.
> 
> So, for most of us, we no longer had to write in assembler. But that
> doesn't mean C is assembler.
> 
> So, are we just having fun over a few beers, or talking seriously? I like
> both!
> 
> --Marc Rochkind
> 
> On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> > Seen on another list...  And I got quoted by Steve Bellovin :-)
> >
> > --
> > Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> > suffer."
> >
> > ---------- Forwarded message ----------
> > From: Kent Borg
> > To: cryptography at metzdowd.com
> > Subject: Re: [Cryptography]
> >     "NSA-linked Cisco exploit poses bigger threat than previously thought"
> >
> > On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
> >
> > > I first heard more or less that line from Doug McIlroy himself; he
> > > called C the best assembler language he'd ever used.
> >
> > Ancient fun-fact: Years ago there was an article in Byte magazine
> > describing how a useful subset of C could be directly assembled into 68000
> > code. Not compiled, assembled.
> >
> > C is a stunning assembly language. When those wild-eyed nerds at AT&T
> > decided to write Unix not in assembly but in C (where was management!?),
> > it was radical. But C was up to (down to?) the task, it was pioneering
> > then and is still doing useful things decades later: From the fastest
> > supercomputers to some pretty slim microcontrollers (plus a hell of a lot
> > of Android devices) multitudes of computers run a Linux kernel compiled
> > from the *same* C source code, with almost no assembly. Big-endian,
> > little-endian: no matter. Different word lengths: no matter.
> >
> > That is one impressive cross-platform assembly language!
> >
> > Unfortunately, C is also a dangerous language that mortal programmers
> > cannot reliably wield.
> >
> > -kb, the Kent who knows he is pressing his luck on a moderated
> > cryptography mailing list, but C deserves a lot of respect, as it also
> > deserves to be efficiently sent into a dignified retirement.
> >
> > _______________________________________________
> > The cryptography mailing list
> > cryptography at metzdowd.com
> > http://www.metzdowd.com/mailman/listinfo/cryptography
> >
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Comments on "C"

[Marc Rochkind]

Yeah, OK, another one of those clever glib UNIXy aphorisms.

But, as anyone who's actually programmed seriously in assembly language
knows, C is not assembler. It is a system programming language low enough
to be used for things that were once done in assembler, the most important
of which is an OS.

So, for most of us, we no longer had to write in assembler. But that
doesn't mean C is assembler.

So, are we just having fun over a few beers, or talking seriously? I like
both!

--Marc Rochkind

On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Seen on another list...  And I got quoted by Steve Bellovin :-)
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
> ---------- Forwarded message ----------
> From: Kent Borg
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography]
>     "NSA-linked Cisco exploit poses bigger threat than previously thought"
>
> On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
>
> > I first heard more or less that line from Doug McIlroy himself; he
> > called C the best assembler language he'd ever used.
>
> Ancient fun-fact: Years ago there was an article in Byte magazine
> describing how a useful subset of C could be directly assembled into 68000
> code. Not compiled, assembled.
>
> C is a stunning assembly language. When those wild-eyed nerds at AT&T
> decided to write Unix not in assembly but in C (where was management!?),
> it was radical. But C was up to (down to?) the task, it was pioneering
> then and is still doing useful things decades later: From the fastest
> supercomputers to some pretty slim microcontrollers (plus a hell of a lot
> of Android devices) multitudes of computers run a Linux kernel compiled
> from the *same* C source code, with almost no assembly. Big-endian,
> little-endian: no matter. Different word lengths: no matter.
>
> That is one impressive cross-platform assembly language!
>
> Unfortunately, C is also a dangerous language that mortal programmers
> cannot reliably wield.
>
> -kb, the Kent who knows he is pressing his luck on a moderated
> cryptography mailing list, but C deserves a lot of respect, as it also
> deserves to be efficiently sent into a dignified retirement.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160828/076f3852/attachment.html>

[TUHS] Comments on "C"

[Dave Horsfall]

Seen on another list...  And I got quoted by Steve Bellovin :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

---------- Forwarded message ----------
From: Kent Borg
To: cryptography at metzdowd.com
Subject: Re: [Cryptography]
    "NSA-linked Cisco exploit poses bigger threat than previously thought"

On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:

> I first heard more or less that line from Doug McIlroy himself; he 
> called C the best assembler language he'd ever used.

Ancient fun-fact: Years ago there was an article in Byte magazine 
describing how a useful subset of C could be directly assembled into 68000 
code. Not compiled, assembled.

C is a stunning assembly language. When those wild-eyed nerds at AT&T 
decided to write Unix not in assembly but in C (where was management!?), 
it was radical. But C was up to (down to?) the task, it was pioneering 
then and is still doing useful things decades later: From the fastest 
supercomputers to some pretty slim microcontrollers (plus a hell of a lot 
of Android devices) multitudes of computers run a Linux kernel compiled 
from the *same* C source code, with almost no assembly. Big-endian, 
little-endian: no matter. Different word lengths: no matter.

That is one impressive cross-platform assembly language!

Unfortunately, C is also a dangerous language that mortal programmers 
cannot reliably wield.

-kb, the Kent who knows he is pressing his luck on a moderated 
cryptography mailing list, but C deserves a lot of respect, as it also 
deserves to be efficiently sent into a dignified retirement.

_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography