User: Password:
|
|
Subscribe / Log in / New account

A longstanding GnuTLS certificate validation botch

A longstanding GnuTLS certificate validation botch

Posted Mar 5, 2014 16:12 UTC (Wed) by mpr22 (subscriber, #60784)
In reply to: A longstanding GnuTLS certificate validation botch by zorro
Parent article: A longstanding GnuTLS certificate validation botch

I cannot help wonder why such critical code is written in C and not C++.

Because libraries implemented in C++ generally only get used by programs written in C++, because interfacing to libraries implemented in C++ from any other language entails significant pain. I like C++, but I have no difficulty understanding why people don't use it to implement libraries intended for general adoption in non-C++ programs.


(Log in to post comments)

A longstanding GnuTLS certificate validation botch

Posted Mar 5, 2014 21:45 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> Because libraries implemented in C++ generally only get used by programs written in C++, because interfacing to libraries implemented in C++ from any other language entails significant pain.

What matters is the interface, not the implementation. You can have a library implemented in C++ but with a pure 'extern "C"' interface, and it'll be as easy to use as a library implemented in C.

No, the real problem with writing a library in C++ is the "which C++ runtime" question. The C++ ABI is not a solid as the C ABI, and there is more than one C++ runtime. Loading more than one C++ runtime on the same process, with the common ELF linking rules, is not a good idea.

(On Win32, there is more than one C runtime, but it's less of a problem because its symbol resolution rules make it easy to have several incompatible runtimes in the same process without many issues.)

But I believe the reason C is used instead of C++ is complexity and historical reasons. Many libraries were first written back when C++ compilers were not as good, so they used C by default; and C is simpler to write and understand.

A longstanding GnuTLS certificate validation botch

Posted Mar 6, 2014 3:10 UTC (Thu) by proski (subscriber, #104) [Link]

Does it mean "DLL hell" is now a problem on Linux and not on Windows? That's something to think about, especially if it hinders C++ adoption.

A longstanding GnuTLS certificate validation botch

Posted Mar 6, 2014 7:06 UTC (Thu) by Seegras (guest, #20463) [Link]

It still is a problem on Windows. And there's also a "Codec Hell" on Windows.

A longstanding GnuTLS certificate validation botch

Posted Mar 8, 2014 17:41 UTC (Sat) by smurf (subscriber, #17840) [Link]

… and hindering C++ adoption is a bad thing in what way exactly?

SCNR,

A longstanding GnuTLS certificate validation botch

Posted Mar 9, 2014 7:00 UTC (Sun) by HelloWorld (guest, #56129) [Link]

C++ is an abomination, and yet it's still much better than C.

A longstanding GnuTLS certificate validation botch

Posted Mar 10, 2014 19:05 UTC (Mon) by drag (subscriber, #31333) [Link]

> Does it mean "DLL hell" is now a problem on Linux and not on Windows?

It's always been a problem on both systems. Microsoft largely solved their issue by taking various approaches to versioning DLLs, preventing applications from overwriting library files, static compiling, heuristics involving locating and using libraries based on what was bundled with the applications and a few other things I only have a distant and vague memory of.

Linux distributions fixed it's own version this by simply making things really difficult for users that try to install anything that isn't carefully compiled, versioned, and controlled by whatever distribution they happen to be using. Then when users run into problems with missing libraries or conflicts they can are called idiots in online forums and such places for not using one of the applications that can be installed by the local package management software... and if that didn't work then the normal advice is to reformat the disk drive and install a different Linux OS that probably had a working version of whatever application they are struggling with.

> That's something to think about, especially if it hinders C++ adoption.

C++ ABI breakage caused myself and many other Linux users a huge number of headaches in the past. Now it's been a long time since I've ran into issue.

However I still consider it a very bad sign whenever I run into a applications or APIs that makes use of 'boost' or any similar binding generation thingy. If it happens to work, great, but if it doesn't then it's going to be a nightmare.

A longstanding GnuTLS certificate validation botch

Posted Mar 25, 2014 15:50 UTC (Tue) by nix (subscriber, #2304) [Link]

Uh, drag, Linux's DLL hell was largely (though not entirely) obviated by SONAMEs and symbol versioning. You seem to have become so obsessed with the claim that distributions are evil that you're allowing it to twist your view of the world into zones best described as mendacious reasoning.

A longstanding GnuTLS certificate validation botch

Posted Mar 25, 2014 17:21 UTC (Tue) by khim (subscriber, #9252) [Link]

Unfortunately that's not true. SONAMEs and symbol versioning could fix the “DLL hell” in theory, but they are not used consistently (libraries are not bumping SONAMEs when they change API and/or they don't use symbol versioning consistently thus you can not use different versions in the same process). In the end situation for third party developers is better in Windows: at least there you can use boost both in application and it's plugin even if versions of boost are different. On Linux… it does not really work.

A longstanding GnuTLS certificate validation botch

Posted Mar 25, 2014 18:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

After struggling with packaging application on Linux for multiple platforms I've learned to like Windows. It keeps developers honest - there is no single global prefix for libraries, so each dependency has to be referred specifically from the build files. So assembling all the dependencies in one installer package is pretty much trivial.

On Linux it's superficially easy to just install all the dependencies using apt-get or similar package managers. Everything will even work on developer's machine. But then comes the packaging time and extracting all these dependencies (even accidental ones) becomes a task which can easily result in a non-working package if you forget something.

And that's even without going into the !@#&!&*!^@ glibc versioning that forces me to use an ancient RHEL image to get a 'universal' binary.

A longstanding GnuTLS certificate validation botch

Posted Mar 6, 2014 20:19 UTC (Thu) by dashesy (guest, #74652) [Link]

Should also add that C++ is harder and fewer people can get it right, whereas some elite companies (Google, ...) can filter out people who do not understand stupid but hard C++ idioms like virtual inheritance, other projects should not raise the skill-set level too high to afford over their lifespan. In lay terms, you never know if the next person understands the *fancy* feature you like correctly, or just will screw things up.

A longstanding GnuTLS certificate validation botch

Posted Mar 6, 2014 22:07 UTC (Thu) by khim (subscriber, #9252) [Link]

Actually Google does not do that. It's just don't worth it.

What Google can do (and what it actually does) is creation of some kind of Google/C++ language where some missing pieces are filled with Libraries/base and where most problematic pieces are removed by a style guide.

This approach works, but it's really hard to do: in a sense that means that each С++ project uses it's own XXX/C++ language. The fact that there are no "battareis included" C++ is really hurting it. And no, boost is not it: it's just a pile of tricks some of which are great and some of which are really awful.

A longstanding GnuTLS certificate validation botch

Posted Mar 7, 2014 2:41 UTC (Fri) by dashesy (guest, #74652) [Link]

Yes the only sane way of using C++ is to take a subset of it and force it via policy, meanwhile enforce code review and the policy strictly.
I know many who love boost and cannot live without it, but IMO it is the worst type of hacks it is a language-level hack to foist C++ to something that it is not. This is besides the fact that one has to make sure the compiler itself knows C++ quirks enough to compile boost correctly!
On the other hand Qt is beautiful and can make C++ tolerable.

A longstanding GnuTLS certificate validation botch

Posted Mar 9, 2014 7:11 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> I know many who love boost and cannot live without it, but IMO it is the worst type of hacks it is a language-level hack to foist C++ to something that it is not.
This is Not Even Wrong. It's so vague it's meaningless and you're talking as if boost were a single library while in reality it's a collection of libraries, some of which are unquestionably great.

> This is besides the fact that one has to make sure the compiler itself knows C++ quirks enough to compile boost correctly!
The solution to broken compilers is to not use them.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds