Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues (zdnet.com)

Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. From a report: Memory safety is a term used by software and security engineers to describe applications that access the operating system's memory in a way that doesn't cause errors. Memory safety bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses. Users who often read vulnerability reports come across terms over and over again. Terms like buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free -- all describe memory safety vulnerabilities. Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs.

Comments

A stupid term

[Anonymous Coward]

whoever is accounting for these phrases will certainly consider the use of literals in source code. I suppose bounty hunters would like to reclassify perfectly good code as bugs but to no avail

Re:A stupid term

[Anonymous Coward]

...Are Memory Safety Issues...

...which is why, in programs that I write, I don't use any memory at all.
Only sissies use memory - real men use just the CPU's registers and a
little stack space, and maybe parts of the BSS segment -- but that's all.

Hell, when I started programming, memory didn't exists. You write right to
the HD platter and had to time your code so that the data would be under the
head at the point in your code that you needed it again.

strcpy()!? Who need that nonsense - if you weren't smart enough to know
where the string was supposed to be to begin with, you had no business coding.
Anything else is just lazy. And buffered I/O? Give me a break - I did all of my
terminal I/O in raw mode.

#--

So now that we know the obvious as stated by MicroSoft, the real question is,
and IMHO more interesting, what comprised the remaining 30% (aside from
hardware issues like Intel's CPU bugs) of the bugs? Cause, honestly, I would
tend to think that all security bugs would be in that category, right?
Unless they are blatantly obvious bugs like skipping a password check, or
something like that - things that normal (regression) testing would uncover.

CAP === 'passion'

Meaning

[fahrbot-bot]

Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

They can't remember how to code safely. :-)

Re:Meaning

[willaien]

True. Part of the issue is that some languages easily lets you develop programs that don't use memory safely. C/C++ easily let you develop applications that violate memory safety.

You have to be constantly vigilant, and everyone else who develops for the same project has to be constantly vigilant. Mistakes will happen, and nothing will call you out on it unless you do extensive memory safety testing or configure and use some tools that help detect common memory safety issues and hope that you catch anything they don't.

Re:Meaning

[willaien]

Large systems require a lot of developers, and even the best developer can have a bad day and make a mistake that potentially exposes their application to various memory exploits. Sometimes you have to pay the tax of having better developers, more tools, etc. to make the applications safer.

But, in general, as processors get faster, memory amounts in modern computers gets higher, we should move away from such languages except for projects that require them.

Re:Meaning

[fahrbot-bot]

If you have good coders, this is pretty much a non-issue.

And time/resources to think things through, review and revise before pushing it out the door.

Re:Meaning

[Anonymous Coward]

I bet you have zero evidence or knowledge of the competency of Microsoft developers.

Also, it is evident from the discussion here that that vast majority of the participants have very little knowledge about computers, programming languages.

Re:Meaning

[kalpol]

C/C++ gives you CONTROL. If you don't have enough knowledge to use it properly, use something else. It's as if you can't drive a car, you are probably going to hit a tree. But if you can drive, you have whole areas open up to you for exploration and increases in productivity.

Re: Meaning

[Anonymous Coward]

No itâ(TM)s not a non issue.. they find vulnerabilities every day.

Re:Meaning

[willaien]

Ooh, analogies!

Did you know that modern cars have more safety features, meaning that you're much less likely to die in a collision in a modern vehicle, due to things such as airbags, seat belts, crumple zones, automated braking, etc.?

Just like modern, higher level languages give developers enough access to much of the system without requiring you to worry as much about memory safety, most car drivers don't need drag racers to get to work.

Re:Meaning

[Anonymous Coward]

Rolling coders gather no Rust.. wait, are we suggesting that Microsoft migrates to Rust!? Rewriting Microsoft C++ code base in a memory safe way would probably be almost equivalent task. I wonder if anybody has even tried to use the new recommendations in kernel code at this point.

Re:Meaning

[Anonymous Coward]

Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

The other 150% are design/architecture issues, and the rest are math errors.

Re:Meaning

[epine]

C/C++ easily let you develop applications that violate memory safety.

The modern C++ idiom easily lets you develop applications where you barely touch memory safety yourself, and competent libraries (such as the STL) do all the hard lifting.

C does not let you do this in any natural way.

If you wish to write your own RAII-compliant classes, you do need to book off half a day to watch (and digest) this series of three videos: CppCon 2014: Jon Kalb "Exception-Safe Code, Part I"

Outrageous investment? Well, it's your life.

Re:Meaning

[theweatherelectric]

Ugh, another completely predictable response from a C ideologue. Ideology turns a person into a mindless fanatic. Ideology makes a person dumb.

The practical reality is that memory safety is a problem. Ideological utopias do not exist. Languages like Rust are trying to mitigate the problem of memory safety in the real world. Forget your ideology and try to find a way forward to some pragmatism.

Re: Meaning

[Anonymous Coward]

So you are saying that modern cars are less performant and hides several older cars in layers under the chassis?

Re:Meaning

[willaien]

Fair point. If you are careful to not use any of the low level memory allocation functions except in exceptional circumstances, you can easily create modern C++ applications without memory safety issues by sidestepping them entirely.

However, a lot of applications have been developed before these paradigms became common, and I'm sure that a lot of applications have been developed since by developers who didn't know any better or reject them for whatever reason and thus don't use those paradigms.

I guess my critique against C++ is against the older style of C++, the parts that are there for compatibility with C code. And against any codebases that use those.

Re: Meaning

[willaien]

My point was simply that analogies suck, because they can be flipped around on you.

If you want to continue the analogy, safety features do have costs. Either in R&D, per part costs, performance, etc.

Safety in computing has costs and trade-offs as well. Performance impact is there for managed languages, but modern computers are so much faster than older systems that the safety costs are unimportant for most applications, and the added cost of developer time greatly outweighs the much cheaper systems.

Re:Meaning

[Anonymous Coward]

That makes no sense. Why should MS be fielding bad coder problems arising from C or any other language? That's a failing application, its author needs to deal with that, in fact is the only one that really can. The question is why this is bleeding into the OS which they DO own, and thus is their own bug?

When it comes to the application, the OS should give it access to a narrow range of memory and throw page faults when it attempts to access memory out of its bounds (i. never allocate the first page at address 0x0 under any circumstances, attempts to write/read NULL are newbie mistakes everywhere. Similarly, never allocate the last page that ends at FFFF_FFFF). The combination of this would ensure the application could never touch anything it isn't supposed to, hardware ensures this is true.

Of course that is naive, applications need some system resources to function. That is where MS starts to own the problem, and why blaming it on a language doesn't make sense. It shouldn't happen in the first place, what if the programmer is intentionally doing this to spy/gain access/etc? You cannot blame the application, no matter how badly written, for what the OS does with what it's given. MS maintains one of the most confusing, abundantly poorly documented series of APIs and calls on the planet (and god help you if you need to write a device driver and don't want to pay for support tickets). That is their fault, and they can't blame anyone but themselves.

Re:Meaning

[gweihir]

That is more on the architecture and design side, but definitely has a huge impact on overall quality.

Re:Meaning

[gweihir]

As MS keeps their failings a trade-secret, nobody besides MS can have evidence. But their products pretty much speak for themselves.

Re:Meaning

[gweihir]

The ideology here is with the Rust fanatics that completely ignore that developer quality is critical, regardless of language. While C does allow you to do a lot of dangerous things, a modern compiler will warn you and a competent developer will know how to avoid most of them. The memory problems in C are a symptom, not a root cause and that is what you people consistently get wrong.

Re:Meaning

[theweatherelectric]

a competent developer will know how to avoid most of them

Re-read the title of the article. 70% of security bugs are memory safety issues. Your ideology is not working. It has failed.

Re:Meaning

[e432776]

I've had it! I'm taking all the memory out of my machine to increase its security. Hold on, brb!

Re:Meaning

[lgw]

I did low-level code for ~15 years without ever having a memory leak or memory safety bug. Not because I'm especially diligent, but because I was in areas where it just didn't come up. From primitive assembly (with no dynamic memory allocation in the first place, it's hard to screw it up) to C++ done right.

Those odd corner cases are nearly the same set of places where it still makes sense to use low-level languages in the fist place. These days, if you're creating a large C code base where you're constantly allocating and freeing resources, it's almost certainly the wrong tool for the job. OTOH, if half your variables are "const volatile" because they're really memory-mapped sensors, or you only allocate memory at startup because you can't do anything dynamic in your hard realtime system, then it's both the right tool and these memory-use bugs are barely relevant.

Re:Meaning

[Anonymous Coward]

Except that this article is about Microsoft, in general. Microsoft uses languages other than C and C++ to write their software. They have Visual Basic, C# and C++, to name a few. To say this is the fault of C and C++ is disingenuous.

Everyone in this discussion is trying to extrapolate what the article is saying by pointing to faults beyond where the article went. Unless you are able to show some research that these 70% of security bugs are caused by C/C++, you need to stop spreading FUD.

Memory safety is a universal problem in programming, and while some languages help you avoid them, non are 100% safe.

Re:Meaning

[theweatherelectric]

To say this is the fault of C and C++ is disingenuous.

Read the slides from the talk. They specifically mention C++ as a problem to be solved. And they're right.

Re:Meaning

[Anonymous Coward]

Cause everything fits on the stack... oh wait

Re:Meaning

[Pinky's Brain]

The fallibility of human beings is the root cause. You can mitigate that fallibility or maintain an absolute illusion of control.

PS. do you ride a motor cycle by any chance?

Re: Meaning

[Pinky's Brain]

In the case of ABS and traction control, yes indeed.

Re:Meaning

[byteherder]

This is just another cases of 'Dumb coders make dumb mistakes'.

News at 11.

Re:Meaning

[gweihir]

You fail on multiple levels here (no surprise):
- The article is only about MS bugs, not general ones
- A number like 70% is meaningless. At the very least a full classification as to ease-of-finding, ease-of-exploitation, access gained, etc. is needed instead.
- I do not do "ideology", I do facts. The ideology is with you people and your current great thing is nowhere near as good as you believe
- If you shift languages, you just get more bugs in other areas with bad developers, neatly removing all of your argument's basis

Seriously, you have no place in this discussion. You lack both fundamental insight and experience.

Re:Meaning

[gweihir]

It is a poor craftsman that blames his tools. And that is what is going on here.

The demented belief in finding just the one true tool that will make everything better (but never does) is as old as coding. There is no silver bullet.

Re:Meaning

[gweihir]

I don't think you can mitigate that fallibility. You can only try to get humans that have mostly overcome it in the desired application domain.

P.S.: No. Why do you ask? I am not even driving a car because I know I am a bad driver.

Re: Meaning

[Anonymous Coward]

Maybe they should become journalists?

Re:Meaning

[theweatherelectric]

It is a poor craftsman that blames his tools

A good craftsman doesn't use poor tools. Harden up and get some practicality, my son.

Re:Meaning

[theweatherelectric]

Seriously

There is nothing serious about your perspective. You have been captured by ideology. It has confused you.

Re:Meaning

[Anonymous Coward]

I bet you have zero evidence or knowledge of the competency of Microsoft developers.

Two words: Windows Ten

Re:Meaning

[theweatherelectric]

P.S.: No. Why do you ask? I am not even driving a car because I know I am a bad driver.

Ah, this then is one of the causes of your narrow world view. You need to get out in the world more. Broaden your horizons, learn some life skills, and develop some better experience. When you keep yourself narrow it's easy to end up captured by ideological positions. Without those broader experiences you have nothing to counterbalance and make obvious the faulty thinking.

When you gain some more worldliness you'll see the fault in your perspective. Good luck!

Re:Meaning

[Joce640k]

To say this is the fault of C and C++ is disingenuous.

Read the slides from the talk. They specifically mention C++ as a problem to be solved. And they're right.

C++ allows you to write safe code, much safer than C.

The probelem is C programmers calling themselves C++ programmers when all they're really doing is using a C++ compiler to write C.

Re:Meaning

[gweihir]

Like any fanatic, you are utterly convinced _you_ have the truth and nobody that disagrees with you can be right. Pathetic. You are dead wrong though, no surprise.

Re:Meaning

[Anonymous Coward]

And what language is Rust written in, pray tell?

Re:Meaning

[theweatherelectric]

You are dead wrong though

Microsoft has shown you a study which backs my claims. One of their specific recommendations is that they need to move to languages with better memory safety (like Rust).

Show me a study which backs your claims.

Re:Meaning

[theweatherelectric]

And what language is Rust written in

Rust is written in Rust, and before that it was written in OCaml. It's been self-hosted for quite some time.

Re:Meaning

[serviscope_minor]

But, in general, as processors get faster, memory amounts in modern computers gets higher, we should move away from such languages except for projects that require them.

Kind of getting unnecessary though. Type systems have advanced to the point where you can have zero abstractions and memory safety. Nothing will obviate the need for competent programmers though.

Re:Meaning

[serviscope_minor]

The ideology here is with the Rust fanatics

How about we have a sensible adult conversatio where we ignore the fanatics of any sort? Does Rust have fanatics who say stupid stuff? Yep. Does C? Oh hell yes. So does C++, python, Ruby, PHP and probably there's even a MUMPS fanatic out there if you look hard enough.

I'm a C++ developer day to day but familiar with lots of languages. I have read about Rust but neverused it in practice and aren't likely to start any time soon for various reasons. However...

While C does allow you to do a lot of dangerous things, a modern compiler will warn

Yes, a bit. Compiler warnings are getting better year on year. But they still miss a LOT of stuff. That's why we have static analyzers, valgrind and sanitizers.

The difference with Rust is it's baked into the type system so it's precise. Outside of a compiler bug (and unsafe block) you will NEVER get a use after free.
The thing is in C++ you escape those by being careful about ownership. It's still possible to slip up though.

competent developer will know how to avoid most of them.

Most, but not all. And not all of the time.

Re:Meaning

[Anonymous Coward]

If you have good coders, this is pretty much a non-issue. The problem is that MS software is written by the cheapest incompetents available.

This is a bullshit argument and nothing, NOTHING, will prevent errors other than the language's compiler catching them, if they can. If you're tired, your "good coders" become "crap coders." This goes for stupid bosses who think keeping people strapped to a desk for hours on end. People need to stop with this "good coders" crap, programmers are people and people make mistakes, having a compiler which can catch these mistakes are what you want, don't rely on people not to make a mistake.

Re:Meaning

[Anonymous Coward]

Greybeard here. We USED to have code reviews, and made good programmers, even if it was politically incorrect to use a red pen on greenbar. There is always somebody who can program better than you.

I suspect MS has gone cheap and is not employing code auditors to do the sort of thing in OpenBSD, with global replaces of defective string handling and such.

With all these Intel spectre and meltdown flaws(not a bug because someone knew, but rammed them in anyway) the results will not be pretty.

Re:Meaning

[Anonymous Coward]

Nonsense. The memory problems under discussion happen everywhere.

Re:Meaning

[Anonymous Coward]

Oddly enough he does have the truth.

There is so much evidence to support the fact that memory use errors happen all the time in all manner projects no matter who the developers are that it's amazing you can hold your position.

Pathetic, you are dead wrong and resort to insults to make your case.

Re:Meaning

[squiggleslash]

I think a good reason to suggest C is one of the worst languages is to compare it with PHP. PHP is a terrible language with obvious flaws. C is also a terrible language with obvious flaws.

But... my experience is that the average PHP programmer does actually recognize that the language they're being forced to program in is shit. They know mistakes are going to occur no matter how smart they are and that a sizable number of those will be because the language is hot garbage.

C, on the other hand, seems to attract a bizarre level of machismo, people absolutely insisting that C is the best, and the only reason why there's so much terrible C written is that the average programmer is worse than they are, because C, you know, it needs to be written by a true expert. A REAL C programmer. Programming in REAL C. Alongside REAL men, REAL women, and REAL small furry creatures from Alpha Centauri.

The only other language I can think of that attracts that level of misplaced arrogance is C++, which is kinda what you'd expect given one is an extension of the other.

Re:Meaning

[squiggleslash]

While C does allow you to do a lot of dangerous things, a modern compiler will warn you and a competent developer will know how to avoid most of them

A modern compiler will not warn you unless it's obvious. And, I hate to say this, but your use of the word "most" should have told you you're on the wrong side of this argument.

Look, C is dangerous. It's slightly more efficient than most of the alternatives, and most of the alternatives that it's speed comparable to are somewhat more awkward to work with.

The argument "But it's OK in the hands of experts" is wrong. If you consider yourself enough of an expert to write C that doesn't contain security bugs, you're exhibiting Dunning-Kruger syndrome, not expertise.

Using better languages reduces the number of bugs you'll make, regardless of whether you're a real expert or someone who just thinks they are. Part of that is because detecting the kinds of error that causes security issues will usually uncover other kinds of bugs too.

A true C expert is someone who's so familiar with its flaws they'd rather use something else, not someone arrogant enough to think their code is perfect.

Re:Meaning

[Anonymous Coward]

If only that were how it works... in the real world, you use the tools required by your employer. If you can have some input on what those tools are, then great. For the rest of us, we use language X because our boss likes X or because we have inherited code written in X.

Re:Meaning

[dgatwood]

Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

They can't remember how to code safely. :-)

Not at all. They have a huge legacy codebase. Rewriting all those strcpy and strncpy calls to strlcpy takes time.

And except for modern C++, C and C++ historically lacked reference counting, which gives you the additional joy of debugging use-after-free violations. These bugs are remarkably easy to cause and remarkably hard to detect until something just randomly crashes.

Re:Meaning

[gweihir]

He does not. The reason I can hold my position is that I am an actual expert, not somebody that can only regurgitate marketing propaganda. Sure, memory errors are a problem, but they are just a symptom and fixing them will just move the problem somewhere else, where it may do even more damage. This can only be fixed by addressing the root cause.

Incidentally, he did start with the Ad Hominem and that is what I called "pathetic".

Re:Meaning

[gweihir]

And you also do not get it. Tools are nice, but tools cannot fix bad coders. In C that is just more obvious than in Rust. Hence while Rust may offer some benefits, they are nowhere near as good as claimed because its proponents gloss over the fact that bad coders will then just make other mistakes. Now, the thing is that I have seen these claims of "great new tool will solve all problems" (I exaggerate, of course) numerous times and they _never_ pan out. Hence I am not easily impressed anymore.

What I am objecting too here is the constant misidentification of the problem and the constant wrong approaches of fixing it that result.

Re:Meaning

[gweihir]

Look, C is dangerous.

Nope. Bad coders are dangerous and they are so in any language.

Re:Meaning

[gweihir]

Well, let me clarify that a bit, since you seem to actually trying now instead of just doing the thing where you are utterly convinced to have the truth and everything else must be squashed. So:

1. Bad coders are a huge danger. They are the root-cause for most problems with security and other bugs, unmaintainable code and most of what is wring with coding today.

2. Languages are a minor issue. They can somewhat reduce problems and cost, but they cannot and will never be able to increase developer quality. There is no replacement for insight and understanding, except more insight and understanding. That said, language evolution is beneficial, but it is not anything that will be a game-changer until have strong AI (i.e. AGI), which will not be anytime soon.

3. This hyping of one language as being so much better is massively counterproductive and has happened numerous times before, with the same faulty reasoning. First, it is not true. Sure, Rust has some nice things, for example the thread-safety approach, but this is all a gradual, minor improvement in the tool. It is not a sane reason to drop everything and move to Rust now. It is not a great breakthrough. It is just some gradual evolution. And second, these claims obscure the real problem and that is that we have far too many coders with no or insufficient clue. And this problem is getting worse, for example because all these incompetents have driven down wages and really competent people rarely go into coding these days. And no, tools will not fix that or even reduce the impact from that. Bad coders are hugely expensive to society and the only thing hyping tools does is that the coders will get even cheaper and even worse because "management" thinks they now hire people with even less of a clue. Now, Rust does not make that problem worse. But the hugely exaggerated claims as to its benefits _do_ make the problem worse and that is what I strongly object to.

Re:Meaning

[serviscope_minor]

C, on the other hand, seems to attract a bizarre level of machismo, people absolutely insisting that C is the best, and the only reason why there's so much terrible C written is that the average programmer is worse than they are, because C, you know, it needs to be written by a true expert. A REAL C programmer. Programming in REAL C. Alongside REAL men, REAL women, and REAL small furry creatures from Alpha Centauri.

I like the attidude (see sibling post) that because tools can't make bad programmers good, the good programmers may as spend all thier time juggling live chainsaws because of course that makes sense.

The only other language I can think of that attracts that level of misplaced arrogance is C++, which is kinda what you'd expect given one is an extension of the other.

I'm a C++ programmer and I work with c++ programmers and oh god yes.

Is there any other language where people routinely declare that "clearly" the standard library sucks and goes and checks in their own extra uh "optimised" version of a map or whatever complete with use-after-free bugs.

Oddly enough the only other language (other than C) where I've encountered serious attitude is Python. A small segment of the community gets really hot and bothered about "pythonic" and "pure python" and just flip their shit if you write the slow inner loop in C++.

I've never encountered a JS or PHP developer with the attitude their language makes them a superior person.

My favourite are FORTRAN programmers. They look up, squint at the details of the numerics and the rounding mode, write the moral equivalent of int i,j,k,l; and then continue to write FORTRAN in whatever language happens to be in front of them.

Re:Meaning

[theweatherelectric]

I am an actual expert

You really aren't. You're just making a baseless claim and doing nothing to refute Microsoft's study.

Show me a study which supports your claim that these mythical perfect programmers will solve everything. Show me evidence. Show me data. I am waiting.

Re: Meaning

[K. S. Kyosuke]

They ported LLVM to Rust already?

Re: Meaning

[theweatherelectric]

You might as well complain about any library written in any other language that any Rust program links to. As a complaint it makes no sense. What surprises anyone that worse tools are used to build better tools. This has been true for the entire history of software development. What will you argue next? That C isn't really C because actually it's all machine code in the end, and that machine code isn't really machine code because that's not how the processor works internally?

The question was what language is Rust written in. The answer is that it's written in Rust.

Re:Meaning

[squiggleslash]

Nope. Bad coders are dangerous and they are so in any language.

So people who aren't Bad Coders(tm) never slip up and make mistakes?

Also try reading this. It explains how a typical corporate process resulted in the rug being pulled and nobody realizing code that did work correctly now had cases where it wouldn't.

Now, before you say "Sure, but that could have happened in Java or C# too!", that's true, but in Java you wouldn't have given anyone the opportunity to overwrite the stack with data and code of your choosing.

What worries me is that most C programmers think they're good programmers. The better the programmer, the more likely it is they realize they too can make mistakes. The fact there's a whole bunch of people waving the C flag yelling "C is only bad if it's programmed by people who are worse than me" is deeply disconcerting for that reason.

Re:Meaning

[squiggleslash]

its proponents gloss over the fact that bad coders will then just make other mistakes

Rust's proponents probably do not believe your apparent believe that every programmer makes the same number of mistakes regardless of what programming language they're using. They're probably of the opinion that if someone makes 11 mistakes in C, including 8 buffer overflows, they'll probably make a little over 3 in Rust.

That's a reasonable assumption, and they're probably correct. They probably won't find eight other things to do wrong in order to make up for the lack of buffer overflows.

Re:Meaning

[Anonymous Coward]

If you are using higher-level languages c#, Java, Java Script, etc. you don't get to decide what happens to memory when you are done with it. Load an encryption key into and object to access some resource then let go of the reference, you don't if or when that memory location is going to be used or by who, or if the OS is going to "zero out" that address when its done.

Just like deleting a file on a hard disk. Unless you directly set those sectors to zeros the data is just sitting there until something else comes along and writes a new value.

Re:Meaning

[gweihir]

I am not actually arguing for C. I am arguing that the Rust-crowd vastly overstates what their thing can do and that this is counter-productive. Read https://slashdot.org/comments.... for more details.

Just so you know, I am not a one-language C coder. I have done real work in Eiffel, Python, C, C++, Lua, Perl and a few others and I have tried out and would be competent to use quite a few more.

I do agree about the C coders you describe. Many do vastly overestimate their skills and hence they _are_ a serious problem. But moving them to Rust will not solve that problem, because it ts the coders that are the problem, not the language. They will still vastly overestimate their skills if they were to code in Rust. Rust is only somewhat less dangerous than C and in many regards it is just as dangerous as C. For example, all application logic errors (and a lot of security problems come from that direction these days) are just as easy to make in Rust as they are to make in C. As long as you have a general-purpose language, there is no way to make it safe to use. Pretty much the same as you cannot make a chainsaw or a gun (or a kitchen knife, for that matter) really safe to use. IT hat to be used safely, but the device itself is always unsafe because it can always be used in an unsafe manner.

Re:Meaning

[theweatherelectric]

I am not actually arguing

I agree. You aren't arguing anything. You're just making baseless claims with no data to back it. Show me a study to support the claim that your mythical perfect programmer will solve all the problems. Show me the evidence which demonstrates that you are correct.

Microsoft has shown you a study which contradicts your claim with real world data. Microsoft is the more credible source here.

Re: Meaning

[K. S. Kyosuke]

You might as well complain about any library written in any other language that any Rust program links to. As a complaint it makes no sense.

It makes no sense to complain that the inclusion of, say, a buggy C++ library could make a Rust program with its oh-so-perfect memory management vulnerable? Then why do people bother with Rust in the first place? Surely not to end up with programs mostly glued together from C++ Swiss cheese.

What will you argue next? That C isn't really C because actually it's all machine code in the end, and that machine code isn't really machine code because that's not how the processor works internally?

Non-sequitur much? How is that relevant for including buggy components in programs?

The question was what language is Rust written in. The answer is that it's written in Rust.

The more accurate answer is that a large but not overwhelming portion of it is written in Rust, compared to Go written in Go, the various Lisps written in Lisp, the various Schemes writren in Scheme...

Re:Meaning

[gweihir]

I am not actually arguing

I agree. You aren't arguing anything. You're just making baseless claims with no data to back it. Show me a study to support the claim that your mythical perfect programmer will solve all the problems. Show me the evidence which demonstrates that you are correct.

Microsoft has shown you a study which contradicts your claim with real world data. Microsoft is the more credible source here.

And now you are back to your ideology. A pity. Well, it was worth a try.

Re:Meaning

[theweatherelectric]

That's a "no" on the data then. So much for your alleged expertise. I asked you to deliver and you failed. You don't deliver because you can't deliver.

It's amusing that even in the complete absence of any evidence to support your fanciful ideas you're still a true believer in your articles of faith.

A missing null is a terrible thing.

[willaien]

I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?

Re:A missing null is a terrible thing.

[Anonymous Coward]

Was a different time - security wasn't the issue it is now, because malicious actors weren't significant.

Re:A missing null is a terrible thing.

[gweihir]

I am sure they were aware. They likely just badly misjudged the typical quality of coders.

Re:A missing null is a terrible thing.

[Freischutz]

I am sure they were aware. They likely just badly misjudged the typical quality of coders.

More likely they just didn't anticipate the degree of maliciousness we have today and they probably also didn't expect C to have such a long lifespan.

Re:A missing null is a terrible thing.

[Jeremi]

They might have, but doing so wouldn't have avoided the problem -- even with a ptr+length scheme, you're still dealing with pointer artihmentic, and so it's still quite easy to mess up and read/write outside of your buffer's bounds, if you aren't careful.

An effective fix requires language support, with the holy grail being a language where a buggy or insecure program simply won't compile, and therefore any program that does compile is much more likely to be secure/bug-free. Languages like C# and Rust are headed in that direction, although I think there is still a long way to go before we have a language that is both "safe" and efficient.

Re:A missing null is a terrible thing.

[Vlad_the_Inhaler]

I do remember one of the creators of C describing that particular decision - and it was a decision - to be their greatest mistake. I loathe that language, along with those which share these deficiencies.

Re:A missing null is a terrible thing.

[Anonymous Coward]

I loathe that language, along with those which share these deficiencies.

I loathe your loathing. If you can't code with the big boys, keep to BASIC.

I also loathe your grasp of English.

Re:A missing null is a terrible thing.

[willaien]

It would have brought a different set of problems, for sure. And we can never know what hundreds of thousands of developers, etc. would have discovered about it. But, it certainly would have made certain classes of issues pretty much non-existent.

Re:A missing null is a terrible thing.

[willaien]

To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.

I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.

Re:A missing null is a terrible thing.

[dfghjk]

Spoken like a true moron. I suppose lack of memory safety is a "decision" for processor manufacturers too. How dare assemblers not implement proper heap protection!

If you can't understand tools and how they are used, find something else. Your inability to code properly is not C's fault.

Re:A missing null is a terrible thing.

[hAckz0r]

I was just learning how wonderful the VAX Descriptor could be right when this char *c=null thing took hold in WinNT. No easy way to double check your string lengths or anything. WinNT 3.1 even pushed GDI into the kernel, and they got what they expected. Memory performance right when the memory price point was becoming really cheap, and lots and lots of memory bugs.

Somehow in my sleep, I could hear Dave Cutler screaming "Noooooooooo"!!!!!!!.

Re: A missing null is a terrible thing.

[Anonymous Coward]

Never mock someone whoâ(TM)s English isnâ(TM)t good.. they probably know more languages than you do

Re:A missing null is a terrible thing.

[Krishnoid]

Joel Spolsky has provided some background on this.

Re:A missing null is a terrible thing.

[goose-incarnated]

I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?

How does pointer+length fix a maliciously (mal)formed string?

For each string that enters the system you'll need to check the length against the data you've been given, at which point you may as well have just used a terminating NULL because the result is the same (because the length might be lying to you)

Okay, lets say that you *are* checking the length against the input - what do you do when the length is (uint64_t)-1? At that point you may as well have just used a terminating NULL anyway, because the result is the same.

Okay, so let's say that you enforce a maximum string length as strings enter the system - you can do the same with a null-terminated string too.

Any safety that a ptr+length solution gives you, you can already get from a null-terminated string currently, right now.

In fact, the null-terminated string is actually safer than ptr+length because there is only ever one source of the string's length, and that is the string itself. With a ptr+length solution there are many more opportunities for a string to have a length indicator that is different to it's actual length.

The problem isn't the existence of a null-terminated string; it's the overflows that occur because code is relying on a length that is lying about the *actual* string length (as in heartbleed), instead of (correctly) enforcing a terminator on the input (once the end of the input is reached).

The other problem is that, right now, you can validate data entering the system to enforce limits, and test the program against these limits using valgrind, but too few systems are tested this way; if they were then we wouldn't be seeing buffer overruns at all, strings or otherwise.

How many Windows C (or C++) devs actually use a Windows equivalent of valgrind? I don't know of any.

Re:A missing null is a terrible thing.

[Anonymous Coward]

Not only maliciousness, but connectedness. At the time C came along the idea of having billions of devices all talking to each other and sharing data and people maliciously targeting each other for profit rather than lighthearted joking was probably completely alien.

When C came along it was relatively rare to have people outside your own team accessing a system or being able to talk to it. When C came along if someone tried to exploit a buffer overflow you walked down to their office and told them to knock it off. The Internet forced programming to scale in a huge and, in many cases, unexpected way.

Re:A missing null is a terrible thing.

[Drishmung]

...I suppose lack of memory safety is a "decision" for processor manufacturers too. How dare assemblers not implement proper heap protection!

.

Actually, it was a decision, and some vendors made different choices. Quite successful choices.

while (*p++=*q++);
when you actually mean
p = q;
(and the idiom depends on idiosyncrasies of the PDP-11 instruction set), was a stupid decision.

Re:A missing null is a terrible thing.

[RoccamOccam]

Languages like C# and Rust are headed in that direction, although I think there is still a long way to go before we have a language that is both "safe" and efficient.

You say that like Rust isn't "safe" and efficient.

Re:A missing null is a terrible thing.

[willaien]

Not going to do a point by point breakdown of that, but, I dread to think of how expensive it would be to get the length of a string if you're considering uint64 sized strings if it were null-terminated.

Re:A missing null is a terrible thing.

[Anonymous Coward]

Kernighan is still around, why don't you ask him?

Re:A missing null is a terrible thing.

[presidenteloco]

Perhaps the requirement not yet achieved would be:
safe and efficient, and simple and comprehensible.

The former two for obvious reasons, and the latter two so that it is adopted widely for development, and so that it is maintainable.

Re:A missing null is a terrible thing.

[Anonymous Coward]

really? you do realize the string would be in ram already, so something read every single byte.
counting them in ram isn't as expensive as reading them from media or the net

so.. it would take longer and would be more impactful on very very long strings, but the issue isn't any reason that would be a problem

Re:A missing null is a terrible thing.

[Anonymous Coward]

You can never have a language that's 100% bug free since you can always have logic bugs... but languages like C# and Rust (and pretty much every language anyone uses other than C/C++ and assembly) eliminate entire classes of bugs like the memory safety issues discussed in this article. And, realistically, I suspect as slow as a language like Python is, the slowdown simply doesn't matter for a lot of applications. Rust and modern C++ matter for the few that do need speed, but mostly the parts that need to be fast can be library calls from a safe language (e.g. high-performance computing stuff gets written in Python sometimes... because the actual work is calls to numpy which is implemented in C).

Re:A missing null is a terrible thing.

[Anonymous Coward]

And I loathe your illusion that if you use C, you are a big boy coder. Your code has more bugs than anyone else's. You just don't know it yet.

Re:A missing null is a terrible thing.

[Anonymous Coward]

Lack of null termination is far less likely to be the class of problems than issues with the pointers themselves.

Re:A missing null is a terrible thing.

[Anonymous Coward]

I could be wrong but I think he is referring to a string with a max size of uint64 would be what 1667 TB in size? That is a lot of RAM to check.

Re:A missing null is a terrible thing.

[Anonymous Coward]

How does pointer+length fix a maliciously (mal)formed string?

You use a language which has these types of strings built in and it handles the usage for you. You can't overwrite the count, want to concat? Create a new string.

Re:A missing null is a terrible thing.

[goose-incarnated]

The stupid, it burns.

In fact, the null-terminated string is actually safer than ptr+length because there is only ever one source of the string's length, and that is the string itself. ... lolwut. A string (defined as pointer+length) is the string itself. The length is the only source of the string's length. There is preisely one source.

With a ptr+length solution there are many more opportunities for a string to have a length indicator that is different to it's actual length.

Yeah no one ever scribbled over a terminating null.

Please for the love of god stay away from C, you're a menace.

You don't actually know what a NULL is, do you? It's a zero dumbass. In languages like C, the zero is considered the terminator for a sequence of characters, which is what we meant by the word "string".

I think once you look up what "character", "string", "NULL", "terminated" and "length" means, you'll be a better programmer. You already show some potential.

Re:A missing null is a terrible thing.

[BadDreamer]

Heartbleed came about because the incoming string was ptr+length.

There is no security advantage at all in ptr+length. What there is, is a speed advantage. In Delphi it's known as "shortstring", and is an excellent tool for high speed string manipulation where no string will be longer than 255 bytes.

Re: A missing null is a terrible thing.

[Anonymous Coward]

Heartbleed came about because they were still doing low level memory management.

Re:A missing null is a terrible thing.

[squiggleslash]

No, he's right. There's nothing he wrote that implies he doesn't know what a null is. There's plenty that you're writing here though that shows you don't understand the problem.

There is absolutely nothing about null termination that's more secure than length+string. It's entirely possible, and indeed a common source of errors, to not put a null at the end of a string, for example:

#define BUFFER_LENGTH 4

main() {
char buffer[BUFFER_LENGTH];
char buffer2[255];
strncpy(buffer, "Hello world!", BUFFER_LENGTH);
strcpy(buffer2, " is a language called C");
puts(buffer);
}

This will, on C compilers that store everything in the most obvious way (which isn't all of them) print "Hell is a language called C". On others, it'll fill your screen with garbage. And on a handful it'll, by accident, print "Hell" because whatever data is stored after "buffer" happens to be zero by coincidence.

How is this better? It isn't! And it's not a contrived answer either, because strncpy was introduced precisely to prevent buffer overflow errors, and yet nobody noticed between implementation and standardization/release that to use it in such a way that it didn't cause overflows a programmer had to do a, usually redundant, step of sticking a null in the last element of the destination buffer, just to make sure that if the string was too long, it was still a string.

Yes, null termination is so bad that even the experts at ANSI couldn't figure out how to fix it properly. (IIRC it was the OpenBSD people who introduced the world's first safe string copying function as a standard - in the very late nineties, 15-20 years after C first appeared. FIFTEEN FUCKING YEARS. FIFTEEN to SAFELY COPY A STRING. Do you have ANY idea how terrible that is?

Re:A missing null is a terrible thing.

[goose-incarnated]

No, he's right. There's nothing he wrote that implies he doesn't know what a null is. There's plenty that you're writing here though that shows you don't understand the problem.

There is absolutely nothing about null termination that's more secure than length+string. It's entirely possible, and indeed a common source of errors, to not put a null at the end of a string, for example:

#define BUFFER_LENGTH 4 main() { char buffer[BUFFER_LENGTH]; char buffer2[255]; strncpy(buffer, "Hello world!", BUFFER_LENGTH); strcpy(buffer2, " is a language called C"); puts(buffer); }

This will, on C compilers that store everything in the most obvious way (which isn't all of them) print "Hell is a language called C". On others, it'll fill your screen with garbage. And on a handful it'll, by accident, print "Hell" because whatever data is stored after "buffer" happens to be zero by coincidence.

How is this better? It isn't! And it's not a contrived answer either, because strncpy was introduced precisely to prevent buffer overflow errors, and yet nobody noticed between implementation and standardization/release that to use it in such a way that it didn't cause overflows a programmer had to do a, usually redundant, step of sticking a null in the last element of the destination buffer, just to make sure that if the string was too long, it was still a string.

Yes, null termination is so bad that even the experts at ANSI couldn't figure out how to fix it properly. (IIRC it was the OpenBSD people who introduced the world's first safe string copying function as a standard - in the very late nineties, 15-20 years after C first appeared. FIFTEEN FUCKING YEARS. FIFTEEN to SAFELY COPY A STRING. Do you have ANY idea how terrible that is?

I said:

How does pointer+length fix a maliciously (mal)formed string?

And you display how a maliciously malformed string is a problem!

My entire post was on strings entering the system - once it's in and validated you don't have more problems with null-terminated than with ptr_length. Before it's in, you have all the same problems with null-terminated than with ptr+length.

Using ptr+length doesn't buy you anything unless you trust the length, in which case you may as well trust the null-terminator.

That snippet you posted has a bug because the length indicator was wrong.

Re:A missing null is a terrible thing.

[Freischutz]

To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.

I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.

True, but C has also suffered from stagnant development and downright neglect. C could have benefitted immensely from some project like the C++ boost project whose features get integrated into progressive C updates a long time ago.

Re:A missing null is a terrible thing.

[Anonymous Coward]

That should be 'terminating NUL'. Not NULL. NULL is a macro for use with pointers.

Re:A missing null is a terrible thing.

[squiggleslash]

And you display how a maliciously malformed string is a problem!

Nope. There is no maliciously malformed string in my example. I processed it presuming it might be too long, and used what ANSI considers the correct function to copy it to an array of known size.

My entire post was on strings entering the system - once it's in and validated you don't have more problems with null-terminated than with ptr_length.

I just gave you an example of how a built in ANSI function has problems outputting valid null terminated strings. strncpy wouldn't have worked the same way with a length+characters approach because it wouldn't have made sense, it would have had to put \3HEL (or \3\0HE) to be placed in the buffer, not HELL. (Of course, because strings would end up being a type, it'd be more like:

string *buffer = newstring(BUFFER_LENGTH);
strncpy(buffer, "Hello world!", BUFFER_LENGTH);

and newstring would have returned something in the form:

struct {
int length;
char text[4];
}

and so you'd still have HELL in text[] but length would be set to 4. Of course, my hypothetical C variant we're talking about would actually also have a buffersize property in the struct it returns so functions like strcpy can actually know from the start how big the destination is.

Using ptr+length doesn't buy you anything unless you trust the length, in which case you may as well trust the null-terminator.

No, that's not how any of this works. ptr+length works because you generally know there is a length to begin with. You do not know there is a null, at least, not one at the end of the string. You can safely presume the length is correct because there's no reason for it to be wrong. An off by one error isn't going to cause the length to be omitted.

I gave you an example of how a simple off-by-one error can cause a string to buffer overflow if you're using nulls. This is an error that cannot occur in a ptr+length environment. Can you, conversely, think of an error that can occur in a ptr+length environment that wouldn't occur in a null terminated string environment?

Also, just throwing it out there, serviscope_minor didn't mention it, but I thought I will because TBH it's an even bigger flaw, but how do you handle it when there's a null in the middle of your string? I've always hated null termination for that reason, it reminds me of the old CP/M and DOS issue where text files couldn't contain a ^Z otherwise it'd be treated as the end of the file.

Also (while I'm on it), don't you find it a pain to have to use strlen each time you want to append strings to one another?

I mean, I just find it surprising anyone's saying "No, I must defend null terminated strings!" rather than "Oh yeah, another reason why they're shit and C is terrible."

That snippet you posted has a bug because the length indicator was wrong.

No, the length was right. The length is the size of the buffer. The buffer has four characters. It's 100% correct.

Re:A missing null is a terrible thing.

[strikethree]

C was designed to be more of a shorthand for assembly rather than a high level language.

There is no string type in C. The C Standard Library functions that are string-related have to assume that the pointer you pass will be a pointer to a null terminated array. Those Standard Library functions could have been set up so that they accept a length argument... and in fact, some functions do accept/require a length element. strncpy() is one such function.

C is perfectly fine. The C Standard Library could use some attention, but C is fine AND it is not going anywhere until something can actually replace its functionality. Seeing as how all replacements proposed so far are actually higher level languages, I don't see C getting replaced any time soon.

The problem with creating a replacement for C is that no matter how you design the language, it will still be a weapon of mass destruction in the wrong hands. How could it not be?

Ignorant people seek to kill C. But the language they write their C killer in is... wait for it... C.

Complexity is inescapable. Skill is non-replaceable.

You can wish for a nice warm steak to be in front of you, but I guarantee it will NOT happen without a cow getting murdered, sliced up, and cooked. You can wish for the nastiness to go away, but it will always be there. You either deal with it, write in C, or you try your best to avoid, by using a higher level language than C... but that higher level language was likely written in C.

There is a price to be paid for quality programmers. People seem to be trying VERY hard to avoid that price, but look at what we get for that price: Hardware that is less effectively LESS powerful than the 8.5Mhz 68000 CPU that used to provide an awesome computing experience.

You know, they can't actually pay for good programmers though... they are not willing to pay for management than can recognize and promote quality programmers.

So we get a screensaver in Windows 10 that activates even when a full screen video game is active when this problem was solved several decades ago in Windows 98. Microsoft isn't even wearing clothes anymore and nobody seems to care. Their (Microsoft's) shame is on perfect display for anyone to see... and for some reason, everyone gives them a free pass. WTF?

TL;DR, No. Brian Kernighan and Dennis Ritchie would likely have not changed C just to make hiring easier on the corporate types.

Re:A missing null is a terrible thing.

[willaien]

16 exabytes, actually.

Re:A missing null is a terrible thing.

[willaien]

I can think of no valid reason why you'd ever want to have a string as large as 16 exabytes and think it's ever a good idea to have to walk the entire thing to figure out its length.

Re:A missing null is a terrible thing.

[willaien]

Edit: Even if you can evaluate 4 billion characters per second, you're looking at 146 years to calculate the length of that string.

Re:A missing null is a terrible thing.

[willaien]

I feel like there's a fundamental misunderstanding of what ptr+len means.

It means that all of the c api's functions would be based around this idea. So, for example, "get_s()" would return a structure containing the length of the string and a pointer to the first character. It means that "str_concat()" would take in two of these structures and return a new one, etc. (or, some idiomatic c equivalent of these things).

Exactly how do you think that a "malformed string" would get in that lies about its length? It's not like we'd be relying on the input to tell us the length, the function calls would create the char* and tell us how long it is.

Re:A missing null is a terrible thing.

[willaien]

And, yes, I realize that you can certainly write code that creates malformed strings. The point is that the standard C library itself would have memory safety built into its own handling of strings.

Re:A missing null is a terrible thing.

[dgatwood]

They might have, but doing so wouldn't have avoided the problem -- even with a ptr+length scheme, you're still dealing with pointer artihmentic, and so it's still quite easy to mess up and read/write outside of your buffer's bounds, if you aren't careful.

Yeah, but other languages that existed at the time (Pascal) had run-time bounds checking, and there's no reason C couldn't have done that too, with the addition of a slightly richer string syntax. Though they couldn't have anticipated the long-term security implications of that decision, the folks who created C knew that it was a tradeoff. They chose a slightly smaller footprint (no length bytes) and slightly better performance over robustness.

Re:A missing null is a terrible thing.

[Anonymous Coward]

I feel like there's a fundamental misunderstanding of what ptr+len means.

It means that all of the c api's functions would be based around this idea. So, for example, "get_s()" would return a structure containing the length of the string and a pointer to the first character. It means that "str_concat()" would take in two of these structures and return a new one,

There's nothing stopping the committee from doing so now with null-terminated strings, but they haven't done so.

It's certainly possible to write a safe 'get_s()' function that returns a null-terminated string, or a safe 'str_concat()' that takes two null-terminated strings and returns an allocated new string that is also null-terminated. Adding in a length indicator for all of these strings doesn't help.

Re:A missing null is a terrible thing.

[Anonymous Coward]

No, the length was right. The length is the size of the buffer. The buffer has four characters. It's 100% correct.

Actually, no, poster has a point. The standard (poorly, IMHO) specified that the strncpy result may not be a string and the caller has to terminate it in that case. This is a failure of the standard. What makes you think that they would have gotten the specification correct for ptr/length strings? After all, the strncpy function does no allocations hence the equivalent in ptr/length strings will also not do any allocations and will rely on the destination string being large enough, failing which the ptr/length strncpy() will have to truncate the destination.

This doesn't make it right, obviously, but the fact that it is perfectly possible to specify a strncpy() that always produces null-terminated strings doesn't provide any support for ptr/length strings being superior in this particular case.

After all, you are arguing that the standard would have specified a perfectly working ptr/length strncpy. If they were capable of doing that they would have perfectly specified the null-terminated strncpy.

Re:A missing null is a terrible thing.

[Anonymous Coward]

Apparently you aren't aware a number of successful operating systems (you should look up that term) are written in C. You apparently can't write good code in C. Too bad. Many of us can and do.

My old enemy...

[Anonymous Coward]

... the missing null terminator.

Re:My old enemy...

[Thud457]

the missing null terminator .

"I won't be back..."

-- or --

"Listen, and understand! That Terminator is not out there! It can't be bargained with. It can't be reasoned with. It doesn't feel pity, or remorse, or fear. And it absolutely will not stop... ever, until your program is dead! "

So create standards-compliant functions MickeySoft

[Anonymous Coward]

The C Standard added Annex K, Bounds-checking Interfaces in an effort to address this.

Every see all those "sprintf() is deprecated" misleading error messages from Visual Studio? The ones that make you think that functions that are required by the C standard are "deprecated"?

Well, Microsoft on the surface seems to be pushing you to use those "safer" Annex K functions? No, not really. They're pushing you to use Microsoft's bullshit versions. Per the C committee:

Field Experience With Annex K — Bounds Checking Interfaces

...

Microsoft Visual Studio

Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1. For example, it doesn't provide the set_constraint_handler_s function but instead defines a _invalid_parameter_handler _set_invalid_parameter_handler(_invalid_parameter_handler) function with similar behavior but a slightly different and incompatible signature. It also doesn't define the abort_handler_s and ignore_handler_s functions, the memset_s function (which isn't part of the TR), or the RSIZE_MAX macro.The Microsoft implementation also doesn't treat overlapping source and destination sequences as runtime-constraint violations and instead has undefined behavior in such cases.

As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable.

So, MickeySoft, just STFU about memory problems when you use them as nothing more than an excuse to push your proprietary version of C on the population.

Memory Footprint

[Anonymous Coward]

The careless use of memory creates a larger attack surface. When Chrome is capable of using all of the machine's available memory, it creates a huge attack surface for whatever today's web exploit is.

There is currently no way to limit the memory used by any browser. They will all happily consume whatever is available, and sometimes never give it back.

I've had to resort to creating a VirtualBox with 1GB of memory running Devuan just to constrain web browser memory usage. This has the added benefit of confining attacks.

Re:Memory Footprint

[Anonymous Coward]

32GB in my laptop. Chrome is using 600MB and ive done nothing special. It hardly consumes all available ram.

Re:Memory Footprint

[sexconker]

32GB in my laptop. Chrome is using 600MB and ive done nothing special. It hardly consumes all available ram.

Yeah, but once you OPEN Chrome it'll use 6 GB.

Re:Memory Footprint

[Anonymous Coward]

it's not hard at all to place a limit for memory usage on a process group
for example, a quick search shows this howto:
https://www.rittmanmead.com/blog/2015/12/using-linux-control-groups-to-constrain-process-memory/

Re:Memory Footprint

[Anonymous Coward]

There was that time I upgraded to 8GB RAM while still using 32bit linux, this constrains firefox processes to 2GB RAM and firefox was using only two processes then (or three maybe, if that were two firefox and one plugin-container)

16GB RAM, 64bit CPU with BIOS or UEFI+CSM, 32bit linux might be a good machine for browsing and still having some RAM left.. But the browser might still behave very badly when a process bumps against the 2GB limit (browser's memory management goes into some sort of damage control mode and gets slow, performing heroic acts for the browser to not blow up). It did that with two-process firefox.

Well damn! There's the probrem!

[Anonymous Coward]

You let user programs access the operating system's memory? You big dummy! What the fuck is the matter with you people? Stop it!

Microsoft has VERY poor management, apparently.

[Futurepower(R)]

Microsoft never knew how to code safely, apparently. One of the many, many stories:

Microsoft Admits Normal Windows 10 Users Are 'Testing' Unstable Updates (Dec. 12, 2018)

This is about MS bugs, not general ones

[gweihir]

Why they do not have that under control is puzzling. Well, not really, this is MS, after all.

Re:This is about MS bugs, not general ones

[Anonymous Coward]

Have you looked at the security release notes for a linux distro lately. Its all memory safety bugs there too. This is a C/C++ issue not a Microsoft Issue.

Re:This is about MS bugs, not general ones

[Anonymous Coward]

Queue in someone saying "Microsoft needs some Rust"

Re:This is about MS bugs, not general ones

[gweihir]

You seem to be unaware of the scales here: A typical Linux distro will have > 1000 applications. MS does not even make that many. And no, it is not all memory safety. This is an MS issue.

Re:This is about MS bugs, not general ones

[gweihir]

Those idiots. Tools will never fix bad coders.

Re:This is about MS bugs, not general ones

[Austerity Empowers]

It's an MS issue, look at the article, MS is fixing the bugs. You can bet your ass they're not fixing other people's bugs. If their API code is not up to dealing with bad applications (intentional or malicious) then it really is their bug. *Most* of the apps with horrible security issues that require immediate fixes on other OSes are running with some level of enhanced privilege. On Windows... who the hell knows, apps run with escalated privileges just because they ask and the user hits yes. That's a real problem that MS can't seem to fix.

Doesn't help if you remember

[SuperKendall]

They can't remember how to code safely. :-)

The problem is, even if you know full well how to "code safely" all it takes is one slip, or some interaction with another part of the system you didn't fully understand, and you are done.

That is why for most things, sadly languages that allow such slip-ups simply have to go. We cannot live like this forever in a world of chaos where any system of any size is just moments away from disaster or infiltration. As an industry we have to somehow ratchet ourselves forward, even if only a little bit.

Re:Doesn't help if you remember

[Anonymous Coward]

sadly languages that allow such slip-ups simply have to go

So by that you mean C.
C++ does provide strong support for dealing with these problems-- RAII, smart pointers, threading libs etc. are all there and have been there for years and years.
Rust provides extremely strong support built into the language for dealing with these problems.
Neither of these sacrifices performance (much if at all) compared to C to achieve these things.

But what about managed languages you ask?
Java has famously had security issues.
C# has had security issues.
Both are "fast" compared to scripting languages but not even remotely fast enough to take over C's domain.

Haskell and Go are faster than scripting languages but they're just too slow to truly compete with Java or C# let alone Rust, C++, and C.
It goes without saying that scripting languages don't work here.

If you're serious about fixing these security issues then you're talking about:
1. rewrite everything in Rust or very good C++ or some other language that is provably secure and just as fast as the C that these things are written in (so expensive and time consuming that it's practically impossible)
or
2. figure out and write a provably correct and secure tool that can prove that code is either secure or insecure (literally impossible)
or
3. grow up and realize that there always have been, always are, and always will be security bugs and that the mature reaction is to find and fix them as they come up and not to scream and shout and wring your hands and demand that Something Be Done. You know those situations where there's several people in a small boat and they're cruising over some waves and doing ok, but then some retard panics because the boat's rocking a little bit and stands up and starts running around the boat and then capsizes it? That's what's going on here. Just be cool and deal with the problems instead of panicking and making things much worse in a different way.

And that's it. There are no other options.

Re:Doesn't help if you remember

[Austerity Empowers]

I will give up C when you pry it from my cold dead fingers. The solution is not to ban languages the youngin's don't like, the solution is for MS to stop releasing crap. It's one thing when application developers write code with bugs, it's a whole other thing to release an OS with bugs. MS should really be abandoning Windows and trying to figure out how to either use Linux or to go the way of Apple and adopt BSD and try to be able to take in changes.

The world does not need that many operating systems, it needs to put its weight behind one good one. End users don't even know what an operating system is anyway, all they see is the UI. The UI can be crappy corporate code, the damage can be contained on that fairly easily.

Re: Doesn't help if you remember

[MemeRot]

In what way is Golang not fast?

I'm not a fan. But it's faster than c# or Java.

Re:Doesn't help if you remember

[theweatherelectric]

MS should really be abandoning Windows and trying to figure out how to either use Linux

Seems like a bad idea. In 2018 the top 6 products with the most security flaws were all Linux products. How do you account for that?

Re: Doesn't help if you remember

[Anonymous Coward]

Golang is nice but each EXE carries around it's own garbage collection. Some applications need to utilize their own GC, borrow it from a library, use a common instance, or don't do it at all.

Re: Doesn't help if you remember

[Monster_user]

Uhm, first one with 900+ vulnerabilities is Debian. What they don't indicate is what branch or branches of Debian is included. Debian is not a single release, but a system. There is the "stable" branch, which is supposed to be secure, and is akin to Windows 10 LTSB (or Windows 7). There is the unstable branch which is more current and akin to the Windows 10 Deferred channel. Then there is the Testing branch which is akin to Windows 10 Insider Preview, and isn't expected to be secure.

The question is whether these 900+ vulnerabilities are 300 duplicated vulnerabilities for each branch, or whether they are more heavily biased towards the testing or stable branches.

Once you get past Debian and Android, the next ones are at around the 300 mark, and Windows 10 is in the top ten.

And if you really want to compare Linux, not that RedHat Enterprise Linux is much further down the list than even Windows Server, much less Windows 10.

Re:Doesn't help if you remember

[SuperKendall]

1. rewrite everything in Rust or very good C++ or some other language that is provably secure and just as fast as the C that these things are written in (so expensive and time consuming that it's practically impossible)

That is exactly what I am saying. You say it's too expensive. How many billions of customers must be hacked until it is considered viable? How much system downtime, lost or corrupted data, cooperate secrets leaked forever?

We can't do everything at once but we could also do at least a think bit more than letting companies swing in the wind by agreeing to produce new systems we know are inherently insecure.

That's why I am saying we must make SOME effort to ratchet security to the better, no matter how small. A journey of a billion trillion miles still begins with a single step.

Re:Doesn't help if you remember

[Anonymous Coward]

John Carmack is a better coder than most of us.
When he brought in a static analysis tool it found a ton of memory bugs in his code.
I'd wager that a large % of the bugs in Linux and BSD are also related to common c/c++ memory allocation issues.
Memory management issues are not simply limited to "bad" coders or Microsoft.

Re:Doesn't help if you remember

[Anonymous Coward]

It is pretty old news by now that nobody can do manual memory handling without making mistakes. What I find the most interesting is the fact that even if you rewrite all programs (like so many like to advocate) then there will still be 30% of security exploits left.

As you said it yourself, it only takes one slip for the system to be done. If we spend all that money rewriting and still don't solve the problem it can be argued it wasn't worth the expense. Even if it did reduce the attack vector by 70%.

Besides, nowadays I'm more afraid of what upper management decides to include into the system on purpose than any mistake the engineers do. Sometimes it could even be considered a feature that you can crack it.

Re: Doesn't help if you remember

[serviscope_minor]

Uhm, first one with 900+ vulnerabilities is Debian. What they don't indicate is what branch or branches of Debian is included.

plus debian comes with a lot of non critical stuff, applications, out of the box.

Re:Doesn't help if you remember

[Austerity Empowers]

I do not know how many vulnerabilities would exist if we included everything that uses the MS ecosystem as this does with Debian, it would be a very large number. Suffice it to say those are not the bugs MS is talking about MS fixing.

There were 775 Windows 10 vulnerabilities in 2018, there were 604 "Linux Kernel" vulnerabilities in 2018 (which kernels, and how many were affected by the largest set of these, is unknown, but by definition 604), there were 385 FreeBSD kernel vulnerabilities in 2018.

MS is releasing the most crap. If you add in how much redesign they are going to have to do to make Windows 10 functionally equivalent to Linux or BSD or OS X, and how many bugs you can expect with that fresh code, the answer is to give it up. Focus on Linux or BSD, throw their shitty UI on top of it if they must to keep the droolers happy. Get one good OS out of it, and focus their weight on fixing problems rather than designing new, and then fixing new. OSes have little monetary value, they're too "boring" to sell to consumers.

The best choice would be Linux, while it still has the larger # of vulnerabilities of the two other options, it is the most active, and it would enable MS to not be the exclusive set of eyes on their OS. If MS gave up on their bullshit OS and focused on hardening linux, they could cut down the # of issues they have to chase and solve on their own significantly. Everyone benefits.

Re:Doesn't help if you remember

[squiggleslash]

The solution is not to ban languages the youngin's don't like, the solution is for MS to stop releasing crap

If you've reached an age where you feel you can describe Rust users as "youngins" and you don't see the value in Rust and the problems with C, then there's a serious problem.

(Besides, nobody's taking your C compiler away from you or talking about that - they're talking about not using it any more for code you need to be able to trust. There is absolutely no reason on Earth for a replacement TCP/IP stack, web browser, or email client you switch to be written in C. There are safer alternatives that are just as efficient. If you want to write them in C, go ahead, just expect thinking people to want alternatives to your implementation written in safer environments.)

C's flaws are obvious. Why do people feel the need to pretend it's OK? You don't Slashdot flooded with apologists for PHP every time a Wordpress vulnerability gets publicized.

Re:Doesn't help if you remember

[theweatherelectric]

I do not know how many vulnerabilities would exist if we included everything that uses the MS ecosystem as this does with Debian

So you're saying Debian's development, packaging, and distribution model is fundamentally flawed from a security point of view? That doesn't inspire me to use Debian.

There were 775 Windows 10 vulnerabilities in 2018

There were 255 Windows 10 vulnerabilities in 2018. I don't know where you're getting 775 from. You're probably confusing it with the "all time leaders" vulnerability counts. If we look at the all time leaders, Debian is number 1 and "Linux Kernel" is number 2.

Re:Doesn't help if you remember

[Anonymous Coward]

So umm which Windows 10 kernel - to use your argument. They update that on a somewhat regular basis too. I think you're argument is an uphill battle but GLWT.

Re:Doesn't help if you remember

[Anonymous Coward]

Linux is mostly written in C...

MS's Jim Allchin...

[QuietLagoon]

... didn't he once say that Microsoft addressed the memory security issues in Windows? Maybe 15 years ago?

Re:MS's Jim Allchin...

[drinkypoo]

... didn't he once say that Microsoft addressed the memory security issues in Windows? Maybe 15 years ago?

Microsoft developed and provided all the tools you'd need to avoid the problem, and then apparently never bothered to use them themselves.

Quality Control

[Zorro]

They have heard about it and almost completely wiped out Quality AND Control.

Re:Quality Control

[Anonymous Coward]

MS has a very large suite of tests that, in theory, should pick up many of these bugs. So MS needs to go back to the drawing board and rethink these tools.

This is not new

[MobyDisk]

This has been the vast majority of security bugs for 30 years. This is why every new language in the last 20 has sort of automatic memory management. Even C++ has moved in this direction with the vast selection of smart pointers.

Caused by C++?

[Anonymous Coward]

Aren't they all memory errors/bugs made possible by C++?

Aren't there today, newer programming languages, in which such bugs are impossible?

Is it really realistic to just say "Hire better programmers!" or "Train your programmers better!" (so they would never make any mistakes)?

Re: Caused by C++?

[Anonymous Coward]

Yes! We call them 10x engineers. In addition to being ten times better they also train all the other programmers. Alas for most employers who fail to hire or retain a 10x engineer when they find one.

Re: Caused by C++?

[Anonymous Coward]

I think you better read peopleware again so you properly understand about what DeMarco was refrerring to when he said some developers are 10x more productive than others. (Hint youâ(TM)ll be surprised that it doesnâ(TM)t mean what you think it does)

Re:Caused by C++?

[Anonymous Coward]

Aren't they all memory errors/bugs made possible by C++?

There might be some you'll need to use assembler to do.

Aren't there today, newer programming languages, in which such bugs are impossible?

Sure. Good luck writing anything non-trivial with those.

Is it really realistic to just say "Hire better programmers!" or "Train your programmers better!"?

Yup, or maybe just ones that don't go out of their way to code memory errors/bugs with C++ (the newer version).

(so they would never make any mistakes)?

Nope, just less of the bad ones.

Stop allowing compilation with warnings!

[Anonymous Coward]

Simply put, stop allowing compilation with warnings. The compiler flags the problem, but then it's up to the developer or user not to use the boundary condition or memory leak risk that would cause a buffer-underrun or crash.

All warnings should still be errors, therefore halting the link to executable process.

Re:So create standards-compliant functions MickeyS

[Narcocide]

Thank you. Someone please mod this +1 informative.

Race condition

[Anonymous Coward]

Not sure I'd classify race conditions as a memory safety issue. Most race conditions are dependant on external resources such as files in secondary storage, or objects in network state.

Re:Race condition

[tepples]

A race between two threads that call a language's equivalent of malloc or free can certainly corrupt their shared heap.

In other news ...

[Anonymous Coward]

... share prices in Valgrind sky rocket.

ressurect the Lisp Machine

[Anonymous Coward]

Start over with a new computer design based on typed objects, eliminating the possibility of memory bugs.

Race condition does not fit into the list

[Anonymous Coward]

You can have race conditions in any language as long as there are two processes or threads executing instructions in parallel or interleaved. No need for shared memory.

There's a reason

[ledow]

Strange then that the various rewrites of Windows and the kernel, and device drivers etc. don't use a memory-safe language. Or that I'm really pushed to name an OS that *wasn't* written in C / C++ and might be something that anyone's heard of except on a tech forum.

Maybe something to do with the fact that - despite what's claimed - memory-safe languages tend to be slower and/or consume more resources in the first place. That's the problem you need to fix - push the memory safety into hardware, so it doesn't need to be in the language. That means a complete architecture change.

Name memory-safe languages in mainstream use and you end up with:

- Python
- Java
- C# (which just makes me think ".Net Framework")
- JavaScript
- Rust and Go are in the middle ground - they can be memory safe but they often aren't.

Not sure I really want an operating system written in any of those languages. Or even written by the people who wrote those languages (Google may have written Go and use an OS of their own, but didn't exactly make Android or ChromeOS now, did they? And they are both based on what kernel, written in what language?)

Until we solve that performance problem of memory-safety, and a memory-unsafe OS underpinning the whole thing, nobody's going to bother with a memory-safe language.

Re:There's a reason

[Anonymous Coward]

And the reason is that once you try to deal with these issues automatically the suckage to performance hurts more than the occasional bug.

And you still won't deal with things like pushing the wrong address into a DMA controller no matter how clever your language is.

And maintaining a large C project, with another team doing similar in C++ - the C code seems more robust. When you need to do clever things in C++ you need to be really clever and it bites you in the arse later. C, well it's just part of the price and paid upfront.

Re:There's a reason

[jma05]

This is mostly a strawman.
None of those languages were ever considered real candidates for OS or driver development, except Rust (which generates the same machine code with safer high-level constructs).

As much as I dislike C, I am fine with it for kernel and driver development. C can be mostly safe IF you pour a lot of human resources to review it. People always assume they are better at things than they actually are... and with C that is more of a problem.

Not all that makes an OS and presents vulnerabilities is kernel and driver code. Avoid C whenever you can (especially network facing code, bottleneck is mostly IO anyway), but otherwise keep it. If you are not writing hardware level code, one perhaps needs to reconsider its use entirely. Keep it legal and rare.

Rust is much harder to learn than C. That makes it a not-yet-ready replacement, not performance costs.

Re:There's a reason

[ledow]

That there isn't a mainstream, popular, memory-safe language that is suitable for writing an OS (to the point that *anyone* from the entire tech industry has written an OS in it that's mainstream/popular in itself?) is a strawman?

No, that's my exact point.

Any language is an expression of your intention. If your intentions are poorly thought out, planned, described and executed, that's a fault common to all languages and little can fix that (expecting the "grammar" or "vocabulary" of a particular language to save you in that instance is not sensible).

C is used for many reasons. It's not "safe" because "safe" is hard anyway. It is quick because quick is hard in many languages that are safe.

Rust is no more difficult than C but if want to do anything vaguely OS-like or interesting, you have to utilise it's "unsafe" settings and you're back to square one.

All things aside - trusting SOFTWARE to enforce security is a nonsense. When software wants to access out-of-bounds, it only has to change a number.

We need to design *hardware* to enforce memory security. Things like "per-process/page encryption" are starting to do that for us - Intel's next round of chips features a way to have a different memory key for each part of memory. It's a start. But what's needed is a literal way to ensure that you *can't* access outside of bounds anyway. We fudge this with flags and DEP and things at the moment, but that still allows huge scope for error and attack.

If we lacked a method for one process to, in any way, access the memory of another process, no matter what address it was tricked into trying to access, and everything had to be done through message-passing and hardware bounds, then you could start to make a more secure system.

Intel are bolting security on piecemeal that should have been in there decades ago. And the hardware needs to do the job. Then it's simply not possible to express "Access this piece of memory that's part of another process", by accident or by design.

Re:There's a reason

[jma05]

No, the strawman is pointing to scripting languages like Python and Javascript and saying they won't cut it for writing an OS. Of course, they don't. Who is even suggesting?

Again, I am not arguing against use of C for kernels. I am arguing against using C style programming (trusting humans with transparent memory access) unless it is absolutely warranted.

I am also not getting the sense that you properly tried Rust yet.

https://ruudvanasseldonk.com/2...

It does do safer constructs with no extra cost. It does safe without compromising quick.

> Any language is an expression of your intention. If your intentions are poorly thought out, planned, described and executed, that's a fault common to all languages and little can fix that (expecting the "grammar" or "vocabulary" of a particular language to save you in that instance is not sensible).

I completely disagree. Tools (languages in this case) have a great bearing on your ability to express yourself. There is a huge amount of psychology research on this general area; and this is a psychology issue, not a CS issue. Intentions aren't enough. That is the whole point of programming language research.

> All things aside - trusting SOFTWARE to enforce security is a nonsense. When software wants to access out-of-bounds, it only has to change a number.
> We need to design *hardware* to enforce memory security. Things like "per-process/page encryption" are starting to do that for us

Of course. I completely agree that the current security scenario is broken and these are all band-aids. My point is that because we don't have that utopia, we do need to compensate until we get there.

They should know

[OneHundredAndTen]

Microsoft knows everything there is to know about buggy software.

Re:They should know

[Anonymous Coward]

cheap shot. not that I entirely disagree, but still ... you could have made an attempt to move the thread in a constructive direction.

Radical? solution

[presidenteloco]

Get off these 50 year old languages?

Either rewrite from scratch, or develop smart auto-migration tools then repair the results.
The auto-migration tools can try to infer "intent of a sane programmer" and put in a whole bunch of additional memory safety checks.
I suppose it could put the memory safety checks in to code in the original language (yuck) or could put them in by migrating the code to the new safer language.

BTW Betrand Meyer has some interesting stuff going on in the area of safe concurrent programs these days, using an extension of Eiffel.

Re: Radical? solution

[astrofurter]

"Betrand Meyer has some interesting stuff going on in the area of safe concurrent programs these days, using an extension of Eiffel."

Eiffel is a beautiful language. Man I wish more companies would use it for real work.

Re:Radical? solution

[arglebargle_xiv]

Get off these 50 year old languages?

Onto what? If it's Java then 70% of your issues will be JVM exploits. If it's SQL then 70% of your issues will be SQLI. If it's HTML then 70% of your issues will be XSS. If its $X then 70% of your issues will be $Y, for any value of X in combination with whateer Y goes with it.

Re:Radical? solution

[Anonymous Coward]

SQL and HTML are DSL's, you can't rewrite anything in them.

C's and therefore C++'s and therefore Java's, and any other idiot language which inherited C's for loop, should be instantly disregarded, it's "designed" to fail.

They should use Java

[Anonymous Coward]

Because C# is REALLY not memory safe.

Should

[AHuxley]

have made an Ada OS.

isn't this the OS's job?

[qinglong]

how can a program that runs on a host be allowed to access the host's resources? shouldn't the host be controlling what the parasite is doing? a program shouldn't be allowed to access a memory space which it is not priviledged to. The host should kill the program immediately

Re: So create standards-compliant functions Mickey

[spongman]

Microsoft doesnâ(TM)t make a C compiler. VisualC++ is just that a C++ compiler (that just happens to compile some C programs).

And water is wet ..

[najajomo]

“Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues” .. due to the defective WinTEL x86 memory model.

Other operating systems

[Anonymous Coward]

So, since this is such a curse and appears to have been afflicting them with bugs for so long....How come their main 2 competitors do not suffer the same fate?

They are putting out a bad product, there are no excuses. Hiring out foreign labor from 3rd world countries on the cheap, and the quality level has nose dived because of this.

Hire competent employees, pay them well, treat them well. That is how you succeed. Hiring untalented cheap labor is how you infest an organization with structural weaknesses that could take years to dig out if they could even all be caught.

I thought Slashdot showcased NEWS for nerds...

[slashdot_commentator]

How is this news?

More important, WTF has Microsoft done to prevent 70% of those errors? They've plowed an impressive amount of money creating their developer tools division. Couldn't have they shelled out a few more million to design a memory safe language and implemented it upon their VM (CLR)? Why do they perpetuate their OS product on a language (C++) utterly vulnerable and responsible for 70% of those security holes. Yes, C++ is capable of being type safe and memory secure, but apparently most people coding their product aren't capable of writing such code flawlessly in C++.

Re: So create standards-compliant functions Mickey

[Anonymous Coward]

Microsoft doesnâ(TM)t make a C compiler. VisualC++ is just that a C++ compiler (that just happens to compile some C programs).

Nice try.

But C++ subsumes significant parts of the C language, such as 27.9.2 C library files, on p 1019 of the C++ standard,

Besides, you're fucking WRONG anyway:

C99 Conformance Visual Studio 2015 fully implements the C99 Standard Library

Linux USED to have mitigations (GRSECURITY), now i

[Anonymous Coward]

Linux USED to have mitigations (GRSECURITY), now it does not, since GRSECURITY went closed.

Re:isn't this the OS's job? - Grsecurity / PAX

[Anonymous Coward]

Not according to linus, but he's a fucking CoC-sucking moron.

GrSecurity does as you say. But they went closed and are violating the GPL by adding an additional restrictive term ("we punish you if you redistribute")

Where are all these bad programmers coming from?

[old_dirty_unidef]

They should teach this stuff in colleges, not in corporations. Are the selection pools for MS limited to Ivy League schools?

Warning: unused parameter

[tepples]

All warnings should still be errors

Your method forms part of a class that implements an interface including a particular parameter, but your implementation of said interface has no need for that parameter. The compiler issues a warning that your method does not use this parameter, and your policy is to treat all warnings as errors. How do you make your method fit the policy?

Re:Warning: unused parameter

[Anonymous Coward]

Don't do what you're trying to do.

a) Your method isn't correctly implementing the contract defined by the interface, don't do that. That parameter is probably there for a reason.
or
b) Inform future contributors that the parameter isn't used with a macro that acknowledges the parameter's presence but doesn't calculate with it. You'll have to document why there, same to the users of your method. This is surprising, so don't do it.

I use that to my advantage in hosts files

[Anonymous Coward]

See subject: As hostnames don't cross 255 bytes it's faster as you say BUT also runs on LOCAL STACK vs. GLOBAL HEAP (system RAM) + usually STAYS in the L1/L2/L3/L4 caches (another speed-gain).

* I used Delphi (Windows versions of program below) &/or FreePascal (Linux/BSD/Apple models) as it's FASTER on strings (by double++ vs. MSVC++ in of all places a competing trade mag "Visual Basic Programmer's Journal" Sept./Oct. 1997 issue "INSIDE THE VB5 COMPILER" where Pascal ALSO beat MSVC++ by DOUBLE in math too)

ALSO A SECURITY ADVANTAGE (2 for the price of 1).

APK

P.S.=> For the best hosts file multiplatform:

APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between chars & download)

APK Hosts File Engine 10++ SR-1 32/64-bit for Windows https://hosts-file.net/?s=Down... (DL link @ bottom)

Soon 4 MacOS (I just got a NEW Mac-Mini to port it there)... apk

Re:So create standards-compliant functions MickeyS

[Anonymous Coward]

MickeySoft

What are you, 12 years old?

The proper spelling is Mickey$oft.

No memory problems here

[presidenteloco]

Well, back in the day, and I do mean the day, I was coding in Common Lisp on a Lisp Machine, which was a computer which ran no other language than lisp. So the only non-Lisp thing on the machine would have been parts of the Lisp interpreter/jit-compiler/garbage collector, process scheduler, which were written in micro-code.

So all memory access to non-trusted programmers was only allocated to the programmer as cells with safe pointers to other cells, or was numbers and safe, sized strings, and maybe a high-level typed and bounds-checked numeric array here or there etc allocated as part of the core lisp implementation. Programmers could not cast to or from pointers, nor know where the pointers, which were managed by the language environment, pointed to.

So it was basically impossible for any regular application programmer to cause any memory mis-use error.

You could still do stupid things, like infinite or memory-intensive recursion, but that would always break in a nice and controlled way.

Ah, those were the days.