Comments

BenApril 14, 2017 9:18 AM

Amen to that, Bob. Even "don't use gcc" would be a start, given that team's persistent efforts to introduce new vulnerabilities into old code with each version.

AnuraApril 14, 2017 9:39 AM

@h2g2bob

That's not a problem with C++ so much as a problem with using fixed-size integers. Unless you want to use arbitrary precision integers or go with the python approach where integers change datatype when they overflow then you are stuck with having to deal with that problem.

In fact, I'd say that I'm thankful unsigned integers are so well defined with respect to addition - many cryptographic algorithms (e.g. SHA*, *fish, ChaCha/Salsa) would be a bigger pain to implement if they weren't.

Embedded coderApril 14, 2017 10:23 AM

Re: how unsigned ints overflow. That's a basic feature of the hardware. If you increment an N-bit value that's 111...1b, the carry out has nowhere to go except the proc's status register, and the result is 000...0b.


The standards are interesting but mostly irrelevant to small embedded systems. I would add
* Run out of flash, not RAM, even if your proc allows it. Ground the flash reprogramming voltage pin through a resistor -- you're going to buy the procs pre-programmed. For development, leave out the resistor and solder a jumper to the voltage you need. Try to download malicious code now!
* Always use a WDT. Only reset in once place (main loop, ISR, thread or task). Everything else will set flags as they run (which means everything must unblock in less than the WDT time), and that 'one place' resets the WDT and clears the flags iff all the flags are set.
* Write your own version of assert() that writes to a spare UART. Use it extensively.
* Use the exact-size integer types (e.g., uint8_t) and verify by analysis that any arithmetic cannot overflow.
* If there is a password that is used to get into a special mode (e.g., BIT) make it long and random (don't worry, your test equipment won't complain) and don't allow retries. A low baud rate is a simple way to limit the number of tries. A 20-byte password takes 21ms to enter at 9600 baud. You can always switch to a higher speed later.
* _All_ your security-related code and data _must_ be in internal memories.
* You're going to be making millions of these devices and won't be able to update them, so you better get it right the first time. And that means you better keep it simple.

AnuraApril 14, 2017 11:03 AM

@Embedded coder

How overflow is handled is a choice; an integer of all 1-bits might be defined as an error state which it gets set to when it overflows. Different behaviors can be abstracted within the environment or programming language. If C++ left it up to the implementation then they can choose how they want to handle overflow, which might be affected by the hardware or the personal philosophy of the person implementing the language. Thus, it becomes one more problem to deal with when you are designing an implementation. Making it well-defined (unlike signed integer overflow) allows those implementing the algorithm to rely on that well-defined behavior across all systems and implementations.

AnonApril 14, 2017 11:03 AM

As I see it, too many programmers rely on language features to think for them, rather than the programmer properly understanding his or her code and thinking about what they are trying to do.

I hate const. Why? It is only used at compile time, as a method to prevent a programmer assigning a value to a variable they think should be "read only" after declaration. They then get into the mind-set that it is OK to do stupid things, "because the compiler will warn them".

Of fourse, these same developers later wonder why their code blew ip on them in the most unexpected way.

Here are some tips (IMHO):

* Don't write code if you don't need to
* Don't use language features for any reason other than ABSOLUTELY NEED TO
* All the "cool new features" we see in recent updates that people scramble to get - if they were really needed, why did they take 30 years to appear?
* Stop worrying about breaking old code - this is 90% of the problem! Fix the damn problem.

AnuraApril 14, 2017 12:56 PM

@Anon

It is a bad craftsman who blames his tools. Not unlike the Linux kernel, I've built entire castles using nothing but a shovel and a bucket.

DannyApril 14, 2017 1:04 PM

Isn't that beautifiers job anyway? Write the code as you like, then before post it to repository have it go through a beautifier, with the coding style rules you want/need. Job done.

Nick PApril 14, 2017 1:38 PM

Also, any C++ developers should also check out and review SaferCPlusPlus by duneroadrunner. Unlike Ironclad C++, he claims his is ready to go and actively maintained.

Nick PApril 14, 2017 1:50 PM

@ Anura

Instead of arguing, I'm straight-up calling that a lie perpetuated by people defending unsafe or inflexible languages. I know more craftsmen that I could begin to count in construction, mechanical engineering, factories, and so on. They or their companies all try to use best tool for the job plus consider its limitations. Constrained by budget priorities more than anything.

Programmers doing what "craftsmen" do would be using safer languages with good tooling and easy maintenance. By comparison, the people trusting languages like C or C++ are more like Luddites insisting on doing construction of complex properties only with hammers, nails, metal, and wood. They'd manufacture the toilets and heaters the same way. I can only imagine the material/labor cost, poor usability, and quality issues.

My InfoApril 14, 2017 2:01 PM

C++ security? What are you talking about? Just sit on the couch, use the nice comfy IDE, and let the compiler take care of it for you.

My InfoApril 14, 2017 2:14 PM

#include <iostream>
int main(const int argc, const char *const *const argv, const char *const *const envp) { std::cout << "I give up." << std::endl; return 0; }

Embedded coderApril 14, 2017 2:23 PM

@Anura
How overflow is handled is a choice; an integer of all 1-bits might be defined as an error state which it gets set to when it overflows.

All procs have an overflow bit which handles the situation you describe (unsigned int x = ~0; ++x;). Unfortunately most (all?) HLLs don't let you access it. It would be better IMHO if the programmers checked for overflows themselves where they can happen instead of having the overhead of a check at every operation. Every byte matters!

Oh, what we could do if we had access to the proc's status register, though!

Clive RobinsonApril 14, 2017 2:46 PM

@ Embedded coder,

The int overflow issue is just on issue with hardware. When you work with some analog I/O you get some funny things where you have to know your way around not just two's complement but one's complement as well.

As for WDT and blocking, there are quite a number of ways around this, for *nix people there is always select and poll. For old PC Hacker types doing bidirectional serial IO like a terminal program in DOS, you read the status flags from the second generation UART (16450) and cut back to the main loop if the RX buffer was empty or full for TX. The main loop would likewise read in the flags as a polling system. Smarter people would use the interupt system, either way being a single user single process environment it was almost trivial because all the CPU cycles were yours to idle with, so blocking was not an issue, but charecter loss on the generation one UART (8250) and high baud rates was, which could lead to custom screen drivers as the BIOS had all the speed of a snail on mogadon (Nitrazepam for those on the other side of the puddle).

Clive RobinsonApril 14, 2017 3:05 PM

@ Anon,

I hate const. Why? It is only used at compile time,

It depends on what type of system you are writing for and if the compile is specific to it.

In low resource CPU embedded systems such as 8bit systems, const can be used as a flag to the compiler that the variable can be put in ROM as opposed to RAM.

Embedded coderApril 14, 2017 3:20 PM

@Clive Robinson
"The int overflow issue is just on issue with hardware. When you work with some analog I/O you get some funny things where you have to know your way around not just two's complement but one's complement as well."

Don't students learn 2's C and 1's C any more? As I wrote, if a HLL gave you access to the overflow status bit, the program could check. Otherwise, statically analyze your code to make sure it doesn't overflow.

"As for WDT and blocking, there are quite a number of ways around this"

You missed the point. I wrote that you only want to reset the WDT if all your execution units are OK: the main loop, periodic ISRs, threads, tasks, etc. To do that, each sets a flag when they run. In one, and only one place, the program checks if all flags are set, and if so, resets the flags and WDT. If a task can block forever, waiting for something, it won't be able to set its flag and the WDT will be allowed to expire. It would have to wait for the event with a timeout, then check what happened once it resumes executing. The code gets a little more complex, but it pays you back the first time a thread hangs. How you do the actual implementation is immaterial.

John GaltApril 14, 2017 3:30 PM

@ Nick...

[[[ Programmers doing what "craftsmen" do would be using safer languages with good tooling and easy maintenance. By comparison, the people trusting languages like C or C++ are more like Luddites insisting on doing construction of complex properties only with hammers, nails, metal, and wood. They'd manufacture the toilets and heaters the same way. I can only imagine the material/labor cost, poor usability, and quality issues. ]]]

LOL.

What's your favorite "safe language" and I'll show you the LEX/YACC grammar and C source code.

Of course, there is always assembly language. What "safe CPU" do you recommend.

But, for the safest of the safe, I suggest coding it in 1s and 0s. Then, you can be certain that there are no mistakes, whatsoever.

BlakeApril 14, 2017 4:33 PM

Is there a direct download link? The web version has blank colored boxes for all the "code examples", and the download link there requires registration.

Clive RobinsonApril 14, 2017 5:08 PM

@ Embedded coder,

Don't students learn 2's C and 1's C any more?

It depends, but I've intervied quite a few CS grads and no they could not answer questions about it. Oddly perhaps EE and Physics grads have always given the right answers. Even Chem/Bio grads who have moved over to lower level programing for embbeded and ICS have been able to answer it as well.

As I wrote, if a HLL gave you access to the overflow status bit, the program could check. Otherwise, statically analyze your code to make sure it doesn't overflow.

Another way in a HLL is to make a copy of the value you are going to add to then compare the result to the copy if the result has overflowed then it will be less than the copy. But you need to know that the HLL compiler has not put something clever in like forcing the result to 0-1.

As for static analysis, I'm not that keen on it as I've seen it go wrong in the past.

ThothApril 14, 2017 6:03 PM

@all

This is the reason security will forever never improve because the insecure stuff never gets thrown away and simply keeps "floating up". Another half a century and probably we are still going to be stuck at the problems we could have solved many decades ago.

My InfoApril 14, 2017 7:03 PM

@Clive Robinson

Oops, I must have disclosed my e-mail address: anon@...

const char *const *const argv

The first instance of "const" means that "argv" is a pointer to a pointer to a memory location that must not be modified, i.e. the double dereference "**argv" is constant.

The second instance of "const" means that "argv" is a pointer to a memory location that must not be modified, i.e., the dereference "*argv" is constant.

The third instance of "const" means that the variable "argv" itself is constant.

When you use "const" variables as arguments to a function, then you must declare those arguments "const" in the declaration of the function, which is a promise not to modify them in the body of the function.

The compiler will make a lot of noise if you write code that breaks a "const" promise.

char *const *const argv

Constant pointer to constant pointer to variable char.

const char *const *argv

Variable pointer to constant pointer to constant char.

const char **const argv

Constant pointer to variable pointer to constant char.

char **const argv

Constant pointer to variable pointer to variable char.

char *const *argv

Variable pointer to constant pointer to variable char.

const char **argv

Variable pointer to variable pointer to constant char.


Please. I promise.

ab praeceptisApril 14, 2017 7:10 PM

Cute! Very nice Ersatz for the friday squid - and funny, too.

It seems, though, that the cmu people didn't dare to call out the truth and therefore chose to not call it "Big fat list of reasons why C++ is a box full of vipers and pain. Stay away from it even for hobby stuff, let alone anything security related!".

Example desired? Et voilà:

MEM50-CPP. Do not access freed memory
MEM51-CPP. Properly deallocate dynamically allocated resources
MEM52-CPP. Detect and handle memory allocation errors
MEM53-CPP. Explicitly construct and destruct objects when manually managing object lifetime
MEM54-CPP. Provide placement new with properly aligned pointers to sufficient storage capacity
MEM55-CPP. Honor replacement dynamic storage management requirements
MEM56-CPP. Do not store an already-owned pointer value in an unrelated smart pointer
MEM57-CPP. Avoid using default operator new for over-aligned types

Thanks to cmu for providing the big fat list of reasons to avoid C[++] like the plague.

Clive RobinsonApril 14, 2017 7:18 PM

@ Thoth,

This is the reason security will forever never improve because the insecure stuff never gets thrown away and simply keeps "floating up".

The problem is not the language but those who use it.

The language serves a purpose which originally was to be a step up from asembler in a system independent way, to aid in porting an OS. Compared to the method it replaced of writing an OS from scratch in assembler it was a great improvment. Unfortunatly ad K&R themselves have admitted they would do somethings differently.

Unfortunatly the original documentation for the language was brief and not fully specified. Thus as people wrote their own compilers or reworked those of others as I did with Small C there were many slightly different implementations. Thus the standardisation process began within the industry, the problem was the industry have vested intrests and their own favourit additions. When you have a committee of vested interests you end up with a mess...

Both C and C++ have suffered from this. But worse is the standard libraries they suffer from revision after revision of bloat. After all ask yourself how many people do you known who can tell you how to use every part of the C++ standard library?

The simple fact is the language has been pushed way way beyond it's original intent and gone from something simple and sort of elegant into a something more reminisant of what the keeper of the elephant house has to face in the morning.

ab praeceptisApril 14, 2017 7:27 PM

Nick P (4/14 1:50 PM)

Funny that you say that. That's pretty exactly what I tell my clients and what I insist on in our own house.

"Evangelists, hackers, gurus - leave that to the marketing and PR driven idiot boxes. Be craftsmen! Think and act like craftsmen!"

When being asked what kind I use to respond "ship builders". Reason: The oceans are a quite good and well working analogon to the environment in which our products run. Usually more or less calm (sea states up to, say, 2 m) sometimes heavy gales, and occasionally even a freak wave. If you aren't prepared, you are dead, simple as that.
Plus (I'm lacking the word) treacherous low depths, riffs, etc.

And: A ships hull must be tight. No matter, how many km of welding, not a single cm can be done poorly plus the "skeleton" mus be well reflected, computed, designed, and built.

OF COURSE no shipbuilder can do that with cool toys and poor materials. He'll always ask for the proper tools and doesn't work with lousy ones.

I'm glad to see you using the term "craftsmen", too. The evangelists, cool hackers and gurus we had - and they created a mess. Time to get on our feet again and to become (and educate) good craftsman.

FigureitoutApril 14, 2017 7:57 PM

My Info
--If you're going to post code, you could at least make it pseudo interesting, not a print statement.

Embedded coder
Don't students learn 2's C and 1's C any more?
--Yeah we do. For ECE students at least. Got a hw assignment on it due next week on it (1st hw assignment that isn't coding, so easy one). That and IEEE floating point standards w/ sign bits, mantissas, and exponent numbers.

Nick PApril 14, 2017 8:04 PM

@ John Galt

"What's your favorite "safe language" and I'll show you the LEX/YACC grammar and C source code."

We'll start with Burroughs ALGOL, LISP, and Pascal that predate C language. That is if you're implying a dependency on it. Next we'll look at Ada compilers written in Ada, Rust compiler written in Rust, Wirth languages like Oberon written in themselves, the most robust of all C compilers (CompCert) written in Coq extracted to ML, and while you're at grammars a clean semantics of C capturing undefined behavior written in K/Maude with GCC-like front end.

We don't need C anymore. It's not even as good as the competition. If you did need it, there are tools to cleanly do FFI or extract better stuff to safe C that you needn't bother writing. Then you can recode that stuff piece by piece.

"What "safe CPU" do you recommend."

CHERI, SAFE, or HW implementation of SAFEcode given two already run FreeBSD. They knock out all the code injection methods currently in use.

"But, for the safest of the safe, I suggest coding it in 1s and 0s. Then, you can be certain that there are no mistakes, whatsoever."

You did seem to be trolling like a lot of your other comments. This confirms it.

@ ab praeceptis

"I'm glad to see you using the term "craftsmen", too. The evangelists, cool hackers and gurus we had - and they created a mess. Time to get on our feet again and to become (and educate) good craftsman."

I usually say engineers. Craftmen is another good term that might even be more accurate for average, high-quality software given it's a balance of proven methods (science) with clever adaptations (art). Either one is different than people using C except the most dedicated who should probably be thought of more like the Monster Garage people than regular craftsmanship or engineering. ;)

John GaltApril 14, 2017 8:16 PM

@ ab

[[[ OF COURSE no shipbuilder can do that with cool toys and poor materials. He'll always ask for the proper tools and doesn't work with lousy ones.

I'm glad to see you using the term "craftsmen", too. The evangelists, cool hackers and gurus we had - and they created a mess. Time to get on our feet again and to become (and educate) good craftsman. ]]]

CASE tools -- flop.
4GLs -- flop.

C -- works every time. To me, C++ is only suitable for event-driven OO GUIs.

Berkeley DB -- still vibrant; SQL (whatever flavor), etc. All written in C.

COBOL / RPG : Still around; but, who wants to do that? Maybe CICS and 3270 screens will appeal to today's craftsman.

Today, every 2-5 years, you gotta rewrite/overhaul everything because the "script kiddie" language has changed again.

Recompile &/or relink C - you are done.

Java? Don't get me started. Today you even have to worry about malware for the JVM.

John GaltApril 14, 2017 8:31 PM

@ Nick....

[[[ We'll start with Burroughs ALGOL, LISP, and Pascal that predate C language. That is if you're implying a dependency on it. Next we'll look at Ada compilers written in Ada, Rust compiler written in Rust, Wirth languages like Oberon written in themselves, the most robust of all C compilers (CompCert) written in Coq extracted to ML, and while you're at grammars a clean semantics of C capturing undefined behavior written in K/Maude with GCC-like front end. ]]]

ALGOL? You gotta be kidding. Pascal was derived from the ALGOL line. Python is today's FORTRAN.

Pascal started as the UCSD P-System. (Predating Java. Derived from ALGOL) Been there; done that. (I stamped out bugs in the Microsoft Pascal Libraries)
LISP -- been there; done that.
ADA -- been there; done that.
Modula-2;3 -- been there; done that.
SPL -- HP's system programming language ~ Pascal. Been there; done that.
Assemblers across several mfrs --- been there; done that.
BASIC (name it) .... been there; done that.

Rust -- you got me there. I ain't been down that road.

So... You are writing everything in ALGOL, LISP, and Pascal? On what? An IBM 1401 with 4K? (That's what my late father-in-law started on.)

Anyone here still using DBase III?

John GaltApril 14, 2017 8:34 PM

@ Nick...

[[[ We don't need C anymore. It's not even as good as the competition. If you did need it, there are tools to cleanly do FFI or extract better stuff to safe C that you needn't bother writing. Then you can recode that stuff piece by piece.]]]

I wonder how many lines of C you executed today

???

What OS do you run? Linux? BSD?

You might want to pull out the source code for the Kernel.

Or, maybe your 1977 TI-59 calculator. (I had one of those, too.)

Clive RobinsonApril 14, 2017 8:35 PM

@ Figureitout,

Got a hw assignment on it due next week on it

Good luck on that just remember the two zero values with one's complement ;-)

@ My Info,

When it comes to C proggrammers you can split them into two groups by those that are as happy using assembler and all the others.

Those happy with assembler and develop embedded low resource systems, tend to avoid the likes of malloc and pointers where the compiler does the arithmetic.


MKApril 14, 2017 8:51 PM

Seymour Cray liked to program directly in octal. Ed Lee, who was president of Prolog (a line of PROM programmers) said we should just get out a large (D-size) drafting template, and fill in the entries with assembly code, then convert to hexidecimal, which was then punched directly into the PROM programmer. Code changes required a new drawing, with all the approval signatures. Which hexidecimal? The Bendix G15 used UVWXYZ, the Royal McBee LGP30 used something derived from Flexowriter tape code. ABCDEF came much later. 0's and 1's are the only safe way. Depending on how the bits were numbered in a byte or word...

John GaltApril 14, 2017 9:09 PM

@ MK

>>> LGP-30 hex codes...

I almost forgot about FORTH. I had fun with that, too. Reverse Polish Notation still works with my HP calculator, too.

I still prefer the TI AOS system over the HP RPN.

Nick PApril 14, 2017 9:48 PM

@ John Galt

You're definitely trolling. You're whole post... what's relevant to the discussion... substitutes arguments about what tools get what jobs done in security better with whether certain systems are more usable today because all the labor was put into them. I love when people argue by popularity, lines of code in existence, or longevity. I counter with COBOL on mainframes. There's piles of it which nobody is replacing in most critical sectors. COBOL must be one of best languages in existence, right?

No, it just has the most functionality, it's hard/costly to rewrite, and so people tolerate its use in critical systems. Just like C and C++ for mainstream stacks that take millions of lines of code to run that are currently designed for C and C++. To put into perspective, Solaris 10 rewrite cost almost $300 million dollars. Mozilla takes in about that much a year just expanding and maintaining Firefox. A full stack switched to safer language with compatibility with existing, popular apps will cost a fortune if users aren't willing to tradeoff something.

You're talking economic and social stuff, not what language is superior. The alternatives are there. Few just want to invest in them in systems programming space outside the vibrant Go, Rust and Julia ecosystems that are getting lots of attention and software rewrites in their niches. Rust already has a microkernel-based, graphical OS called Redox made by a handful of people with contributions from some more. It's free of all kinds of security issues at compile time. UNIX in C still isn't after over a billion dollars worth of labor invested. It also took forever to get that reliable.

I wonder where $200 mil, $300 mil, or $1+ bil in labor in safe languages and toolchains would've gotten us? Pretty amazing what Ada, SPARK, Eiffel/SCOOP, and Rust did with mere millions to tens of millions. I imagine result would be more badass in terms of reliability and maintenance.

ab praeceptisApril 14, 2017 10:04 PM

John Galt

Kindly note that my nick is "ab praeceptis" (and not 'ab' just yours isn't 'J.').

I'm very glad that you came here. Finally, we dumbheads - incl. our host Bruce Schneier - have someone around who knows just about everything better than we do (and generously offers his wisdom to just about everything that comes up here).

John GaltApril 14, 2017 10:13 PM

@ Nick...

[[[ You're definitely trolling. ]]]

Pull the plank out of your own eye first.

I'm still waiting to know the "safe language" that you prefer.

If you showed up on a C or Kernel forum and said C is obsolete, who would be the troll???

Or, on the other hand, WHAT IS THE TITLE OF THIS THREAD? "New C++ Secure Coding Standard"

Who is the troll? What's your "safe language"?

John GaltApril 14, 2017 10:35 PM

@ ab praeceptis

[[[ "Kindly note that my nick is "ab praeceptis" (and not 'ab' just yours isn't 'J.'). ]]]

I forgot ... "ab praeceptis" is Latin for "by the rules"

A New rule. OK. I'll try to remember it.

[[[ (and generously offers his wisdom to just about everything that comes up here) ]]]

Would you like to know how many millions of lines of code I've written over the years? No, I'm not exaggerating, either. No, I'm not a kernel writer; but, I have even written device drivers in days gone by. Spent some of my best time with petroleum engineers doing reservoir mapping and 30 year production/flow forecasting.

I was using the "internet" for distributed systems before anyone even knew what the internet was.

Wisdom usually does come from experience, you know.

ab praeceptisApril 14, 2017 10:59 PM

John Galt

... plus some other factors. Wisdom is much more than just experience.

You wrote device drivers? Cool. I wrote them for hardware that I had designed myself.

Talking less frequently and listening and looking more you might find out that quite some people here haven't exactly started their career yesterday and quite some around here have demonstrated considerable levels of knowledge and such earned the respect they enjoy here.

You don't gain reputation here by quantity. It is gained by insight, profound lessons learned from lots of experience, by convincing thoughts and arguments, etc.

Feel free to convince me otherwise but until now I'd easily give up 5 John Galts for a single Clive Robinson.

Oh, and btw: Talking about oh how many million lines of code one (self alledgedly) has under ones belt is one of the less convincing ways to demonstrate experience, let alone wisdom.

Wisdom shines and shines without blinkenlights, trust me.

My InfoApril 14, 2017 11:00 PM

@Figureitout

I actually had written a program some time ago with this exact declaration of main().

int
main(const int argc,
    const char *const *const argv,
    const char *const *const envp)

If I recall right, I had declared an iterator for a vector<string,string>, initializing the C++ STL string class from the C string *envp++, but that required some extra work to compensate for the constness.

Anyways, I did have a program that printed out the argument list and the environment variables, after using strpbrk() to parse the environment variables at the "=".

John GaltApril 14, 2017 11:12 PM

@ ab

[[[ You don't gain reputation here by quantity. It is gained by insight, profound lessons learned from lots of experience, by convincing thoughts and arguments, etc.]]]

My purpose here isn't to make or break a reputation.

My purpose here is to make light of some of the most glaring problems with computing, today.

In particular, at this particular site, all the false security paradigms being blahblahed to death.

I mentioned "distributed systems" that I've done. Well, today's great invention known as the internet is not suitable for those systems, any more.

Why? Let me count the ways. I've already pointed out the most glaring one -- one that nobody wants to admit -- where "business cannot be conducted in a war zone... unless you are a prostitute."

Lest I say anything further, just beware that I view most of the leaders in the current internet space as just that -- prostitutes. I never really predicted that "cloud computing" would become "spy computing."

But, it didn't take me long to figure it out.

I see reality for what it is.

I don't care about brownie points.

WaelApril 14, 2017 11:14 PM

A good carpenter doesn't blame his tools. C++ allows you to define your own data types. Quit complaining and go develop your own secure classes or go cut'em from somewhere.

... a comprehensive list of C++ secure-coding best practices.

It's a good initiative, but I don't have the time to go through all of the list, which will likely be dated by the next revision of C++ standard. Going to fall on deaf ears anyways.

So which is more efficient: ++y or y++? That's about the only thing I remember from Scott Meyers' "Effective C++". and I used to read the C++ specifications for fun back in the day when men were men and women were... ribs.

@John Galt,

I was using the "internet" for distributed systems before anyone even knew what the internet was.

That's awfully big talk for someone who only wrote a few million lines of code ;) What does "systems" mean?

@My Info,

const char *const *const argv

Showing off today? Are you by any chance using cdecl? ;)

John GaltApril 14, 2017 11:26 PM

@ Wael...

[[[ That's awfully big talk for someone who only wrote a few million lines of code ;) What does "systems" mean? ]]]

Gas measurement systems, pipeline measurement and control systems (public utility, SCADA, and related systems); insurance claims systems; retail automotive systems; and others. The kind of stuff they try to scare us with on TV.

WaelApril 15, 2017 12:14 AM

@John Galt,

If I explain the joke, it won't be funny. I know what systems meant in your context.

Clive RobinsonApril 15, 2017 4:06 AM

@ Wael,

I used to read the C++ specifications for fun back in the day when men were men and women were... ribs.

Hmm I've heard of the Dr Atkins diet, but well are we going to have to call you Hannibal from now on :-S

WaelApril 15, 2017 5:02 AM

@Clive Robinson,

are we going to have to call you Hannibal from

Call me what you like. But never call me late for supper ;-)

Who's worse, Hannibal or Peter Kürten, the “The Vampire of Dusseldorf,” ?

faApril 15, 2017 6:10 AM

Clive Robinson wrote:

> The problem is not the language but those who use it.

Couldn't agree more. We have currently a generation of 'programmers' that are fully ignorant of the basics.
IMHO everyone wanting to become a programmer should be required to implement some

- fundamental algorithms in assembly language (on e.g. ARM, quite a neat instruction set).
- hardware interface code in C (try doing that using any 'safe' language).

before going on to 'higher level' languages and abstraction for its own sake.

> The simple fact is the language has been pushed way way beyond it's original intent and gone from something simple and sort of elegant into a something more reminisant of what the keeper of the elephant house has to face in the morning.

:-) It's still possible to use C++ in a sane way. Just limit yourself to the basic class mechanism, inheritance, and virtual functions, and stay away from STL and most 'patterns' (many of which are just clumsy ways to try and do things that the language doesn't support natively).


Clive RobinsonApril 15, 2017 7:35 AM

@ Wael,

Who's worse, Hannibal or Peter Kürten, the “The Vampire of Dusseldorf,” ?

Let's not descend into wurst jokes than we already have ;-)

FigureitoutApril 15, 2017 7:42 AM

Clive Robinson
--Oh yeah, +0 (0000) and -0 (1111)? Seems like a nightmare bug waiting to happen...

My Info
--So constant pointers to a constant object? Can't really do much w/ that pointer then eh?

Something weird I came up for a C++ class I'm taking was a stack iterator (they say you're not supposed to iterator thru a stack) that just makes a copy of the stack you want to iterate thru so you can pop() off elements w/o actually destroying the original stack you want to iterate thru. Main use would be just checking what's in the stack, can't touch it though. If you wanted to do something to an element you'd just be operating on a copy of it lol.

Clive RobinsonApril 15, 2017 8:02 AM

@ fa,

It's still possible to use C++ in a sane way. Just limit yourself to the basic class mechanism, inheritance, and virtual functions,

You can do those if you realy need them in assembler, and arguably with less side effects. But the fact that closer to the metal engineers avoid them if they can should tell people something...

OO is a high level construct and methodology, that has never sat well on C, there are way better languages to do OO in especially if you realy need it. That also have the advantage of producing either smaller or more efficient code.

I'll let others discuss other high level methodologies such as formal proofs and why they don't sit well on C/C++ but do on other OO HLLs.

Thus I tend to regard C++ as "C in a pink gimp suit", yes the // comment was nice, but so is a nice pattern on the top of your throthy coffee. And I'm sure other little niceties can be listed by many hear. But C++ just "feels wrong" to me, and it has done for over a quater of a century. I purchased and read the two Stroustrup books and was underwhelmed to put it politely. My feeling was of an "opportunity lost" to sort out Cs problems before you dump a load on top.

Imagine if you can a geriatric elephant trying to squeeze into ballet pumps and a tutu then trying to dance the lead in Swan Lake, there is a certain comody aspect to it, but in all honesty it's going to leave the audiance flat, not just the leading man, when he trys a high lift.

It's that sort of feeling I have about C++.

Clive RobinsonApril 15, 2017 9:15 AM

@ Figureitout,

Seems like a nightmare bug waiting to happen......

Yes and no. I've seen -0 (11...) used as both a "null" to indicate an uninitialized variable and as an "inband error indicator"

Thus if the hardware tried to do a maths operation on it, it would throw an exception. It also alowed for an easy version of a try/catch.

The downside is of course the extra fixup steps required when you do addition with negative values or subtraction with a larger number. In two's complement you just do an add or complement and add with Cin0 set and that's the end of it. What's not much talked about is the complement is a fast bitwise or logical operation whilst the increment is a slow wordwise arithmetic operation where you have to wait for the result to ripple across the word, hence the existance of fast "look ahead carry" logic.

One of the big problems as others have noted is the lack of access to the carry flag in HLLs, because it's "out of band signalling". C has this problem where 7/8bit unsigned chars are actually returned as signed ints to do inband signalling. Likewise C's use of /0 to mark the end of a string versus Pascal's String[0] as a counter to the length of the string, which is much more like the way buffers tradirionaly work.

There are pros and cons for both inband and outofband signalling and the use of various types of nulls. Neither is right or wrong but as you say a "nightmare bug waiting to happen" for those that sleepwalk into it.

For instance the "C string way" has the advantage of unrestricted length, but any error will walk all over memory. But worse still it's actually quite slow and inefficient when it comes to storing many strings of text sequentialy in memory. The Pascal string is in effect a "poor mans" linked list, thus it's realy very rapid to find say the 131st string and of a predictable data independent time, which C strings most definatly are not. If you want to do the same in C you have to seperatly build your linked list elsewhere in memory by counting each string at some point usually not at the "natural time" when the string is created or modified. Worse you have a problem when you shorten the string if you do it the quick way by just writing in a null indicator you turn one string into two strings and that realy is a nightmare to sort out.

Any way "you pays your money and you takes your choice" and "live with the consequences".

My InfoApril 15, 2017 9:18 AM

@Figureitout

My Info
--So constant pointers to a constant object? Can't really do much w/ that pointer then eh?
int
main(const int argc,
    const char *const *const argv,
    const char *const *const envp)
{
    const char *const *var_argv = argv;
    // Now you may iterate "*var_argv++"...
    // but you still may not modify what it points to.
    // ...
}

@Clive Robinson

But C++ just "feels wrong" to me, ...

I fully agree. The language lacks the mathematical rigor to support its excessive complexity, and with the ongoing annual release of backwards-compatible standards tweaks, all pretense of the original elegance of C (from the days of Kernighan and Ritchie) has been abandoned.

John GaltApril 15, 2017 10:11 AM

@ Clive

[[[ OO is a high level construct and methodology, that has never sat well on C, there are way better languages to do OO in especially if you realy need it. That also have the advantage of producing either smaller or more efficient code. ]]]

Everyone made a big deal about the "buzzword" OO back in the 90s. My response was: If you are doing it right, you are already doing OO. You don't need a language to do it for you.

I admit that Microsoft pushed it for awhile. The OO constructs in C++ were conducive to easier coding of Event-Driven GUIs. (Apple came up with Objective-C)

Before MS started its push, I was writing both Windows and OS/2 GUIs (even during their beta periods). C in the new GUI env was very tedious. Those long switch statements were a reality. We had to come up with our own methods of dealing with the event handling mechs and managing "states".

Eventually, MS came up with a suitable standardized object model(s) and everything became much simpler -- even in C.

Regardless, I get tired of today's systems that are constructed out of an infinite battery of 1 or 2 line functions and associated calls to execute those 1 or two line functions. Yet, we wonder why programs can't fit inside an 8GB machine, these days.

@ fa

Couldn't agree more. We have currently a generation of 'programmers' that are fully ignorant of the basics.

Today's college graduates don't know what it's like to fit a truly useful program into 16K of memory. I can. My late father-in-law managed to process payroll for a Fortune Co in 4K.

They are taught to build web pages. Today, EVERYTHING looks like a webpage. PROOF: Look at SAML. LOL


John GaltApril 15, 2017 12:03 PM

@ Clive

[[[ For instance the "C string way" has the advantage of unrestricted length, but any error will walk all over memory. But worse still it's actually quite slow and inefficient when it comes to storing many strings of text sequentialy in memory. The Pascal string is in effect a "poor mans" linked list, thus it's realy very rapid to find say the 131st string and of a predictable data independent time, which C strings most definatly are not. If you want to do the same in C you have to seperatly build your linked list elsewhere in memory by counting each string at some point usually not at the "natural time" when the string is created or modified. Worse you have a problem when you shorten the string if you do it the quick way by just writing in a null indicator you turn one string into two strings and that realy is a nightmare to sort out. ]]]

Try char ***string and malloc &/or realloc, instead. The construct is built at creation time, ESPECIALLY if you are processing a serial stream from an I/O source.

Easy.

Pascal string is a "poor man's" linked list? Not in my book. A Pascal string is represented in memory as a C struct

struct string {
int length;
char *str; # malloc( length );
};

Dirk PraetApril 15, 2017 12:18 PM

@ Wael

A good carpenter doesn't blame his tools. C++ allows you to define your own data types. Quit complaining and go develop your own secure classes or go cut'em from somewhere.

Hear, hear 8-)

@ fa

We have currently a generation of 'programmers' that are fully ignorant of the basics.

Which is hardly their fault but that of an industry that promotes development in C#, .Net, Java and all sorts of fancy IDE's the average nincompoop can become productive in after a 4 weeks crash course at any authorized vendor training center.

John GaltApril 15, 2017 12:57 PM

@ Dirk

[[[ Which is hardly their fault but that of an industry that promotes development in C#, .Net, Java and all sorts of fancy IDE's the average nincompoop can become productive in after a 4 weeks crash course at any authorized vendor training center. ]]]

No talent. Code completion makes them barely productive.

Try to teach C to a COBOL programmer. I have. Pointers? Their eyes get big. Pointers to pointers... and they start bitching. Pointers to pointers to pointers and the 1000-yard stare kicks in.

Clive RobinsonApril 15, 2017 1:19 PM

@ John Gault,

Not in my book. A Pascal string is represented in memory as a C struct

Singly linked lists for an incremental block of contiguous strings can use either absolute pointers or offset pointers to find the next string. Offset pointers can likewise be either from the begining of the block of strings or from the current position to the next string.

The length at the start of a Pascal string is in effect an offset pointer to the start of the next string in a contiguous block of strings. The fact that the pointer is embeded at the start of each Pascal string as opposed to a block of memory on the heap does not make it any the less a linked list in terms of ADTs.

What doing it this way does do is save memory and having to calculate a linked list when you read a block of contiguous strings into heap space from a file of Pascal strings. You can also move the block around in memory to your hearts content because the obly thing that changes is the poibter to the start of the block.

Some implementations of malloc() use a not to disimilar structure, and programers who have a good familiarity of stack based languages on minimal resource embedded systems would also be familiar with it as it alows fairly simple multitasking without the need of an MMU. Some Forth word directories are aranged in this sort of offset not absolute pointer linked list again to save quite a lot of memory (1-2 bytes of RAM per word which is a lot when you only have a couple of Kbytes of RAM in an 8bit embedded system for the user dictionary).

One of the problems I have with CS graduates is exactly this problem of only seeing an ADT like a linked list in either some rigid form they had to right code for in their first year, or worse in some abstraction form where they only understand one type of pointer...

It's generaly not a problem with assembler level programers because they know intimately what a pointer realy is, as opposed to the mess of data type size abstraction mathmatics you find in C which usually confusess the bejazzers out of nascent C programmers.

John GaltApril 15, 2017 2:56 PM

@ Clive

[[[ Singly linked lists for an incremental block of contiguous strings can use either absolute pointers or offset pointers to find the next string. Offset pointers can likewise be either from the beginning of the block of strings or from the current position to the next string. ]]]

I'm not sure what you mean -- "Singly linked lists for an incremental block of contiguous strings". WTF? Why would you need a singly linked list for a block of strings (aka vector)?

You are describing nothing more than a variable length record. Save yourself the hassle and build a separate index into it.

I have no clue why you are trying to do what you are trying to do. Makes no sense.

I wouldn't allow myself to get into that situation to begin with. I'd shoot the guy that created the file. I would've normalized the file at creation; or, I would've deconstructed it when I buffered it. And, if I can't buffer it, I'd use ASN1 to define it and save me the trouble.

I define linked lists in Pascal just like I declare linked lists in C. There's always a separate pointer element... not just a length prefix. I'd never use a linked list to format an array, either. Arrays do not equal a linked list -- totally different animals with totally different purposes.

Saving 2 bytes ain't worth the trouble. I don't care what platform it's on. It's an example of unsafe coding -- aka job security. Use ASN1 instead and save yourself a heap of trouble. Pun intended.

RE: FORTH... FORTH is a totally different animal, too. Another subject for another day.


John GaltApril 15, 2017 3:52 PM

@ Clive

PS... Alternative... use a paging system just like those that are used internally in databases like MS/Sybase SQL Server or Oracle. Everything is a variant that has to fit inside a fix sized page.

My InfoApril 15, 2017 5:32 PM

There are just too many ways to skin a cat in C++, and not all those ways are logically consistent. The wheel has been reinvented too many times. The axle is running out of grease and about to catch fire in the middle of the prairie and the horses are spooked.

ab praeceptisApril 15, 2017 5:54 PM

Clive Robinson (4/15/2017 8:02 AM)

I'll let others discuss other high level methodologies such as formal proofs and why they don't sit well on C/C++ but do on other OO HLLs. ...
My feeling was of an "opportunity lost" to sort out Cs problems before you dump a load on top.

Well, you've already put the dagger where it hurts (and well deserved).

To put it even harder: No matter how intelligent stroustrup is, c++ is an example of what happens when a doubtlessly intelligent man hasn't understood some of the basic principles of his field.

Vulgo: The more complex something is the more important proper verification becomes.

I won't get into the discussion of whether c++ achieved its goal and/or whether c++ is a better/more useful/more [insert favourite property] C. It's not even needed for a "death sentence".

Plus: C's problem was not lack of modelling capability. One *could* and *did* model pretty much everything one needed. A higher abstraction level was, at best, a nice to have gadget.

What, however, *was* - and is - C's (relevant here) problem was its ambiguity, its "hands on" hacker attitude towards a proper definition and standard.

Granted, had stroustrup first cleaned up C and used that proper C version as foundation for c++ he would have lost the desired acceptance and crowd for his new c++ thing because it would have been sufficiently different and many would have rejected it for being "too stringent" and "too different".
Strong indication that my take is right: The lifetime of the serious "better C" attempts was always very limited and they were condemned to a life in the exotics department )although some of them were excellent - but that just never was the priority in the C world).

Can we statically verify C and c++? Nope. There have been many attempts and about the best that was achieved are "civilized guessings". Oh and add the plethora of pragmas and other creatures of the diverse inhabitants of the compilers zoo.
Just look at LLVMs toy. Cute but worthless. And those guys are doubtlessly brillant and they are ideally placed, too. The best they can ever hope to achieve is self compliance.

Object orientation wasn't the problem, nor was it urgently desired or needed (nor was it well done, being at that).

John GaltApril 15, 2017 6:17 PM

@ ab praeceptis

[[[ What, however, *was* - and is - C's (relevant here) problem was its ambiguity, its "hands on" hacker attitude towards a proper definition and standard. ]]]

Actually, that's C's strength and keeps it viable for all of eternity. It's well defined primitives cover everything you need. If for some reason the CPU mfrs invent another primitive, they'll include it in their reference C compiler.

Pascal SETS is the only thing that's not built-in to C. (SETS are the thing I miss most.)

My experience is that those who have difficulty with it are not well-versed in abstract thinking -- like COBOL programmers.

ab praeceptisApril 15, 2017 7:08 PM

John Galt

For a man who "knows" and talks everything about everything and who says to have millions of lines of code and decades of experience under his belt, you miss quite a lot.

"I'm not sure what you mean" - Well, then read again what Clive Robinson explained to you and try to understand it (as well as the beauty of ADTs).

More importantly, though ...

"Actually, that's C's strength and keeps it viable for all of eternity."

It seems you haven't understood what this place is all about: security.

Our interest is not in language wars. When we look at languages here then we do that from a certain perspective, namely that of security.

What you just stated, Pardon me, paints you as an idiot - in *this* context which is the relevant here. Somewhere else, for instance at "C rulez! Hacking for life!" you might be a hero.

You like it or you you don't, I don't care, but fact is that we can't build safe and reliable software unless we can verify it (and unless we design, model, and specify it in the first place, all of which is pretty much detested in the "C rulez foreva!" crowd.

Well noted, I do *not* say that C is worthless sh*t and evil! As most here know by now, I sometimes use it myself for certain small parts of code. But I do that well knowing about its weaknesses and taking proper care to avoid them and to carefully verify my code.

All in all: You may be a smart guy and you may have lots of experience and you may feel to have good reasons for liking C; that's all fine with me. But unless you achieve a certain maturity and a healthy level of respect for what this here is all about (as well as for the people here who care about that and who are certainly no less smart than you) you won't get traction, let alone respect.

John GaltApril 15, 2017 8:00 PM


@ ab

[[[ You like it or you you don't, I don't care, but fact is that we can't build safe and reliable software unless we can verify it (and unless we design, model, and specify it in the first place, all of which is pretty much detested in the "C rulez foreva!" crowd. ]]]

Let's just say I am tired of your sh!t, too.

C was and is for portability. "Security" is a system feature... not a language feature. Period.

What? You don't like it? Talk to Intel, AMD, and Motorola.

They are directly behind the prevalence of C as a systems programming language because they are the ones who have to provide basic toolsets that people like myself can deal with.

Someday, you'll comprehend the genius of the status quo.

John GaltApril 15, 2017 8:13 PM


@ ab (by the rules... In English)

PS. Bottom line is this: You want "politically correct" language. You don't want the F word it. You don't want the N word in it. You don't want blah blah blah.

Guess what? It ain't gonna happen. There's ~415,000 words in the English language and most people only work with 10,000 or less of them.

Same goes for computer languages.

C is complete... like the vowels in the English language.

John GaltApril 15, 2017 9:18 PM

@ ab

PSS One more thing:

Case in point: Java.

Do you know the history of Java and why Sun created it?

What was Sun promoting?????? I bet you don't even know.

RISC processors in a world dominated by Intel.

The JVM was designed as an attempt to subvert the Microsoft/Intel dominance with basically a software-based Sun RISC artificial CPU (aka JVM)

It didn't work.

Java is a joke on the American people. It's a backdoor into your system. You even have to run a/v software against stuff that can infiltrate your JVM.

Only a few of us know the real design behind the "compile-once; run-anywhere" *feature* of the JVM. LOL.

Security? Or, Spyware?

ab praeceptisApril 15, 2017 9:22 PM

John Galt

For the sake of fairness: You are talking into the void. There is no discussion between you and me. You are disqualified.

Have a nice day

John GaltApril 15, 2017 10:50 PM

@ by the rules...

Here: Converse with Wikipedia

This is on point with Clives "problem"... Which is also what I pointed out. (Shoot the person who creates a "file" like that.) Also, ... abstraction is not a part of ISO Pascal. You must be using Delphi.

At least I know what "safe language" means to you, now. Now for Nick to chime in as to what a "safe language" is (I suspect he'll say BASIC or Logo or Python)

Early criticism

While very popular in the 1980s and early 1990s, implementations of Pascal that closely followed Wirth's initial definition of the language were widely criticized for being unsuitable for use outside teaching. Brian Kernighan, who popularized the C language, outlined his most notable criticisms of Pascal as early as 1981, in his paper Why Pascal Is Not My Favorite Programming Language.[33] The most serious problem described in his article was that array sizes and string lengths were part of the type, so it was not possible to write a function that would accept variable length arrays or even strings as parameters. This made it unfeasible to write, for example, a sorting library. The author also criticized the unpredictable order of evaluation of boolean expressions, poor library support, and lack of static variables, and raised a number of smaller issues. Also, he stated that the language did not provide any simple constructs to "escape" (knowingly and forcibly ignore) restrictions and limitations. More general complaints from other sources[22][34] noted that the scope of declarations was not clearly defined in the original language definition, which sometimes had serious consequences when using forward declarations to define pointer types, or when record declarations led to mutual recursion, or when an identifier may or may not have been used in an enumeration list. Another difficulty was that, like ALGOL 60, the language did not allow procedures or functions passed as parameters to predefine the expected type of their parameters.

Most of Kernighan's criticisms were directly addressed in the paper "The Pascal Programming Language",[35] specifically, under Myth 6: Pascal is Not For Serious Programmers.[36]

Despite initial criticisms, Pascal continued to evolve, and most of Kernighan's points do not apply to versions of the language which were enhanced to be suitable for commercial product development, such as Borland's Turbo Pascal. As Kernighan predicted in his article, most of the extensions to fix these issues were incompatible from compiler to compiler. Since the early 1990s, however, most of the varieties seem condensed into two categories, ISO and Borland-like.

Extended Pascal addresses many of these early criticisms. It supports variable-length strings, variable initialization, separate compilation, short-circuit boolean operators, and default (OTHERWISE) clauses for case statements.[37]
]

name.withheld.for.obvious.reasonsApril 15, 2017 11:30 PM

Goslings' objectives were clear, not to you all as you weren't there, I was.

I argued for a P-Code standard that was to augment the X509.3 "infrastructure", I say that in quotes deliberately. At the time it was understood, before CORBA, that an open directory, Distributed Computing Environment (DCE), would require some sort of heterogeneous support for Large Scale Distributed Computing (loosely coupled). One method to support that type of infrastructure was to have "STUBS" that could be inherited as advertised in a DCE environment.

CORBA was the chosen model and Java (some effort at Beans by IBM proved fruitless--pun intended) proved to be a quasi-competitor at the time. No one really understood a clean model for using the DCE environment that could provide a robust infrastructure for massive parallel computing in a heterogeneous environment. It still does not work today.

As in most efforts to reach computational nirvana, not understanding the end point, competing egos, and tech selective, not solution selective, resulted in an inferior solution!

And so it goes...

name.withheld.for.obvious.reasonsApril 15, 2017 11:39 PM

I will argue that Stroustrup was on the right path...his job as they say was not to fix C, but to provide a way forward. The ANSI committees and those whom with which the truth (in its subjective form) came to kill it--failed (luckily).

Death by committee is sometimes a welcome result (though a lot of work). Stroustrup understood, better than most (except for Wirth), how valuable true object oriented programming could and can be. He was careful, methodical, and I will argue, complete, in both his thesis and operational models. None here can come to the table with the caliber he demonstrated in rethinking programming whilst not tossing every C programmer out there under the bus.

Truly, C++ done correctly is a most invaluable tool--the pity is few people other than Stroustrup knows what that means.

ab praeceptisApril 16, 2017 12:36 AM

name.withheld.for.obvious.reasons

Kindly note that I neither said, stroustrup was stupid nor that c++ is pure crap (although, in my minds eye and in my field it is).

This blog is about security. In another blog, say about games development, c++ might be considered reasonably as a great language.

In the context of security, safety, reliability, however, any statement about these properties is all but worthless unless it can be proven. This boils down to verifiability.

To be of any value, the statement "this code is safe" must necessarily be based on "this code is *verifiably* safe and actually has been verified successfully".

Let's look at other languages that were already there ... Risking to be boring, the typical (Wirth & derivates) range construct for variables basically boils down to a domain specification.

arrival_day : range 1..31;

does tell both the compiler and the verifier about an important property of that variable, namely about a \elem N : 0

int arrival_day;

does *not* provide that information. Sure, one might #define MIN_DAY 1 and MAX_DAY 32 and then explicitly test (theoretically. It's usually not done) but that doesn't necessarily tell the compiler, let alone the verifier about the variable's domain.

So, one will end up making and verifying ACSL or similar annotations - well, will one really? Using a language that is beloved for being terse and saving on key strokes? I have doubts and there are vast amounts of code out there as unpleasant evidence.

As for OO: Not meaning to rob stroustrup of fame and praise but when he started his work OO was basically all but a completed story and there were quite some OO languages out there, most of them certainly not worse and probably even better than c++.

So I stick to what I said: stroustrup did OO for the C family. *That* is his merit (and I have no desire to taint that. As I said, I think he is a very intelligent man, just not one of any major significance for safe software).

John GaltApril 16, 2017 12:50 AM

[[[ I argued for a P-Code standard that was to augment the X509.3 "infrastructure", I say that in quotes deliberately. At the time it was understood, before CORBA, that an open directory, Distributed Computing Environment (DCE), would require some sort of heterogeneous support for Large Scale Distributed Computing (loosely coupled). ]]]

P-Code strips your control over your own CPU. It cannot be trusted. The augmentation was promoted by self-interest. JavaOne was release not long after that.

I probably know more than you think I know about X509, open directories, and LSDC.

http://www.javaworld.com/article/2076467/sun-to-take-wraps-off-java-appliances-chip.html


[[[ CORBA was the chosen model and Java (some effort at Beans by IBM proved fruitless--pun intended) proved to be a quasi-competitor at the time. No one really understood a clean model for using the DCE environment that could provide a robust infrastructure for massive parallel computing in a heterogeneous environment. It still does not work today. ]]]

Yup. It doesn't work. Wanna know why?

[[[ I will argue that Stroustrup was on the right path...his job as they say was not to fix C, but to provide a way forward. The ANSI committees and those whom with which the truth (in its subjective form) came to kill it--failed (luckily).]]]

C doesn't need to be "fixed." I wish I could say the same about a few other languages, tho.

It was meant to be portable... and, it is. Mission accomplished.

[[[ Stroustrup understood, better than most (except for Wirth), how valuable true object oriented programming could and can be. He was careful, methodical, and I will argue, complete, in both his thesis and operational models. None here can come to the table with the caliber he demonstrated in rethinking programming whilst not tossing every C programmer out there under the bus. ]]]

1) Read my comments about "buzzword" OO and C++ above... I was wading in the trenches of swamp water. C++ domain is for GUIs. I don't think Android people want to learn C++. Java is now being ousted by browsers for the reasons I already cited, above. (Spyware)

2) Look at it this way: NAME ONE standard BUSINESS data "object" (that means something to an enduser) that works across all platforms from phones to desktops to servers to "cloud" (more servers) and across all software platforms and across all industries, today???

Why does everyone have their own version of everything?

We also went thru the "EDI" stuff in the early 90s. Guess what came out of that? Lots of pieces of paper that nobody reads.

3) The problem isn't "rethinking programming"... The problem is the ENVIRONMENT that we gotta program in.

Sorry, but "cloud computing" ain't the answer. It's the dumbest answer.

Wanna try to do a massive enterprise system on an Android? Tada! That's what someone had in mind.

You won't see me twiddling my thumbs on an Android.

SO... because the powers that be didn't get to create their new world programming order, they decided to become spies, instead.


ab praeceptisApril 16, 2017 12:55 AM

name.withheld.for.obvious.reasons

Apologies, being html stupid, I'm walking again and again into that trap.

The domain property I talked about should evidently be a \elem N : 0 < a < 32

name.withheld.for.obvious.reasonsApril 16, 2017 1:29 AM

@ ab praeceptis, John Galt
I make no arguments for or against C++, I will defined Stroustrup's genius and his decisions. Yes John, security is not a language--it is a process. I do believe I answered my own question but it may has been confusing as I used it as a rhetorical device (often lost in translation as they say). Interesting in hearing what you have to say on the subject.

I understand where both of you are coming from, and it is a pity that again, superior solutions are left wanting. I am a big fan of formalism, in its true form--not pseudo or quasi versions.

Before "cloud computing" the idea of using massive parallelism was the system designers panacea. That is not a statement about the original vision. I agree, the raft of BS that has subjected the designers' "stream" is nothing but "EVIL".

No designer today can hope to be successful if in the supply chain all elements must be scrutinized to a discrete (state machine) model.

We are all invariable subjected to a more than a doubtful result...

name.withheld.for.obvious.reasonsApril 16, 2017 1:36 AM

@ John Galt

Never implied that C needed to be fixed, I said the Stroustrup's job was not to fix it...

I am tool agnostic--selecting a tool to do a job is backwards. Selecting the right tool to do the job is... Anything can be used as a hammer, though the results will vary.

John GaltApril 16, 2017 1:47 AM

@ anonymous (the man with no name.... hmmmm.... Mad Max?)

Before "cloud computing" the idea of using massive parallelism was the system designers panacea. That is not a statement about the original vision. I agree, the raft of BS that has subjected the designers' "stream" is nothing but "EVIL".

1) Get the GD govt out of it. Send the NSA/CIA on holiday. Give them estates in French Polynesia or Afghanistan and early retirement as a reward for their "service."

No designer today can hope to be successful if in the supply chain all elements must be scrutinized to a discrete (state machine) model.

2) I've visited with Dr Bowles -- The man behind UCSD Pascal... the P-Code System... FINANCED BY THE NAVY. (That's the real reason most of those Java patents were worthless... PUBLIC DOMAIN... as the swindled Larry Ellison found out. It's treated like above top secret.)

Bowles almost lost his job over all the fluff around the P-System.

Hence... I replay #1.


We are all invariable subjected to a more than a doubtful result...

I know what the answer is. And, there's a way to achieve it. But, we gotta put certain orgs in figurative handcuffs to get it done. I'll leave it at that, for now.

John GaltApril 16, 2017 1:54 AM

@ anonymous Mad Max

I am tool agnostic--selecting a tool to do a job is backwards. Selecting the right tool to do the job is... Anything can be used as a hammer, though the results will vary.

I have my toolbox, too. I'm not limited. And, I'm not afraid to pull out something new and/or that's better suited for the task and goals of /whatever/;

TatütataApril 16, 2017 5:47 AM

I close my eyes imagine a place where the more obnoxious participants could either voluntarily retreat to or be exiled, and where they would pursue their "intellectual" journey with their worthy brethren. A natural name for such a place could be "Atlantis" or "Mulligan's valley".

On the usenet there was such a place, which was called the "killfile". Many clients also implemented the threaded model of exchanges, where one could simply type "I" to ignore a given thread. This was especially useful when the critters would crawl out of the idiot box under a mutated identity.

Re. The CMU guidelines.

Whom is the following advice directed to?

CON50-CPP. Do not destroy a mutex while it is locked

CON53-CPP. Avoid deadlock by locking in a predefined order

CON56-CPP. Do not speculatively lock a non-recursive mutex that is already owned by the calling thread

CON43-C. Do not allow data races in multithreaded code

I'm sure there is somewhere in there a brilliant recommendation on the lines of "do not attempt to dereference a pointer to deallocated memory"... Yep, I just saw it: "MEM50-CPP. Do not access freed memory"

But I don't see any advice on the lines of "lock mutex only when the data necessary for interacting with the resource are ready and validated. Keep the critical section as short as possible, and do not lock simultaneously lock more mutexes than absolutely necessary."

Dirk PraetApril 16, 2017 6:15 AM

@ John Galt

Try to teach C to a COBOL programmer. I have. Pointers? Their eyes get big ...

In some distant past, I made the transition myself from RPG (II,III,/400) and COBOL on IBM midrange systems to C, C++ and others from there. It indeed was an entirely different beast. But it's not any different than adapting to another culture or learning a (spoken) language with different roots than your own. Some people will only manage to become conversational, whereas others will also try to learn the grammar and subtle intricacies. Which is not just a matter of skills, but also of motivation.

In my observation, there's different types of programmers. There's the amateurs who know just enough to hack some source code, make minor modifications and get that to compile. There's those only in it for the money writing code as if they were flipping burgers but couldn't care less that they're actually serving up rat meat. And then there are the artists with a passion for their job, who treat both their toolkit and creations like a musician does his instrument and songs, always striving to achieve higher levels of tradecraft mastery.

Without going into the religious debate surrounding programming languages, every single one of them both has its strengths and its weaknesses, and for any given application domain will be either more or less suitable and depending on the proficiency of the writer. From where I am sitting, it's kind of a point(er)less debate invariably stirring up strong emotions.

That said, I think I owe you a beer. Yesterday evening, I was looking into why some of the geeklets on a recently upgraded Mac were not working anymore. Turned out Apple had changed the default sudo behaviour in Sierra as well as the logging subsystem. Then on some forum I spotted a little snippet with your name that was an ideal replacement for the defunct code displaying the most recent Time Machine backups. So if that's you, thanks for that 8-)

Clive RobinsonApril 16, 2017 10:55 AM

@ Dirk Praet,

Just hiding from the barbecue fug and had a flick through the comments when I saw,

In my observation, there's different types of programmers

You left out that important sub class from the code cutters and artisanal types, the proffessional engineer. I know they are rarer than hens teeth in the sausage machine that is the software industry and FOSS, but their often hidden work is very much the work the world realy runs on with zero defect and uptimes measured in years.

You can recognise a few from the fact they were either hard scientests or engineering trained and brought the correct methodology mentality with them. They tend to be comming into or middle aged or above, usually with families --though late starters-- and actually try to work 9-5 with few or no code meetings. Oh and their code is useually commented in a way where you can read the comment and be informed rather more than the by the actual code, and thus any engineer could pick it up and not even be familiar with the language or methodology in use. It's kind of a mark of respect to those that follow, worn almost like a badge of honour.

Though they don't turn out the lines of code a day that code cutters do, their code generaly needs few if any bug fixes or maintanence that is not upgrades and specification change fixes...

John GaltApril 16, 2017 1:02 PM

@ Clive

[[[ Oh and their code is useually commented in a way where you can read the comment and be informed rather more than the by the actual code, and thus any engineer could pick it up and not even be familiar with the language or methodology in use. It's kind of a mark of respect to those that follow, worn almost like a badge of honour. ]]]

I've been doing it that way forever. I had seasoned IBM system programmers tell me I wrote textbook code when I was a novice.

BTW, it's the "IRA hunters" that like having all of those meetings. [see below]


@ Dirk

[[[ That said, I think I owe you a beer. Yesterday evening, I was looking into why some of the geeklets on a recently upgraded Mac were not working anymore. Turned out Apple had changed the default sudo behaviour in Sierra as well as the logging subsystem. ]]]

You'll enjoy SystemD, too.

I still do quite a bit of textmode curses stuff.... Why? How often are UIs changing now??? The latest, greatest, "gadget"???? Your browser, maybe?

GOAL: Longevity.

[[[ In my observation, there's different types of programmers. ]]]

Yup. Out of a group of ~100, I'd salute 5 of them. The rest thought they could live off their CS degrees for the next 50 years expecting that piece of paper to cash out like an IRA.


[[[ And then there are the artists with a passion for their job, who treat both their toolkit and creations like a musician does his instrument and songs, always striving to achieve higher levels of tradecraft mastery. ]]]

I play classical guitar, too. And, my "hero" ... Andres Segovia. He's the reason I started down the classical route.

I'm even recording my own eulogy for that future day... my sole public performance of a suite Segovia recorded early in his career ... that he commissioned from another composer... and it took me 25 years to locate a copy of the sheet music -- ON EBAY (!!!).

On some unknown future day, at my own funeral, I will have the last word. I will not permit anyone to get up behind a podium and say, "Mr Galt was ... and his systems... blah blah blah." Just sit down, shut up, and listen.

Now, go home and have a beer.

;)


WaelApril 16, 2017 1:22 PM

@John Galt,

I will not permit anyone to get up behind a podium and say

For me, it doesn't matter what they say when I'm alive, let alone after I expire. Live long and prosper :)

Opinions are like ... everyone's got at least one of them. Some have more than one (because they got torn a new...)

John GaltApril 16, 2017 2:37 PM

@ Tatütata (translation: With Sirens Blaring)

[[[I close my eyes imagine a place where the more obnoxious participants could either voluntarily retreat to or be exiled, and where they would pursue their "intellectual" journey with their worthy brethren. A natural name for such a place could be "Atlantis" or "Mulligan's valley".]]]

This is BLOG. Not USENET. My comments will disappear into the abyss of the blogsphere in due course.

However, I got your attention, didn't I? But, you have to assign a label the messenger... because you know that my siren is louder than yours -- because it's the truth; and, not your lie.

Now, whether or not those of you who are in a better position to actually "fix" the "environment" in which we all live is up to you. If you choose not to... just remember that farmers grow your wheat for your bread because, chances are, you can't do it yourself. You'll starve.

Furthermore, you won't ever forget that there was someone here the with the balls to say it the way it really is.

Mission accomplished.

Dirk PraetApril 16, 2017 3:10 PM

@ Clive

You left out that important sub class from the code cutters and artisanal types, the professional engineer.

They are a rare breed indeed, and I learned I lot from such types. I still do.

@ John Galt

I play classical guitar, too.

I'm a bass player myself.

ATNApril 16, 2017 4:02 PM

In C, you have to define everything, in terms of memory space and each operations to execute. In my domain C++ has lasted a very short time, to go back to C.
In which language can we program current multiprocessors with memory cache and virtual addresses? Obviously, you have to be able to say in that language those things:
- pack those variables in a single cache line
- do not put those counters in the same cache line, they may be incremented by different processors
- the cache line size of that data is defined in the PCI device description, it is variable
- those variable updates should not go through the write buffer, delay the execution if necessary
- those variables have to be in the same physical page, cannot cross boundary
- change properties of physical page, deal with variable page size, copy on write
- those two addresses are pointing to the same data
- this is user mode multi thread, obviously we cannot use a semaphore for performance reasons.
Most/all languages refuse to even acknowledge the current state of processors.
Seems that I need to stay with C for a long time...

My InfoApril 16, 2017 8:46 PM

Cue the artisanal boutique code cutter and classical music lover... Oh, that's right, we're talking about Donald Knuth. We'd better be careful about that one.

Nick PApril 16, 2017 11:48 PM

@ ATN

That's an interesting list. I don't know anything that goes that far. The parallel languages I saw are a bit more high-level. Those included X10, Chapel, and recently ParaSail (Ada-based).

name.withheld.for.obvious.reasonsApril 17, 2017 12:12 AM

@ ab praeceptis

Apologies, being html stupid, I'm walking again and again into that trap.

The domain property I talked about should evidently be a \elem N : 0

Non necessary--I share your sense of things. In fact, your statements always make me think of Prolog or Smalltalk. Am I wrong in thinking you've spent some time in this type of code-space?


Regards

ab praeceptisApril 17, 2017 12:49 AM

name.withheld.for.obvious.reasons

Well, Prolog (in the Eclipse incarnation) as well as xsetl just happen to be very useful tools in our field. Plus they are excellent links between math (algorithms) and code (implemented algorithms). I frequently find that my variable definitions are but a transformation of what I have already done in, say Prolog.

Sure, some modelling tools can offer that, too, but in a less comfortable way (for my taste) and muuuuuch slower.
Experience has (painfully *g) taught me to research the relevant domains and algorithms in better ways that using some (java based. yuck!) sepc/modelling tool.

Dirk PraetApril 17, 2017 4:10 AM

@ John Galt

Styles? Preferences?

While for most bass players - including myself - Jaco Pastorius is the pole star, some of my personal favorites include Steely Dan's Walter Becker (for his virtuosity on both bass and guitar) and, of course, Charles Mingus. In a rock 'n roll context, that would be Flea (RHCP), Phil Lynott (Thin Lizzy) and Lemmy Motorhead. And then there's Bootsy Collins, Larry Graham, Louis Johnson, Bernard Edwards ...

On classic guitar, I'm a huge fan of the work of Django Reinhardt and Heitor Villa-Lobos.

Dirk PraetApril 17, 2017 5:46 AM

@ Rachel

Les Claypool?

Definitely. Fits right in with Lemmy and Phil Lynott.

AlastairApril 17, 2017 11:32 AM

@Nick P

"We'll start with Burroughs ALGOL"

Ah, but that's cheating ;-)

Burroughs ALGOL was designed for a stack-oriented, segmented, tagged-word architecture machine which was designed alongside the language. It is pretty tough to write unsafe programs in it, because the hardware itself prevents array overflows and stack underflows.

That said, it's still not safe. Unless the language (and hardware) has fundamentally changed in the, oh gosh, forty-some years since I had my hands on a B6700, you can do denial of service type attacks on it.

Fork bombs are obvious. Another trick is to construct a circular linked-list and force the hardware LLLU (linked list lookup) instruction to run on it, which it will happily do until the hardware instruction timeout interrupt kicks in a second or two (I don't recall the exact number, and it's probably changed in the A-series) later.

(Aside: the LLLU op is there to implement the OS's first-fit memory allocation algorithm. Memory is variable-sized segments, not fixed-size blocks.)

Of course the variants DCALGOL and ESPOL are deliberately unsafe. How many languages have a built-in array called MEMORY[] that lets you address the entire machine?

That said, it is a relatively safe language/OS/architecture. The only way I ever figured of doing a privilege escalation involved tricks with reading/writing Burroughs backup format tapes on non-Burroughs hardware. There's an easy fix to that which I'm sure was long since implemented -- just require that a compiler reloaded from backup be manually tagged as such from the console.

(For those unfamiliar with the Burroughs system -- the tagged architecture made it physically impossible (at the hardware level) to execute code, a file could only be designated as a code file by a compiler, and a compiler could only be designated as such by a privileged OS command. In various corners of the web you can still find a paper I wrote on it 35 years ago, which cropped up in a number of college computer architecture classes. First hit if you google my name and B6700.)

AlastairApril 17, 2017 12:00 PM

@ John Galt

"ALGOL? You gotta be kidding. Pascal was derived from the ALGOL line. Python is today's FORTRAN.

Pascal started as the UCSD P-System. (Predating Java. Derived from ALGOL) Been there; done that. (I stamped out bugs in the Microsoft Pascal Libraries)"

So many misconceptions.

First, he was talking about Burroughs ALGOL, not ALGOL. If you weren't even aware there was a difference, you're not qualified to comment. (See my above post.)

Second, Pascal DID NOT start as the UCSD P-System. That came much later. The first Pascal compiler was written (in Pascal) by Niklaus Wirth at ETH Zurich, it was a slightly more than 3000 line, recursive-descent compiler which targeted CDC 6000 (and later Cyber) series mainframes. In college (mid-70s) we learned a variation of it called Moltex (Molto Expressivo) in CS 201, but since we didn't have a compiler for it (no CDC mainframe) we did assignments for that class in PL/I *shudder*

The P-system came some years later, and Pascal was already mutating.

ADA of course was the result of a (penultimately) four language competition for a DOD standard language, one of the requirements going in was that it look Pascal-like.

(Side note: For my sins, I once had to teach C++ to a bunch of ADA programmers at Lockheed-Martin for a project. I used to teach a course in APL at college. I'm not sure which was worse. ;) )

John GaltApril 17, 2017 12:26 PM

@ Alastair

>>> Second, Pascal DID NOT start as the UCSD P-System. That came much later. The first Pascal compiler was written (in Pascal) by Niklaus Wirth at ETH Zurich, it was a slightly more than 3000 line, recursive-descent compiler which targeted CDC 6000 (and later Cyber) series mainframes. In college (mid-70s) we learned a variation of it called Moltex (Molto Expressivo) in CS 201, but since we didn't have a compiler for it (no CDC mainframe) we did assignments for that class in PL/I *shudder*

You are arguing semantics.

Why?

Pascal was 'introduced to the world' (that is.... you and I) as the P-System.

Prior to that, it was still stuck in a Lab. The P-Code system, itself, more-or-less officially started at Burroughs.

Pascal was introduced as "THE" P-System (P-System == P-Code + Pascal) and was 'accidentally' put into the public domain in the late 70s (~77ish?)

Note your own comment.. "no CDC mainframe"

John GaltApril 17, 2017 12:59 PM

@ Alastair

[[[ (For those unfamiliar with the Burroughs system -- the tagged architecture made it physically impossible (at the hardware level) to execute code, a file could only be designated as a code file by a compiler, and a compiler could only be designated as such by a privileged OS command. In various corners of the web you can still find a paper I wrote on it 35 years ago, which cropped up in a number of college computer architecture classes. First hit if you google my name and B6700.) ]]]

Note... the birth of Java ;)

Java is basically Pascal IV. They removed the begin/end statements (probably because C programmers don't like typing Begin/End);

Nobody wanted to admit that at the Google/Oracle patent trial. Consider the "accidental" public domain status of the P-System. There lies the real reason Sun wouldn't try to enforce patents because they knew, deep down, they'd lose.

Unfortunately, Oracle/Ellison either didn't realize it or David Boies (the atty that raped Bill Gates via email) gave him bad advice.... while David Boies was affiliated with "insiders" (aka Al Gore) ... to cause Larry to cough up $~7 Billion for the "value of Java" when he bought Sun.

It's a good example of how crazy certain people in the tech industry really are.


Nick PApril 17, 2017 1:36 PM

@ all re Burroughs & secure HW/SW schemes

Architecture of the Burroughs B5000

Capability-based Computer Systems

Intel i960

Those are among the best of the old days. Add KeyKOS on software side for isolation and persistence.

@ Alastair

I'll be darned if you're legitimately the author. Been sharing your essay on Hacker News, Lobste.rs, and other forums for some time. You then show up here to enlighten us. My claim on Burroughs from what I read is the stuff described in that document would've stopped most code injection that was popular for decades. At least until return-oriented programming showed up which broke a lot of models. One group claimed Burroughs tagging couldn't stop it but I haven't verified it myself. I assumed there would be DOS, misconfiguration, etc attacks with me mostly focused on stopping code injection as it's most critical. Nonetheless, it was remarkable how bulletproof Barton et al got the fundamentals *in 1961!* That's before Anderson, Schell, and Karger were effectively inventing INFOSEC. A Schell interview also said both Anderson (earliest INFOSEC guy) and person who put segments/MMU into Intel CPU's were Burroughs people. Even outside Unisys, the legacy of Burroughs lives on. :)

I was looking for a simple project for academics to rebuild on the Burroughs legacy. There's a lot of secure CPU's out there like Cambridge's CHERI and SAFE at crash-safe.org. Those are big projects, though. I thought it might be useful to take something like Leon3 or J1 cores that are GPL, add Burroughs-style checks into CPU, something for return-oriented programming, and concurrency extensions for safety. Also, if not already in Burroughs design, something for detecting & efficient response to integer overflows along lines of a pointer to error-handling code called in any given module automatically when overflow happens. Maybe underflow, too, but I rarely see those. Keep the whole thing deterministic. Target real-time Java, Ada/SPARK, Rust, Astrobe Oberon, or a Go runtime to it. Might have a nice safe/secure CPU for either embedded (eg aerospace boards) or to cram as multi-core + SMP into servers for secure, enterprise apps. What you think?

John GaltApril 17, 2017 2:19 PM

@ Nick

[[[ I was looking for a simple project for academics to rebuild on the Burroughs legacy. There's a lot of secure CPU's out there like Cambridge's CHERI and SAFE at crash-safe.org. Those are big projects, though. ]]]

Try this (a complete system with a safe CPU): I gifted mine to a possible child prodigy a few years ago. I think I gave him a copy of the C compiler that I created for it, too. I didn't build a linker, tho. It was a VROM based system. Complete with 9900 Assembler, too.

(At one time, I even had a 3 MB HD for it.)

Embedded system.

http://www.ebay.com/itm/Texas-Instruments-TI-99-4A-system-4/122209887826?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D40130%26meid%3D16b1e908c8484dfc8a5a0b7fec4b0a46%26pid%3D100005%26rk%3D3%26rkt%3D6%26sd%3D172621676552

http://www.ebay.com/itm/Texas-Instruments-P-CODE-INTERFACE-CARD-PCODE-PHP1270-TI-99-4A-TI99-WORKS-/152504743545

http://www.ebay.com/itm/Texas-Instruments-TI-99-4-Peripheral-Expansion-System-Model-PHP1200-/172621676552

http://www.ebay.com/itm/Texas-Instruments-TI99-4-Peripheral-PHP1260-32K-x-8-Memory-Expansion-Card/172628965729

http://www.ebay.com/itm/Texas-Instruments-TI-99-4A-system-4/122209887826

[tracking code stripped from links by moderator]


ab praeceptisApril 17, 2017 6:40 PM

Alastair

"I once had to teach C++ to a bunch of ADA programmers at Lockheed-Martin" - I hope that those responsible for that decision ended up in jail. Did they?

On a more serious note: That little side note of you shows well, albeit brutally, what and where a major problem is: Greed and/or utter incompetence in the management of both governmental and enterprise antities.

AlastairApril 17, 2017 6:52 PM

@Nick P

Yep, that's me (usually when I post here it's under my initials).

We had a dual-CPU B6700 as our (academic) campus mainframe back when I was in school. (We also had an IBM 360/50, primarily for admin use but a select few courses had access to it for packages only available for the 360). Between what these days would be called dumpster-diving and social engineering, I had a code listing of the OS (MCP) and a stack of manuals on the architecture and systems programming languages for it. (Plus, one of the campus systems guys wrote a paper on the architecture of Burroughs codefiles that I had a copy of.) Later I worked for the Computer Centre part time.

Shortly after the B6700 paper appeared in Computer Architecture News (I was working at a different college at the time, that one did have a CDC mainframe) I got a call from a senior guy at Burroughs (don't recall the name off the top of my head, sorry) and we had an interesting discussion about the system.

As far as tagging stopping code injection, I think it would. (Well, that and the segment descriptor, also tagged.) The tag bits were not accessible to normal code. They were assigned by the hardware when a segment was loaded. The descriptor specified (among other things) how long a given segment was in memory, whether it was writeable, etc. Attempting to modify a code segment, either by extending it or changing its content, would throw a hardware interrupt.

As I mentioned above (and in the paper), only a compiler could make a file executable. File permissions went beyond what most people are familiar with too. To some extent they were something like the extended permissions that SELinux has. Burroughs also had the concept of a "guardfile", which could (if assigned) exert fine-grained control on the guarded file's permissions, including which specific programs (not just users) were allowed to access it.

This on a system designed in the 1960s - early 1970s.

Yes, there are probably ways to subvert that (especially if there were implementation errors in the MCP) but they generally would require physical access.

The restriction on what is code and what isn't breaks down with interpreted languages, of course, which many of today's popular languages are. (I include anything that compiles to software-interpreted bytecode in this.) The same hardening could be made to apply by (a) sandboxing the interpreter and (b) incorporating many of the above concepts into the design of the interpreter (which might be tricky with some languages).

I've been out of that particular specialty for a long time. Partly I've given up on properly secure hardware ever gaining traction with the ubiquity of x86 and ARM. And I'll always have a soft spot for my first computer, that dual-CPU B6700. (Sure, technically it was the university's, but I totally pwned it. ;) )

John GaltApril 17, 2017 7:12 PM

@ Alastair

[[[ I've been out of that particular specialty for a long time. Partly I've given up on properly secure hardware ever gaining traction with the ubiquity of x86 and ARM. And I'll always have a soft spot for my first computer, that dual-CPU B6700. (Sure, technically it was the university's, but I totally pwned it. ;) ) ]]]

Microcode Based Rootkit.

Muahaha

AlastairApril 17, 2017 7:21 PM

@John Galt

Pascal was 'introduced to the world' (that is.... you and I) as the P-System.

You're still wrong.

My first introduction to actually programming Pascal was on a CDC mainframe -- a Cyber 170 (at another university) -- long before P-systems were available. (UCSD's p-system was released in 1978, Wirth's Pascal compiler was released in 1970. The Pascal Programming Language book was published in 1973.

UCSD p-system was based off of Wirth's second version, Pascal P-2, partly by one of Wirth's students. Wirth's 1976 book Algorithms + Data Structures = Programs has the examples in Pascal, and includes Tiny Pascal compiler. It was that book, widely used as a college text (including at mine) that first introduced a generation of CS students to Pascal.

John GaltApril 17, 2017 7:35 PM

@ Alastair

FYI... Of note... UCSD p-System began around 1974 as the idea of UCSD's Kenneth Bowles,[6] who believed that the number of new computing platforms coming out at the time would make it difficult for new programming languages to gain acceptance.

Bowles was working directly with Burroughs.

Nick PApril 17, 2017 7:53 PM

@ Alistair

"As I mentioned above (and in the paper), only a compiler could make a file executable. File permissions went beyond what most people are familiar with too. To some extent they were something like the extended permissions that SELinux has. Burroughs also had the concept of a "guardfile", which could (if assigned) exert fine-grained control on the guarded file's permissions, including which specific programs (not just users) were allowed to access it."

This stuff is worth a more detailed description preferably with sources. Many histories I've seen put the file permissions in the 1970's following Titan or maybe MULTICS with MLS or capability-oriented work starting later, too. Burroughs being ahead on that would be pretty interesting if it happened. Or did that come with later versions of their mainframes from the 1970's on up?

And, of course, are you still sneaking away to the emulator for nostalgia? Or the official one?

Dirk PraetApril 18, 2017 4:07 AM

@ John Galt

No Stevie Wonder/Nathan Watts?

Undoubtedly a class act too. There's plenty of others I haven't mentioned either because the list would grow too long.

@ Clive

Carlos Santana?

Great guitar player. But like Clapton he should just play and shut up 8-) While nobody even comes close to Hendrix, I guess my personal favorite to date remains Eddie Van Halen because for unknown reasons his style resonates with me like no other. Really nice guy too. I once had a drink with him in a bar in LA where he had overheard me speaking Dutch to someone.

ab praeceptisApril 18, 2017 4:16 AM

Dirk Praet, John Galt (@Moderator)

I love music, I really do, and I wouldn't say anything about a quick exchange but this is growing wild.

Would you kindly respect the topic of the thread and/or carry that guitar/bass non-discussion over to the friday squid?

John GaltApril 18, 2017 4:30 AM

@ ab aka "by the rules"

Dirk Praet, John Galt (@Moderator)

I love music, I really do, and I wouldn't say anything about a quick exchange but this is growing wild.

Would you kindly respect the topic of the thread and/or carry that guitar/bass non-discussion over to the friday squid?


LOL

Do you have a list of your rules available that we can post here somewhere? They seem to be a moving target. Or do they change with your mood?

Don't forget your list of "seniority/tenure laws of respect" so we can all know. (I note you didn't address @ Clive in your temper tantrum.)

Night nite...


ab praeceptisApril 18, 2017 4:51 AM

John Galt

a) it's not my rules but those of our host.

b) I didn't mention Clive Robinson because his value to noise ratio is doubtlessly on the excellent side while that of some others is regrettably poor.

Clives contributions here, unlike yours, are always worth to be read.

AlastairApril 18, 2017 11:02 AM

@Nick P

This stuff is worth a more detailed description preferably with sources. Many histories I've seen put the file permissions in the 1970's following Titan or maybe MULTICS with MLS or capability-oriented work starting later, too. Burroughs being ahead on that would be pretty interesting if it happened. Or did that come with later versions of their mainframes from the 1970's on up?

It may well not have been introduced until their later systems. The B5000 goes back to the early 1960s but there were a number of improvements that went into the large systems Bx500 (B5500,B6500) and Bx700 (B5700,B6700,B7700). It was certainly there by the early 1970s.

I'm afraid I don't know how much of that old documentation I still have, and most of it is probably buried.

Thanks for the links to the emulators. I did once boot up the Hercules S/360 emulator and managed to get it to compile a simple PL/I program, which was enough to remind me how little I really missed that particular beast. Burroughs at least had CANDE.

Come the revolution, IBM and Microsoft will have a lot to answer for. ;-)

AlastairApril 18, 2017 11:14 AM

@Nick P

I did find a reference to this:

[57] H. Bingham, "Access controls in Burroughs large systems," Privacy and Security in Computer Systems, Nat. Bur. Stand. Special Pub. 404, pp. 42-45, Sept. 1974. (II-C3)

in the following:

For example, the Multics system [55] uses software-interpreted access control lists together with hardware-interpreted tables of descriptors. Similarly, the "guard file" of the Burroughs B6700 Master Control Program is an example of an access controller implemented interpretively [57].

from "The Protection of Information in Computer Systems" (1974) here: http://web.mit.edu/Saltzer/www/publications/protection/

Googling "burroughs guardfile" turns up a number of interesting references, most more general.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.