Think of TOR as acting like a VPN or point-to-point tunnel. You can conceptually think of it as another network interface plugged into your network. The policy you choose what to route over it is your own. It doesn't affect how any other protocols function.
I can still access regular sites over TOR. I can also access regular websites over a VPN. openvpn+http:// isn't exactly useful either for the same reason.
And there are other special tld. Your multicast domain group (e.g. .local) is also special. Your dns resolver sees the TLD and resolves it specially. But once again, doing multicast DNS doesn't impact http, git, ssh, etc. So it be silly to have to write mdns+http://... as well.
And if you where to join them, then you have to describe what kind of behaviour should happen if, for example, on openvpn+http://foobar.tld you hit a hyperlink to http://baz.tld. Do I rewrite this to prepend openvpn+? Fail? etc.
ITts a lot better. I've ported libdbus-1 code to sd-bus and in practise I saw 100s of lines are replaced by about 20, with better error reporting on top of it.
Which, for example, is why you can't use `>` in `[` based expressions. Bash thinks you want to redirect the output of `[` to somewhere else. This restriction is lifted for `[[` and makes for much more natural looking code.
Ironically, if the given example was written in pure bash, it would be violating best practices. You don't parse ls line-by-line because you can't make the assumption that filenames will map to lines.
Taking this contrived example at face value, imho, I'd instead place the "best of bash" for the particular task with file globbing.
Well, in practice, it's both. Sure, stacks and heaps are an implementation detail, but they're pervasive. You simply can't write int x[10000][10000]; and expect it to not cause a stack overflow in any real world implementation. It's an implementation detail you absolutely need to be aware of.
Even ignoring personal taste: I care about MSVC. I also care about clang. GCC is the one compiler I'm able to not care about.
> IMHO new C code should be using the gcc cleanup extension
Even if I didn't care about MSVC, I'd disagree.
I'm OK with extensions that are "harmless" in that the program will still run without them working if I #if them out on other compilers - error pragmas, deprecation annotations, static analysis hints, pre-C++11 override keywords, etc.
I'm not OK with self inflicting vendor lock-in for something as important as cleanup rely on a specific compiler's extensions - especially not when we have a perfectly standard, portable, significantly better tested (and thus less likely to have bugs) reasonable alternative in the form of C++ destructors.
If I'm not using C++ destructors, it's either because:
1) I'm doing small changes to an existing C project (in which case I'd be stylistically inconsistent with it's preferred cleanup patterns for minimal gain, since it almost certainly doesn't use the gcc cleanup extension)
or
2) because I can't rely on having decent C++ compilers on my target platforms (which means I can't rely on having GCC either, and thus can't rely on the gcc cleanup extension by definition.)
> For what its worth, it is only MSVC without support.
How recently? I've been enough versions back that clang documented pragmas haven't been available. The cleanup attribute... I can only find docs for GCC. Although I see LLVM bugs for it, so you're right about clang supporting it - at least on HEAD.
> gcc compiler extensions are otherwise still rather portable.
Portable or not, I'd say only about half the extensions I've sought out on clang have actually been available. If that.
> To clang and icc at least.
I should note in scenario #2 above I don't have these available either, since these are decent C++ compilers.
I understand, but the question then becomes why your library depends on dlopen and why you don't offer an alternative static method as Qt's "plugins" do. Doesn't seem like good design on the part of the NSS devs to me, and probably a poor choice of library on the part of the systemd devs to me. But maybe I'm missing something.
