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

41–50 of 55 posts

Re: Can We Trust the Libraries We Use?

#41

Post by jenscow »

mkal_tsr wrote: post #21
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.

You, the user of the library, don't care about finding any bugs in parts of the library that your application isn't using.

Your tests will be testing the parts of code in the library that your application uses, which is the part that matters to you.

Re: Can We Trust the Libraries We Use?

#43

Post by clarry »

jenscow wrote: post #41
mkal_tsr wrote: post #21

Earlier quoted context omitted.

> 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.

You, the user of the library, don't care about finding any bugs in parts of the library that your application isn't using. Your tests will be testing the parts of code in the library that your application uses, which is the part that matters to you.

You can still have bugs in parts of code that you use (or would use) given the right inputs. The problem is making your tests so diverse that they test every possible input.

Re: Can We Trust the Libraries We Use?

#44

Post by mkal_tsr »

jenscow wrote: post #41
mkal_tsr wrote: post #21

Earlier quoted context omitted.

> 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.

You, the user of the library, don't care about finding any bugs in parts of the library that your application isn't using. Your tests will be testing the parts of code in the library that your application uses, which is the part that matters to you.

Are you sure you understand how programming and testing works?

Re: Can We Trust the Libraries We Use?

#45

Post by jmspring »

GrinningFool wrote: post #39
collyw wrote: post #7

Depends where they come from. The average Python or Perl library seems better written and more tested that something I would write myself. JavaScript seems to have a lot less quality in my experience.

I was thinking about that in response as well; then I began to wonder. Is it that the quality is actual higher, or that I'm more likely to gravitate towards established, well-tested libraries (of which there are fewer in javascript)? The more I think about it, the more I think it's the latter. There are tons of crap libraries out there for any language - but the more mature languages/ecosystems naturally tend to have…

Think about node modules. How often have you done an n install only to have 10+ other libraries brought in. Some are going to be decent, some not.

I've found oddities like improper implementations of http digest auth and what not. When libraries are small you can sometimes catch these things easily.

Re: Can We Trust the Libraries We Use?

#46

Post by protonfish »

hrjet wrote: post #38

Java has a very good sand-boxing mechanism (AcessController), which helps limit the effect of bugs in libraries. Firstly, the memory model is highly abstract; no pointer arithmetic and type-less references. To mess with the memory, the thread needs to drop down to native code, and this where sandboxing can trap this behavior. The same mechanism can also help increase trust in a third-party library from a security poi…

Compare this with the worst library include language: JavaScript. There is no sand-boxing at all - code is simply inlined. (PHP's require does this too.) But for some reason web developers pile on the shady libraries when they should be extremely discerning.

Re: Can We Trust the Libraries We Use?

#47

Post by pjmlp »

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…

Funny enough in a sad way, static analysis tooling was part of the original C tooling, but when developers started creating C compilers for systems other than UNIX, lint seldom came along.

It also did not help the way C compiler phases were split.

If anything, we have to thank LLVM guys for making static analysis part of clang.

Re: Can We Trust the Libraries We Use?

#48

Post by Mathiasdm »

tokenrove wrote: post #36
nullc wrote: post #35

> A variable is assigned its own value. Self assignment is used to silence overly aggressive and incorrect uninitialized warnings in GCC (esp prior to 4.5). I'm not sure if thats what the code there is doing— not enough context, but I'd guess it's likely. Odd that the author hasn't seen that before.

That seems unlikely to be the case; the variable being assigned is through a pointer to a struct, which is already being accessed in the context. (Plus, of course, __attribute__((unused)) or similar in a macro would be preferable for silencing warnings) It's pretty likely that, had this occured at the top of a function, and been a direct assignment, the author would not have flagged it (indeed, perhaps PVS-Studio ign…

__attribute__((unused)) indeed would be the best option when using gcc. I believe when using C++11, this can be replaced by [[gnu::unused]].

Another one that I've seen quite often is casting to void.

Re: Can We Trust the Libraries We Use?

#49

Post by 6d0debc071 »

glibgil wrote: post #26
6d0debc071 wrote: post #18

Depends what your use case is.

In this case it is bugs that can be discovered and fixed through static analysis. What about this case?

If your definition of trust is that it passes static analysis without throwing any warnings, then you probably can't trust it. But this is hardly a new or useful insight, almost all code has known bugs in it at the time it ships and the additional value of discovering another bug is generally quite low. The value of discovering bugs lies in understanding how they relate to an undesired behaviour of a running system.

Re: Can We Trust the Libraries We Use?

#50

Post by wldcordeiro »

protonfish wrote: post #46
hrjet wrote: post #38

Java has a very good sand-boxing mechanism (AcessController), which helps limit the effect of bugs in libraries. Firstly, the memory model is highly abstract; no pointer arithmetic and type-less references. To mess with the memory, the thread needs to drop down to native code, and this where sandboxing can trap this behavior. The same mechanism can also help increase trust in a third-party library from a security poi…

Compare this with the worst library include language: JavaScript. There is no sand-boxing at all - code is simply inlined. (PHP's require does this too.) But for some reason web developers pile on the shady libraries when they should be extremely discerning.

How many wheels have been rediscovered in the Javascript ecosystem? It seems to be a symptom of the ecosystem as a whole.
Post reply on HN