Slashdot Mirror
The Security of Popular Programming Languages
An anonymous reader writes "Deciding which programming language to use is often based on considerations such as what the development team is most familiar with, what will generate code the fastest, or simply what will get the job done. How secure the language might be is simply an afterthought, which is usually too late. A new WhiteHat Security report approaches application security not from the standpoint of what risks exist on sites and applications once they have been pushed into production, but rather by examining how the languages themselves perform in the field. In doing so, we hope to elevate security considerations and deepen those conversations earlier in the decision process, which will ultimately lead to more secure websites and applications."
I wonder how Ada 2012 would do in this test, although I don't know of any websites that use this language for a backend.
Who exactly is going to volunteer to implement a major system in a combination of Perl and ColdFusion?
Captcha: jokers
where the hell is it on the list?!
-db
From the article: "To lay the foundation for the research, the team first examined the volume of languages in the field, and found, unsurprisingly, that .Net, Java and ASP are the most widely used programming languages at 28.1%, 25% and 16% respectively. Legacy programming languages that have been around for decades, PHP (11%), ColdFusion (6%), and Perl (3%) rounded out the remaining field."
How did they determine the languages? This certainly differs from TIOBE's methodology (based on Google searches). The "unsurprisingly" seems suspect as well; I feel some of the selections *are* somewhat surprising.
Do they mean Classic ASP? They list .NET separately so I don't think they mean ASP.NET, but they also don't include ASP in their list of "legacy" languages. I also seriously doubt 16% of companies are still using Classic ASP.
ASP isn't even a language, it's a framework. You can write a Classic ASP app in vbscript or javascript. You can write ASP.NET in any .NET supported language. Then there is ASP.NET MVC.
If they can't get their list of tested "languages" straight, I doubt the rest of the article.
I'm not even sure what the article meant by ASP vs .NET ? Surely they aren't talking classic ASP? I doubt anybody is 'starting new projects in classic ASP -- so what is ASP? and how is it not .NET ?
The rest of the article doesn't make a lot of sense to me either.
It may be cliche, but how secure a language is depends on who is using it. PHP is very accessible, and used by a lot of newbies, so "in the field" there turns out to be a lot of vulnerabilities found. However, by following some relatively simple guidelines, code can be made pretty secure. Most of the problems in PHP code are either due to SQL injection, which can easily be avoided by using parameterized queries, or from turning on options that are known to be insecure, like register_globals. C on the other hand would only be used by a small number of highly trained individuals, at least for web applications, so it's less likely to experience problems in the wild, but due to buffer overflows and other memory management problems, it's much easier to shoot yourself in the foot without realizing it.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
One bug that allows silent remote code execution on the WAN side and another bug that is a privilege escalation possibility on the LAN can not be treated as one bug each, right? This is not limited to just security vulnerabilities alone. Many software company top managers insist on looking at bug counts, sometimes sorted into 5 priority/severity levels or so.
It gets worse in the planning and progress monitoring. They use fancy tools like rallydev.com or something, but they allow each team to define its own story points. The Bangalore team uses 1 story point = 1 engineer week. The Boston team uses 1 story point = 1 engineer day. The Bangkok team uses engineer hour. And the top management gets the report, "This SAGA feature story was estimated to take 3264 story points, and it is 2376 points complete". Complete b.s. that is.
We pay ridiculously high salaries for the top management, and instead of expecting them to put in the time, energy and effort commensurate with that kind of pay, to make valuable judgement, hard decisions, step on people's toes, tell it like it is, and paint an accurate picture of the state of the company, we let them shirk their responsibilities.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Yes, of course the security of your language (as well as the rest of your environment) matters. But what's way more important is what kind of devs you have. No matter how secure anything is, if the person supposed to use it does not know about its security pitfalls, do you think that's increasing the security?
Security is by definition the minimum of the security your technology offers and the security your personnel offers. The minimum. Not the average. The same applies to OSs, too. You can have the most secure OS in the world, if you lack the admin to secure it, you're no better off than with an OS that has shabby security itself.
Your security is way more dependent on the personnel you have, and the ability and expertise they have with the different technologies. Simple scenario: Take an admin that knows OS-A like the back of his hand and can somehow kinda-sorta get OS-B to run. OS-A has a few security holes (that the admin all knows about, including their workarounds) while OS-B is absolutely tight but our admin doesn't know it too well.
Which one do you think will, administered by said admin, be more secure?
It's the same with programming languages. C does have its security issues, but a good C programmer knows why he should not put input on the stack and why he should include sanity checks on every input, especially if is of variable length. Some other language might not have that possibly dangerous pit, but there are very, very few languages (outside those fields where security matters and money doesn't) that have none.
What would you prefer your devs to develop in? A language they know, including all its slings and errors, or a potentially more secure one the pits of which your devs don't know?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
In the wake of Heartbleed, one might think that this would be talking about array bounds checking or buffer overflow mitigation. No. It is talking about web site frameworks.
examined the vulnerability assessment results of the more than 30,000 websites
First of all: this is not measuring the security of the programming language. This is measuring the security of the OS infrastructure and toolchains. Notice C/C++ is not on the list, since it is hardly ever used for creating web sites.
There was no significant difference between languages in examining the highest averages of vulnerabilities per slot.
What the heck is a slot?
Any summary where Perl scores the best must be deeply questioned. I doubt this is an apples-to-apples comparison. Surely these Perl sites are not doing nearly as much as the sites written in other languages.
If the language specification doesn't expressly say what happen when things "outside the design" happen, then different implementations may work differently.
For example:
If the language design spec says
"If an array index is out of bounds, exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program,"
that may seem very specific, but if how to "exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program," isn't specified by someone (usually the operating system), then it may not be specific enough. if different operating systems specify how to do this differently, then expected "under the hood" behavior will not necessarily be consistent across operating systems.
For example, does "exit the program" mean simply returning control to the caller, or does it mean explicitly returning any resources that were previously granted to the program by the operating system first? Or is that optional? If it's optional as far as the operating system is concerned, does the language provide a compile- or run-time switch to force such a cleanup? Does returning memory to the operating system guarantee that the OS will sanitize the memory, and if not, does the language guarantee it? If the language doesn't guarantee it, does the language provide a compile- or runtime switch so the program will sanitize memory prior to returning it to the operating system?
These differences in language implementations and even differences in how operating systems handle the starting and stopping of processes can lead to differences in what the code actually does. Usually these differences are unimportant but sometimes they are very important.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
FLAME ON! PURGE THE INFIDELS IN THE HOLY FIRE!
But before we really get into it, this isn't really a measurement of the language somuchas how people use the language. For example: while VB6 was an abomination, VB.NET really isn't all that bad. But since the people who use VB.NET are the amateur noobs who make stupid mistakes. Hey, we all started somewhere. But it means I really wouldn't trust a project that's written in VB.NET for certain tasks.
These are sociological factors. Politics. Culture. And they matter, but they're not technical aspects. The size of the community. The maturing of the developers. How open the overlord megacorp is to people making tools that interface with their toys. How many developers got the hype-bug and wrote libraries for said language. How good those developers were at their job. It all matters, but it's not an aspect of the language itself.
Any Turing complete language CAN do the job. You've got to avoid Turing tarpits, but mostly the right tool for the job is a matter of fashion.
Why the flames? Why is this something that causes so much strife?
Because we all want to bet on the right horse, and who wins is largely a popularity contest. It really DOES matter what the community does. You can't just go off into the woods and code away in TurboPascel and hope to have a lucrative career. It's an inverse tragedy of the commons. Using the tools of your neighbor SHARPENS said tools. So everyone wants you to use their tools. Because their tools are the best.
And so the flame wars rage on.
Neither is on the list, so I am not sure this is much of an attack.
They shouldn't be looking at the number of bugs in the implementation of the language. They should be looking at the bugginess (or not) of the code written in it. That's the important thing.
php is not the worst because they measured completely the wrong thing. They measured how many bugs they found in the implementation of the language, not how many bugs a programmer using that language would introduce that the language would not catch for them.
I do not think C++ would have helped here, all it would have done was made things a bit more obscured. It should also be noted that you can build custom allocators in C++ too (I worked on a couple projects that used them) so that part of the problem would be there too.
C++ makes a lot of things easier, but under the hood it is still essentially C with an expanded library and fancy pre-processor (I know modern compliers do not actually preprocess C++ into C and then compile), thu all the same problems are still there and mostly are mitigated by using libraries that wrap things up in a safer way.
Hey, some of us find manual memory management sexually fulfilling, you insensitive clod!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
(Can't believe I'm replying to an AC).
This sounds great and all that, but that's a very unreasonable statement. Consider C. I don't know a single person who would say that C is secure or that security wasn't built in from the get-go. The same can be said of C++. But those languages offer different benefits (speed and control both come to mind). It's a trade off, to be sure. But sometimes, you have to use a language that isn't secure "from the get-go" to build an application that needs security. We don't always have the luxury of doing the perfect (or near perfect) thing.
Ur/Web is an interesting language with a type system designed to reject vulnerable web programs as ill-typed. The compiler itself is written in a safe language — Standard ML, and there is a proof of language correctness included.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
The security level of a piece of code with good security is 95% coder competence and 5% language, i.e. language is irrelevant. One thing though is that language can add to the security problems if it has insecure tun-rime implementation errors.
One reason most security-critical software is written in C is that there, the coder gets full control. A good coder with skills in secure coding will do fine with C. A coder that does not understand software security will to badly in any language, but in C he/she might not even produce anything that works, which will be an advantage. Also in C, it will be far more obvious if somebody is clueless, which makes review easier.
But "language is important for code security" is even more wrong than "language is important for code reliability". Language is important for code performance though, but only in the sense that it can kill it. Good language choice can also make a good coder more productive (a bad coder has negative productivity, so it hardly matters...). This nonsense about the language being capable of fixing problems with the people using is comes from "management" types that are unable to handle people that are individuals. These utterly incompetent "managers" can be found in many large companies and they believe that in IT, individuals do not matter. Typically these "managers" are not engineers and have no clue what a good engineer can do but a bad one cannot. They also believe that engineering productivity can be measured in hours spent or that all coders are equal and just implement specifications, so outsourcing is a good idea.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Not a single security exploit reported in over 50 years.
"To those who are overly cautious, everything is impossible. "
http://www.crosstalkonline.org...
And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)
DOH! I *knew* I should've read the freakin' article before writing that.
Obviously, the article is talking about scripting languages, languages that (typically) run inside of a hopefully-OS-independent-behavior runtime rather than a traditional compiled language that doesn't contain a lot of "runtime" between the compiled code and the operating system.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I don't understand this:
Perl remediates 85% of all Cross-Site Scripting vulnerabilities, the highest rate among all languages but only 18% of SQL Injection.
There is no Perl language support to remediate cross site scripting. That's all done by the developer and/or framework he's using, so I don't see how it's useful to say that Perl remediates 85% of XSS vulnerabilities when the language itself has no idea what XSS is or how to remediate it.
I'm also having trouble reconciling this statement:
Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language.
So Perl re mediates 85% of XSS vulnerabilities -- the highest rate of any language, yet it has a 17% higher rate of XSS vulnerabilities?
This study would be slightly more useful if they gave details on web frameworks instead of just languages.
I'm surprised Ruby and Python didn't make the list, I figured that either one of those languages would be more popular than Perl for web development today
I can't figure out how I would use this to make make a real-world decision. Just picking the "most secure" language overlooks so many other tradeoffs that I just can't see it as a valid approach, especially when the article ends with a call for more testing, not a call to select superior languages.
This is a non-finding.
A pretty comprehensive study was done that showed regardless of the language selected, the programs written by developers with the most experience in that language were the the ones with the least security bugs, regardless of traits of the language like attack surfaces or complexity.
It's short and sweet. A developer's experience with the specific language or framework an application is written in is a better indicator of application security than the language or framework an application is written in.
Yes, it is indeed lucky for us that the competent OS developers know their stuff, and they don't listen to people like yourself who have no idea why C is better for the Linux kernel (or any kernel, really). I hate to break it to you, but you aren't smarter than the top Linux developers. You simply aren't. Stop confusing yourself into thinking you know more than they do. It is pathetic to watch.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
SQL and amalgamations of languages (e.g., JavaScript generated by PHP) not on the list. XSS attacks involve such "mutt" software.
IMHO, the more code the more opportunities to exploit things. Terse languages to the rescue? Write it all in Haskell, Lisp or something. You'll attract talented developers and the attackers will be like... "Oh crap, we have to analyze that???".
No silver bullets of course. Something has to be able to read/write sensitive information at some point. Something has to determine under what conditions that occurs. It's human nature to make those conditions complicated to the point where vulnerabilities occur...
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Was a new feature that was enabled by default. The heartbeat 'feature' should have been *DISABLED* by default. New features should always be disabled, and then you let the developer decide whether to enable it or not. And then *TEST* it! And *CODE REVIEW* it!
You are being MICROattacked, from various angles, in a SOFT manner.
At the end of the day, all programming languages are about abstracting things. If you are testing the intrinsic security of a programming language, you are in essence testing how successful the language's built-in data types, built-in functions, APIs, standard libraries, etc. are at mitigating risk factors, which is all about abstraction.
A language's intrinsic security is only as good as its abstractions.
(Can't believe I'm replying to an AC).
Why do so many people feel the need to point out that they're stooping below their normally high standards to "reply to an AC"? Either the guy said something that made sense or he didn't. Who cares if he was anonymous? And why lead with that in your reply when it has nothing to do with the discussion at hand?
Hey, enough jokes from you today. You're way over the quota. What, are you getting a big fat refund?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
The fact that the holes exist is what they're talking about.
std::containers don't need to store their size as a separate variable
C strings don't either. It's the protocol that said "hey, rather than null terminating strings, let's put a length byte like Turbo Pascal never went out of style!"
The fun thing is that that design decision has lead to an entire CLASS of SSL bugs (in all stacks, not just openSSL) eg invalid certs validating because of a null byte in the Common Name. And heartbleed was just one more in that heap.
If I have been able to see further than others, it is because I bought a pair of binoculars.
C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8. And the absurd part of it is that they could easily do a good job. Utf8 is just a byte array with various routines to interpret the code. Glibc does a reasonable job for a C library...not ideal, but reasonable.
All the array needs is a way to address a chunk by character # rather than by byte #, a way to copy of a character or a slice of chars, and a way to determine the general character classification of any character. Also a few methods: first(), last(), hasnext(), hasprior(), next() and prior(). And these all "sort of" exist, except getting the general character classification. (Do note that these functions need to operate on utf-8 characters rather than on bytes.) But several different ways of doing this are already known. Vala, e.g., handles it without difficulty, and is able to emit C code (using Glibc libraries).
So it's not a programming difficulty that's holding things up. It's the standards bodies...or, perhaps, some members of them.
But I've looked at C++11, and it is not a satisfactory answer. Vala has a good answer. D (Digital Mars D) has a different good answer. Even Python3 has a pretty good answer. (I don't like that in Python you can't determine memory allocation within the string.) Also Racket, etc. But C++ doesn't.
I think we've pushed this "anyone can grow up to be president" thing too far.
"A new WhiteHat Security report approaches application security not from the standpoint of what risks exist on sites and applications once they have been pushed into production, but rather by examining how the languages themselves perform in the field"
How about designing a language that can't read/write past a previously allocated buffer in memory.
From the start, the design of C emphasized speed and efficiency over all else. "Trust the programmer" was one of the mottoes. If the programmers are doing something weird, assume they know what they're doing, and maybe print a warning, but allow it. C was, by design, weakly typed, and minimalist, especially when it comes to checking for errors because such checks take time.
Often, we've seen efforts to improve C's safety that were eventually sidelined because they were a performance hit. The iostream library is safer, but much slower than stdio. Which one do people prefer? stdio! C libraries are full of routines that do not do bounds checking, for the sake of performance and simplicity. gets() is an infamous one. The language itself is so easy to to use insecurely. Pointers can be set to point absolutely anywhere, and those places both read and written at will. If the OS, with help from modern CPU memory management facilities, didn't set boundaries and kill programs whenever they stepped over the bounds, there'd be nothing to stop them.
Another idea was adding instructions to dynamic memory allocation to do memory wipes. Before freeing the memory, the computer was instructed to zero it out. This resulted in as much as a 10% performance hit, and was quickly abandoned. Wiping memory has been proposed at the OS level as well. But there are always apps that don't need that because they aren't doing anything sensitive.
That brings up a big problem with the article. Where should responsibility for security lie? With the OS? I think trying improve a language's security is the wrong approach. That's what they sort of tried to do with Java. It's like trying to prevent bank robberies by securing the steering wheels of all potential getaway vehicles. Yes, make languages easier to use and less prone to bugs, but don't specifically target security.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
> C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8.
That's because for most programming, UTF8 is not worthy of support. It's inconsistently used, it arbitrarily increases the of individual. It would be much safer used as only binary strings, not as actual characters which must be parsed and reformatted among different environments. The advent and popularity of UTF8 with its confusing and ill defined management of case and formally POSIX compliant operations such as file naming has effectively slowed system programming by many years.
People are still writing code vulnerable to SQL injection attacks?
Yes, they are. It doesn't help when lots of online tutorials give crappy information, like saying to use mysql_real_escape_string in PHP instead of a proper parameterized query. (Using the escape function is better than nothing, but it's not foolproof and is needlessly convoluted.)
This tutorial, which ranks first on Google when I search for 'php sql', uses the escape method and does not mention parameterized queries at all. (The correct method is described here.)
Do the work yourself and make your programs secure. C und ASM are Still the kings of the hill and always will be.
If you need to do things like that, then just use UTF-32. Memory is cheap. Scanning a byte array counting characters of arbitrary length is expensive, and there are no cheap shortcuts that don't involve taking as much memory as your UTF-32 representation would have used in the first place, which require far more complicated and prone to error algorithms to handle it all.
I remember a saying when I was learning programming;-
With C it is easy to shoot yourself in the foot, with C++ it is a lot harder, but when you do shoot yourself in the foot you take your entire leg off.
If you don't like C++ (and who does?) or C, what DO you suggest as a systems programming language?
Rule 1: If it runs under a VM, it's out
Rule 2: If it requires a garbage collector, it's out.
Rule 3: COBOL and FORTRAN are out too.
No, C++ is a separate language from C, and far more expressive. It never was a preprocessor for C; Cfront was a genuine compiler that used C as the target machine, and fairly soon became inadequate for compiling C++.
If you think it's basically C with more libraries and a fancy pre-processor, you're using it wrong.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
FWIW, Linux started way back when C++ was nonstandard (1990?) and didn't have many advantages over C for kernel development. At that time, C was definitely the right choice, and making it a mixture of C and C++ isn't real attractive. Nowadays, I'd recommend C++, as it can do pretty much everything C can and more besides, and standards-conforming compilers can be found everywhere (pity about Visual C++).
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Modern C++ is a lot more coherent than you suggest. Its main problem is the initial compatibility with C, and attempting to be compatible with bad decisions made along the way (long has to be 32-bit, so we need "long long"?). I have no idea why you think binary literals are all that much more useful than octal or hex. Macros aren't type-safe, but C++ templates are. Name mangling is an implementation detail, and there's lots of variation between compiler output that isn't name mangling. Standardizing it would accomplish very little, and there's no need for the runtime to know the mangled name.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
C++, properly written, is much more secure than C. It includes memory management, type-safe I/O, and well-behaved library containers.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Use Rust. It's not at version 1.0 yet but it's promising. See some comments on Rust's benefits for security. And some blog posts by Andrew Ruef and Patrick Walton.
UTF8 is great for storing data in files, but ... working with strings in memory? Insanity will follow.
No sig today...
I think 1996 just called and wants it's Usenet flamewar back.
No sig today...
I remember a saying when I was learning programming;-
With C it is easy to shoot yourself in the foot, with C++ it is a lot harder, but when you do shoot yourself in the foot you take your entire leg off.
Pity you never bothered to find out who said it or in what context...
No sig today...
what bash?
yes sure. just stay away from eval
I'm currently checking if other constructs from bash are prone to execution or information disclosure. Came across 'declare' which may have an issue.
Of course, SQL injections are possible, because SQL is not bash.
Atari rules... ermm... ruled.
Sorry pal, Cfront was a preprocessor in the same vein as Oracles PRO*C. If calling it a compiler makes you feel better about using it then all well and good - but it wasn't. A lot of code went straight through it unchanged, it only processed the specifically C++ parts.
Newsflash - when you're writing a kernel you want to know exactly what is being created during compilation, when memory will be allocated and how is going to be laid out during runtime and when it gets free'd up. ie - it HAS to be explicit otherwise your OS is going to end up in a mess. What you don't want is a load of C++ implicit code and memory allocation happening when you need tight control of both.
Now get back to application programming and leave the OS coding to people who know what they're talking about.
and far more expressive
Such silly nonsense.
Required reading for internet skeptics
"I have no idea why you think binary literals are all that much more useful than octal or hex"
Binary literals are extremely useful when you're dealing with bits in specific places in a byte/word/etc. Its a lot clearer to read and a lot easier to write than trying to encode and decode into hex or oct.
"Standardizing it would accomplish very little, and there's no need for the runtime to know the mangled name."
Oh really? Just how do you think dlopen() finds the functions in a .so shared object file (.dll in windows) loaded during runtime? As things stand you need to 'external "C"' every C++ .so function you might need to call and as for class statics - forget it.
I think your inexperience in the world of low level programming is showing.
Let's try it the other way:
C, properly written, is much more secure than C++.
Huh, it still works. I guess that's what happens when you use a ridiculous qualifier like "properly written".
Required reading for internet skeptics
its pretty much the case that programming languages in which it is harder to make bugs are also harder to make security problems. Because security problems are just a special case of bugs. So all the things we know about writing better languages are important for security. Unfortunately, language technology has always been under-appreciated. People will just use what is popular, which often times is just C or Java and so forth.
Except that I gave reasons why C++ is superior in security to C. It's easier to write secure code in C++ than in C. Both are difficult to write well, but well-written C++ code is going to be more secure than well-written C code.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Could be; I don't have much experience in low-level programming using higher-level languages.
Binary literals would be nice, yes, but I don't see that as a big deal. I find hex literals almost as easy to read, and easier to type correctly. YMMV, of course, but I'd expect proficiency and ease with hex literals to increase over time.
C++ doesn't have a halfway standardized ABI, unlike C. Name mangling is just part of it. There's a lot of other compatibility issues. This is a problem with the language (not the language standard, but the language in the community). Informally standardizing name mangling would be a start, but only a start. I agree that a reliable ABI would be very nice, but it's more work than you seem to think.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Your first paragraph is entirely true. In writing such code, you'd want to be very choosy about which C++ features you used. That doesn't mean C++ is worse than C in this case, only that it loses a lot (but not all) of its advantages.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I never used Cfront that much; I'm taking the the compiler designation from Stroustrup's "Design and Evolution" book. I never used PRO*C (my main experience with interfacing is OCI and OCCI), but in the case of Cfront you'd have to parse to determine which parts of C code you could let through. What would be a function call in C could be a member function call in C++, perhaps a virtual function call, and maybe it could be passed through and maybe not. Operator overloading meant that every expression had to be parsed by Cfront. If you're taking source code, parsing it, and producing somewhat different target code based on the parse, I'm going to call it a compiler.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
So how would you define a precompiler then?
Can't see it being that much work. For method foo in class baa just define the actual function name to be __baa_foo or similar. For a virtual function __baa_v_foo and so on. For overloaded functions __baa_foo1, __baa_foo2 etc. You'd need to know how the names were mapped to which method but its still better than the current mess.
It will if you're using C or C++.
FWIW, *most* of the text I'm working with is ASCII-7, but some of it isn't. Short quotation in, e.g., Greek. I need to be able to count the chars, etc. Utf-32 is an immense waste of space...and I already expect to be doing a lot of paging because of excessive memory use.
I think we've pushed this "anyone can grow up to be president" thing too far.
I wonder if zeroing out memory can go even deeper than the OS. Like, why not have RAM that can zero itself on command? Just turn off the DRAM refresh for a fraction of a second, and viola!
Memory moves have been made much faster by bypassing the CPU, for instance with hard drives with the DMA mode rather than PIO mode. So they are using a DMA from a /dev/zero device or more like a 4k page of zeroes to a range of memory? What you're describing sounds like an excellently lazy method. Zero newly allocated the memory when it is the object of a pagefault, not eagerly when allocated. Though nowhere near as bad as a PIO (or just PO?) method of pushing zeros out of the CPU and into memory, I'm guessing that is still a small performance hit. Is it?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Yes, we mean ASP classic.
Small point but the data was the median not the mean. The metric should not be used to evaluate individual sites. The idea was to determine if there in a inherit difference between the different languages and how they are used in the real world. Are PHP and Java really much more insecure a programming language?
The paper says that a slot is basically the bounds on a site. You can think of them as the same but there are some small differences that do not really mean much here.
> Modern C++ is a lot more coherent than you suggest.
You've never actually worked on a compiler have you?
Parsing modern C++ is a complete clusterfuck.
> binary literals are all that much more useful than octal or hex
There is a time and a place for _standardized_ verbosity.
When you do low-level PLL coding being able to have 1 character = 1 bit is extremely handy.
> Macros aren't type-safe, but C++ templates are.
Templates don't provide conditional compilation.
> and there's no need for the runtime to know the mangled name.
So you've never had a need for it. Great. You're still an amateur!
Gee, maybe I'd like to link code compiled with compiler A against code compiled with compiler B so I don't have to ship libs compiled with X compilers.
Maybe try interfacing some non C++ code with C++ objects. Oh wait, we have to extern "C" everything because of some retarded, and secret linker name mangling.