Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can We Trust the Libraries We Use?

viva64.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Can We Trust the Libraries We Use?

#21

Post by mkal_tsr »

ASneakyFox wrote: post #10

Typically you test your software to your needs. If there's a bug in a library you use it would show up when testing your code that uses the library.

> If there's a bug in a library you use it would show up when testing your code that uses the library.

That's not true at all. You may catch some lib bugs, but not all, even through testing of your own code that leverages the lib. Unless you're implying that you'll pass every possible value to your tests which will then cover 100% of any and all code in the lib.

Re: Can We Trust the Libraries We Use?

#22

Post by kabouseng »

You can't guarantee trusted software even your code and the libraries are 100% trusted / bug less, as the combined software creates emergent properties which will also have to be properly tested. As such you can only trust a software system if it has been properly tested.

If this is the case, then you can provide 100% trusted software even if it has been built with insecure code bases / libraries, as long as all the external interfaces has been tested for all possible inputs.

Off course this is extremely difficult / impossible. This is why we will never arrive at a point where software is 100 trustworthy.

edit - spelling

Re: Can We Trust the Libraries We Use?

#23

Post by arethuza »

Mikeb85 wrote: post #12

You have to, because there's no alternative. And even if it were possible to assure 100% safety from 100% of the code that runs on your computer, how do you know you can trust your hardware?

I guess one approach would be to dramatically simplify required functionality so that it doesn't require a general purpose computer to implement. You could even take things back to the point of having mechanical systems rather than electronic...

[NB I can remember in 1990s being on a project where someone was telling us about the safety shutdown equipment on a UK AGR nuclear power station - it was mechanical logic as when the plants were designed in the 1960s they wanted to use really well tried and tested technology.]

Re: Can We Trust the Libraries We Use?

#24

Post by franzb »

ris wrote: post #14

Another PVS Studio advert

Who cares. It's finding and reporting genuine bugs in widely used open source libraries, and most of the times it's even suggesting a fix or a workaround. Think about it: each article is worth half a dozen to a dozen high quality bug reports.

Moreover, the guys behind PVS-Studio seem like great guys. The CTO, Andrey Karpov, was interviewed in early 2014: http://www.viva64.com/en/b/0231/.

Selling software development tools isn't easy. PVS-Studio "adverts" are interesting and useful to the community.

Re: Can We Trust the Libraries We Use?

#25

Post by glibgil »

kabouseng wrote: post #22

You can't guarantee trusted software even your code and the libraries are 100% trusted / bug less, as the combined software creates emergent properties which will also have to be properly tested. As such you can only trust a software system if it has been properly tested. If this is the case, then you can provide 100% trusted software even if it has been built with insecure code bases / libraries, as long as all the…

Your comment provides no value. The OP has specific examples of tools being used to find bugs in software all without the need for testing. Testing is the least efficient way to fix those bugs. Tooling, as demonstrated in the OP, and other applications of programming language theory are far more efficient ways to have correct software. First, let the computer find the bugs we don't know about, then we can focus on higher goals.

Re: Can We Trust the Libraries We Use?

#27

Post by glibgil »

DanielBMarkham wrote: post #9

Test the hell out of anything you use, both hardware, software, and infrastructure -- and write the tests before you write any code. Double-down on that for stuff like medical tech. Now, is anybody doing that? Anybody? (Sound of crickets chirping)

The article is about static analysis. Static analysis is the most efficient way to catch a whole host of bugs. Testing would be a waste of everyone's time for these types of bugs. Now, the tools in the article are commercial and perform static analysis on C and C++. Other programming languages have static analysis and code path coverage analysis built into their compilers. Many of those languages are free. Writing tests to cover those types of bugs is time wasted on a problem that is already solved.

Re: Can We Trust the Libraries We Use?

#29

Post by glibgil »

Mikeb85 wrote: post #12

You have to, because there's no alternative. And even if it were possible to assure 100% safety from 100% of the code that runs on your computer, how do you know you can trust your hardware?

Let's down-vote these types of comments that answer, vaguely, the question proposed in the headline and reveal that they did not even skim the topics in the OP. Totally worthless.

Re: Can We Trust the Libraries We Use?

#30

Post by DanielBMarkham »

glibgil wrote: post #27
DanielBMarkham wrote: post #9

Test the hell out of anything you use, both hardware, software, and infrastructure -- and write the tests before you write any code. Double-down on that for stuff like medical tech. Now, is anybody doing that? Anybody? (Sound of crickets chirping)

The article is about static analysis. Static analysis is the most efficient way to catch a whole host of bugs. Testing would be a waste of everyone's time for these types of bugs. Now, the tools in the article are commercial and perform static analysis on C and C++. Other programming languages have static analysis and code path coverage analysis built into their compilers. Many of those languages are free. Writing te…

I completely agree.

I won't change my initial comment, but please be aware that by "testing" I also meant static code analysis. (Thought had it covered with software, hardware, and infrastructure, but forgot one)

Post reply on HN