I can't really say anything about lambdas in C++ as I don't think I've ever even encountered something. In Java and C#, they are "syntactic sugar" in that they get expanded into more fundamental constructs. But they have stronger type-checking than an equivalent implemented with a preprocessor and are first-class entities. Passing a lambda to a function is not the same as passing the result of something from the preprocessor. The lambda gets executed in the future.
For whatever reason, the most negative people on/. always manage to get first posts. Some posters have already pointed out limitations but let's talk about the benefits of this.
If a bunch of hosts on my network start communicating in a way that they never have before, that me the sign that an infiltration has occurred. Inbound scanning looks for things trying to get through your firewall from the outside. But as we also point out on/. all the time, does almost nothing against social engineering attacks. It's not hard to get people to plug in USB thumb drives. (I've seen them given out by vendors at security conferences!) Nor can they resist attaching their personal devices to the corporate network.
Now you have a bunch of hosts making outbound connections to new places. Encrypted outbound traffic to IP addresses where FCrDNS fails. Worth investigating.
Of course this isn't a perfect solution, but it has at least some value. There is no claim that this is a replacement for other technologies only a supplement.
You keep saying things like "This and other fuzzing tools" even though it's been pointed out in this thread numerous times that the tool in the paper is not a fuzzing tool and it isn't even close. This tool is finding bugs, not coding errors. It's finding a situation where one object type is cast to another but at some point that cast has become incompatible but the compiler can't catch it. If the compiler can't catch it, it's unlikely that a human audit is going to do so. You would have to continuously audit every cast in the application. But even then you won't find this type of defect. Because the actual cast is never the bug. It's the semantic meaning of the data before and after the cast. And for that, no amount of C++ knowledge in the world will help you. You need to know the application domain and all parts of it. Your philosophical points may have validity. But it's hard to take them seriously when you can't (or won't) even use very basic terminology correctly. The fact that the words are new to you indicates that you've dismissed an entire part of the tools ecosystem without even learning about it.
Google doesn't have to do any such thing. They can just get rid of the legacy Java APIs and, instead, provide modern ones using lambda expressions. Then they can provide a tool chain that goes directly from source to.dx files and skips the whole Java.class file intermediate step. I'm surprised actually that we still even have to compile to Java classes. Then, in order to have write-once, run-anywhere we can get an ART VM for non-Android operating systems.
Prior to that, most software ran on C/C++ on Unix. Then people moved to Linux. Oracle's argument here would be that implementing libc on Linux shouldn't be allowed as it destroyed the value of Solaris. Maybe they will litigate this next. They can buy up SCO and make the same argument.
The issue isn't that the messages happen at compile-time it's that they are very long and hard to understand. We want the errors to be found at compile time (good), but the reason for that is that we want to *fix* the errors. And that's much harder to do if you can't understand the output. Granted it's much better than producing code with undefined behavior.
When I started working with C++11, I found it almost impossible to understand the compiler error messages if they involved anything related to templates. The messages have gotten better and, of course, I'm used to them now. But coming from the Java world, it really felt like an exercise in futility sometimes. More effort spent on understanding a minor syntax error than on actually writing code.
I'm not sure this is a true statement. There are lots of good alternatives to preprocessors that achieve the same goals without many of the drawbacks. The first one I think of is lambda expressions. Granted Java didn't get them until very recently. Templates/Generics also take away a lot of the need for the preprocessor. Most preprocessor work is around portability and the allowing compilation with different compilers. There was a time when you needed a wide swath of compilers to get code running on different hardware. For certain embedded device development, headers with conditional defines still make a lot of sense. But if you're running on phone or laptop hardware (or better), you're better off moving to a two-stage compilation like Java or.Net.
I realize that you want to believe this and I hate to be the one to burst your bubble so to speak but the fact is that these types of defects exist in almost any non-trivial piece of software. However, rather than go back and forth, how about you offer up some code that you've written and we'll run some of the tools you so dislike. If your code comes out "clean," I'll concede the point. But I'm confident that won't happen.
In any event these tools are still not glorified grep and it's not information that older people knew. Software systems have gotten much larger over time. There are whole new classes of bugs (like the ones in the article) that are introduced because the application is too large for the programmer to be familiar with the entire thing. No amount of knowledge of the programming language will help.
It's often impossible to predict the consequences of changing one part of a system. For all we know, the identified defects are the result of two changes that were each correct in isolation but the combination was dangerous. It's easy for that to happen with multiple people committing code.
I don't understand your desire to take something as complicated as writing software and simply say that all problems are because other programmers aren't as good as you are. It's a complex domain and we should be glad to have additional tools.
Fuzzing and grepping are entirely different things. If your original post hadn't gotten modded up, I probably wouldn't even respond.
Fuzzing is a mechanism where cleverly malformed data is sent to an application or even a piece of hardware to see how it responds. Things like an invalid message with a proper authentication code. It's a pretty effective form of testing. In this context your comment might as well be. "Testing your software is just a poor man's method of finding errors (the real problem) in some code. Glorified greps." Ideally we aren't writing defects and are bug-free before a testing cycle, but that rarely (if ever) happens. Even if there are no verification defects there may be validation concerns.
Both this and fuzzing are *dynamic* tools. Grep is a static tool although I don't know how it could possibly be employed in finding all but the most trivial defects. There are sophisticated static tools out there as well. (See FindBugs for an open source example of one). But these have nothing in common with grep.
Perhaps it is somewhat of a troll, but also makes a valid point. (I happen to like the sarcasm as well). We would like to think that all bugs are shallow given enough eyes. It's a reasonable mantra. And closed-source software has a history of eyes being intentionally closed (and the CSO getting mad at you for reporting bugs). Simple things like forgetting to close a file can be found through sheer determination. If the software is small enough for somebody to understand the whole thing, even the more complicated bugs may be found out this way. When things get large, you have experts who understand individual subsystems really well but for use cases that cross multiple sub-systems, subtle errors are made. These can't be found by looking at the code unless you know both subsystems very well. But there may not be anybody in that position so the bugs stay around a long time. For this type of situation you need better tools and a lot of progress has been made in this area. But given the number of bugs that get found in even good production software, there is still clearly a gap to fill.
From the paper: "Runtime type checking by dynamic_castis an expensive operation (e.g., 90 times slower than static_cast on average). For this reason, many performance critical applications like web browsers, Chrome and Firefox in particular, prohibit dynamic_cast in their code and libraries, and strictly use static_casto
If can afford to use dynamic_cast in your code then, arguably, you can afford to write in a type-safe language like Java or C#. That's more of a philosophical discussion but the whole point is that if you can turn static_cast to dynamic_cast temporarily for debugging, that's useful. You an probably do that with some creative macro wizardry but this solution appears to be much better as it also includes an improved runtime type system
You must be younger than me. I would love a medicine that made my not feel anything. I'll probably get modded as Funny (or ridiculous), but I'd really like to know what it is so I can ask my doctor. Do you mind sending me a message?
I actually read the paper (okay, mod me down). Java and.Net have very strong runtime typing systems. C/C++ does not. Adding one is a bit tricky because there are certain things that are legal in C/C++ and not Java. Specifically, it's okay to cast between two classes that are non-polymorphic (unrelated from a type system perspective). Also C/C++ applications often have some additional performance requirements. They've created a runtime typing system and then a mechanism (probably a pre-processor) that can cause static_cast and dynamic_cast to instead use their casting mechanism. You turn it on for debug and off for release. We already have things like debug heaps to look for memory corruption at a small performance cost why not also have a debug type checking system. And, of course, since it gets switched off in production builds, it doesn't have the runtime performance costs. It's one of those things that is obvious as soon as somebody does it. Those are often some of the best advances as they can have a lot of impact quickly.
If you are handling ITAR materials, you need to worry about more than just remote wipe. You're going to need a device that's "not compatible with anything." Doesn't matter if I can remote wipe the stolen device if all of the data has already leaked. This is where tools like MobileIron and BES come in. These solutions have both a server and a device component. (You don't notice the client portions on a BB10 since they are built in). They client apps attempt to keep the sensitive data isolated from other apps on the system in "virtual containers" (to use MobileIron's term). They also monitor devices for compliance with security policies. (Jailbreak your phone, no email for you). For some environments you can't just rely on remote wipe. You have to issue "locked down" hardware. Again we've digressed far from the initial discussion of whether Blackberry devices are compatible with anything to a (perhaps more interesting) one about MDM software.
In the end, third-party MDM software really isn't a good architectural model. The client software should be provided by the device manufacturers and made secure. BB10 OS, Android, and iOS all have to potential to provide what's needed here. Then you need to enforce the use of OEM firmware (which/.ers surely hate) and an entire trust chain. The equivalent of TPM for mobile devices. Security without it is almost impossible.
This works the same in Blackberry 10 the same as Android, iOS, and Windows Phone. The older (pre-QNX) Blackberries screen-scraped Outlook Web Access to get their mail if you didn't have BES. ActiveSync is probably good enough for 90% of organizations out there without any additional MDM software.
Oracle has a ton of money from locked-in customers. And they deploy that capital well. You will go buy from somebody else and then Oracle will buy that company and you're back to square one. Some product purchases (think ERP, et cetera) are like marriages only divorcing is much harder.
In general, "enterprise" software is crappy. Even if you get it from nice people.
In the physical lock example, there is no such thing. If the government has a warrant and determination they will enter and not be responsible for any damage. With cryptography, there are unbreakable locks which is why it creates a new situation.
Well first they tried to hack into Google's data centers without a warrant. https://www.washingtonpost.com... When that didn't work they tried to hack into the app stores, again without a warrant. https://firstlook.org/theinter... After that, Google et al cranked up the encryption. This is entirely a reaction to the US government trying to get data without a warrant. People didn't feel comfortable with that and wanted the device makers to protect data better. The manufacturers have responded to market demands.
The funny thing is that many companies running BES don't even need it. Pretty much any device out there (Blackberry, Android, iOS) will synchronize via ActiveSync without the need for any mobile device management software. Exchange servers supporting ActiveSync are available on the public internet and all you have to do is to point your device at it. In this scenario, I don't even see the expensive MDM products adding any value. There are *some* places where you can't get to ActiveSync over the internet due to firewall, you need to proxy it via something like BES or MobileIron. I'm not convinced that either of these solutions really add much value at all in most environments. But BES and Blackberry devices should not be confused. For most mail and calendaring setups, the devices (handsets) setup and configure exactly the same was an Android or iOS device would.
Not to mention that taxis *should* be taxed heavily as they use the roadways extensively. I guess the gas tax was put in place by the evil taxi cartels too and Uber should be exempt from that. What they can do is start operating their own gas stations and just don't charge the tax. Then when they get arrested, claim that the entrenched gas station industry is just trying to stifle innovation.
You're welcome to take your chances with Jury Nullification. It does exist for good purpose. But I don't consider protecting illegal taxi companies to be a good purpose. Better hope I'm not on your jury.
Slashdot Mirror
I can't really say anything about lambdas in C++ as I don't think I've ever even encountered something. In Java and C#, they are "syntactic sugar" in that they get expanded into more fundamental constructs. But they have stronger type-checking than an equivalent implemented with a preprocessor and are first-class entities. Passing a lambda to a function is not the same as passing the result of something from the preprocessor. The lambda gets executed in the future.
For whatever reason, the most negative people on /. always manage to get first posts. Some posters have already pointed out limitations but let's talk about the benefits of this.
If a bunch of hosts on my network start communicating in a way that they never have before, that me the sign that an infiltration has occurred. Inbound scanning looks for things trying to get through your firewall from the outside. But as we also point out on /. all the time, does almost nothing against social engineering attacks. It's not hard to get people to plug in USB thumb drives. (I've seen them given out by vendors at security conferences!) Nor can they resist attaching their personal devices to the corporate network.
Now you have a bunch of hosts making outbound connections to new places. Encrypted outbound traffic to IP addresses where FCrDNS fails. Worth investigating.
Of course this isn't a perfect solution, but it has at least some value. There is no claim that this is a replacement for other technologies only a supplement.
You keep saying things like "This and other fuzzing tools" even though it's been pointed out in this thread numerous times that the tool in the paper is not a fuzzing tool and it isn't even close. This tool is finding bugs, not coding errors. It's finding a situation where one object type is cast to another but at some point that cast has become incompatible but the compiler can't catch it. If the compiler can't catch it, it's unlikely that a human audit is going to do so. You would have to continuously audit every cast in the application. But even then you won't find this type of defect. Because the actual cast is never the bug. It's the semantic meaning of the data before and after the cast. And for that, no amount of C++ knowledge in the world will help you. You need to know the application domain and all parts of it. Your philosophical points may have validity. But it's hard to take them seriously when you can't (or won't) even use very basic terminology correctly. The fact that the words are new to you indicates that you've dismissed an entire part of the tools ecosystem without even learning about it.
Google doesn't have to do any such thing. They can just get rid of the legacy Java APIs and, instead, provide modern ones using lambda expressions. Then they can provide a tool chain that goes directly from source to .dx files and skips the whole Java .class file intermediate step. I'm surprised actually that we still even have to compile to Java classes. Then, in order to have write-once, run-anywhere we can get an ART VM for non-Android operating systems.
Prior to that, most software ran on C/C++ on Unix. Then people moved to Linux. Oracle's argument here would be that implementing libc on Linux shouldn't be allowed as it destroyed the value of Solaris. Maybe they will litigate this next. They can buy up SCO and make the same argument.
The issue isn't that the messages happen at compile-time it's that they are very long and hard to understand. We want the errors to be found at compile time (good), but the reason for that is that we want to *fix* the errors. And that's much harder to do if you can't understand the output. Granted it's much better than producing code with undefined behavior. When I started working with C++11, I found it almost impossible to understand the compiler error messages if they involved anything related to templates. The messages have gotten better and, of course, I'm used to them now. But coming from the Java world, it really felt like an exercise in futility sometimes. More effort spent on understanding a minor syntax error than on actually writing code.
I'm not sure this is a true statement. There are lots of good alternatives to preprocessors that achieve the same goals without many of the drawbacks. The first one I think of is lambda expressions. Granted Java didn't get them until very recently. Templates/Generics also take away a lot of the need for the preprocessor. Most preprocessor work is around portability and the allowing compilation with different compilers. There was a time when you needed a wide swath of compilers to get code running on different hardware. For certain embedded device development, headers with conditional defines still make a lot of sense. But if you're running on phone or laptop hardware (or better), you're better off moving to a two-stage compilation like Java or .Net.
I realize that you want to believe this and I hate to be the one to burst your bubble so to speak but the fact is that these types of defects exist in almost any non-trivial piece of software. However, rather than go back and forth, how about you offer up some code that you've written and we'll run some of the tools you so dislike. If your code comes out "clean," I'll concede the point. But I'm confident that won't happen. In any event these tools are still not glorified grep and it's not information that older people knew. Software systems have gotten much larger over time. There are whole new classes of bugs (like the ones in the article) that are introduced because the application is too large for the programmer to be familiar with the entire thing. No amount of knowledge of the programming language will help. It's often impossible to predict the consequences of changing one part of a system. For all we know, the identified defects are the result of two changes that were each correct in isolation but the combination was dangerous. It's easy for that to happen with multiple people committing code. I don't understand your desire to take something as complicated as writing software and simply say that all problems are because other programmers aren't as good as you are. It's a complex domain and we should be glad to have additional tools.
Fuzzing and grepping are entirely different things. If your original post hadn't gotten modded up, I probably wouldn't even respond. Fuzzing is a mechanism where cleverly malformed data is sent to an application or even a piece of hardware to see how it responds. Things like an invalid message with a proper authentication code. It's a pretty effective form of testing. In this context your comment might as well be. "Testing your software is just a poor man's method of finding errors (the real problem) in some code. Glorified greps." Ideally we aren't writing defects and are bug-free before a testing cycle, but that rarely (if ever) happens. Even if there are no verification defects there may be validation concerns. Both this and fuzzing are *dynamic* tools. Grep is a static tool although I don't know how it could possibly be employed in finding all but the most trivial defects. There are sophisticated static tools out there as well. (See FindBugs for an open source example of one). But these have nothing in common with grep.
Perhaps it is somewhat of a troll, but also makes a valid point. (I happen to like the sarcasm as well). We would like to think that all bugs are shallow given enough eyes. It's a reasonable mantra. And closed-source software has a history of eyes being intentionally closed (and the CSO getting mad at you for reporting bugs). Simple things like forgetting to close a file can be found through sheer determination. If the software is small enough for somebody to understand the whole thing, even the more complicated bugs may be found out this way. When things get large, you have experts who understand individual subsystems really well but for use cases that cross multiple sub-systems, subtle errors are made. These can't be found by looking at the code unless you know both subsystems very well. But there may not be anybody in that position so the bugs stay around a long time. For this type of situation you need better tools and a lot of progress has been made in this area. But given the number of bugs that get found in even good production software, there is still clearly a gap to fill.
From the paper: "Runtime type checking by dynamic_castis an expensive operation (e.g., 90 times slower than static_cast on average). For this reason, many performance critical applications like web browsers, Chrome and Firefox in particular, prohibit dynamic_cast in their code and libraries, and strictly use static_casto If can afford to use dynamic_cast in your code then, arguably, you can afford to write in a type-safe language like Java or C#. That's more of a philosophical discussion but the whole point is that if you can turn static_cast to dynamic_cast temporarily for debugging, that's useful. You an probably do that with some creative macro wizardry but this solution appears to be much better as it also includes an improved runtime type system
You must be younger than me. I would love a medicine that made my not feel anything. I'll probably get modded as Funny (or ridiculous), but I'd really like to know what it is so I can ask my doctor. Do you mind sending me a message?
Now if only conspicuous consumption would go away entirely!
I never even considered an Apple watch but if it looks like a calculator watch, I might go buy one. Maybe I could run a calculator app full screen!
I wish I had mod points. Alfalfa is something that, if there were any sanity to water pricing, would probably never be grown.
I actually read the paper (okay, mod me down). Java and .Net have very strong runtime typing systems. C/C++ does not. Adding one is a bit tricky because there are certain things that are legal in C/C++ and not Java. Specifically, it's okay to cast between two classes that are non-polymorphic (unrelated from a type system perspective). Also C/C++ applications often have some additional performance requirements. They've created a runtime typing system and then a mechanism (probably a pre-processor) that can cause static_cast and dynamic_cast to instead use their casting mechanism. You turn it on for debug and off for release. We already have things like debug heaps to look for memory corruption at a small performance cost why not also have a debug type checking system. And, of course, since it gets switched off in production builds, it doesn't have the runtime performance costs. It's one of those things that is obvious as soon as somebody does it. Those are often some of the best advances as they can have a lot of impact quickly.
If you are handling ITAR materials, you need to worry about more than just remote wipe. You're going to need a device that's "not compatible with anything." Doesn't matter if I can remote wipe the stolen device if all of the data has already leaked. This is where tools like MobileIron and BES come in. These solutions have both a server and a device component. (You don't notice the client portions on a BB10 since they are built in). They client apps attempt to keep the sensitive data isolated from other apps on the system in "virtual containers" (to use MobileIron's term). They also monitor devices for compliance with security policies. (Jailbreak your phone, no email for you). For some environments you can't just rely on remote wipe. You have to issue "locked down" hardware. Again we've digressed far from the initial discussion of whether Blackberry devices are compatible with anything to a (perhaps more interesting) one about MDM software. In the end, third-party MDM software really isn't a good architectural model. The client software should be provided by the device manufacturers and made secure. BB10 OS, Android, and iOS all have to potential to provide what's needed here. Then you need to enforce the use of OEM firmware (which /.ers surely hate) and an entire trust chain. The equivalent of TPM for mobile devices. Security without it is almost impossible.
Just wear a hijab.
This works the same in Blackberry 10 the same as Android, iOS, and Windows Phone. The older (pre-QNX) Blackberries screen-scraped Outlook Web Access to get their mail if you didn't have BES. ActiveSync is probably good enough for 90% of organizations out there without any additional MDM software.
Oracle has a ton of money from locked-in customers. And they deploy that capital well. You will go buy from somebody else and then Oracle will buy that company and you're back to square one. Some product purchases (think ERP, et cetera) are like marriages only divorcing is much harder. In general, "enterprise" software is crappy. Even if you get it from nice people.
In the physical lock example, there is no such thing. If the government has a warrant and determination they will enter and not be responsible for any damage. With cryptography, there are unbreakable locks which is why it creates a new situation.
Well first they tried to hack into Google's data centers without a warrant. https://www.washingtonpost.com... When that didn't work they tried to hack into the app stores, again without a warrant. https://firstlook.org/theinter... After that, Google et al cranked up the encryption. This is entirely a reaction to the US government trying to get data without a warrant. People didn't feel comfortable with that and wanted the device makers to protect data better. The manufacturers have responded to market demands.
The funny thing is that many companies running BES don't even need it. Pretty much any device out there (Blackberry, Android, iOS) will synchronize via ActiveSync without the need for any mobile device management software. Exchange servers supporting ActiveSync are available on the public internet and all you have to do is to point your device at it. In this scenario, I don't even see the expensive MDM products adding any value. There are *some* places where you can't get to ActiveSync over the internet due to firewall, you need to proxy it via something like BES or MobileIron. I'm not convinced that either of these solutions really add much value at all in most environments. But BES and Blackberry devices should not be confused. For most mail and calendaring setups, the devices (handsets) setup and configure exactly the same was an Android or iOS device would.
Not to mention that taxis *should* be taxed heavily as they use the roadways extensively. I guess the gas tax was put in place by the evil taxi cartels too and Uber should be exempt from that. What they can do is start operating their own gas stations and just don't charge the tax. Then when they get arrested, claim that the entrenched gas station industry is just trying to stifle innovation.
You're welcome to take your chances with Jury Nullification. It does exist for good purpose. But I don't consider protecting illegal taxi companies to be a good purpose. Better hope I'm not on your jury.