I thought it was somehow referring to the "Captain's log" recordings.. Yeah, haven't watched that much star trek.
"Yeah, why not? He deserved it, burning his dog like that. Let's go to KFC to eat some of the most mistreated production animals ever."
Any time you join an existing project you have to learn how to use its libraries, this is no different. Yeah, maybe you'll save a few hours of learning time if some of it is standardized by the base language. If that becomes a real issue with someone you probably shouldn't have hired him/her anyway.
I'm not sure what you mean. It's possible to have arrays of ints, floats and everything. Looks to me like your idea would assume that array works only on structs? Anyway here's the implementation: http://hg.dovecot.org/dovecot-2.1/file/tip/src/lib/array.h
Well, that kind of GENERATE_SORT() seems very ad-hoc way to do it and very specific to a sort.. My method looks more like this (dynamically growing type safe arrays):
#include "array.h"
int foobar_cmp(const struct foobar *f1, const struct foobar *f2);
ARRAY_DEFINE(foobars, struct foobar);
struct foobar f;
array_init(&foobars, 16);
array_append(&foobars, &f);
array_sort(&foobars, foobar_cmp);
I don't think that's much different (or more difficult) from how you'd do it with C++ templates. Of course implementing array.h is easier with C++.
It's also very hard to write type safe code properly in C. Just look at the classic example of the unsafe qsort versus the safer and faster std::sort.
You can do all kinds of nifty stuff with macros and gcc/clang extensions to provide type safety to C. Yeah, if you don't already have a library for that it can be a bit difficult to write one (or find one you like). But once you have the library it's very easy to write (mostly) type safe code with C. For example I have a type safe array_sort() in C.
Except, of course, it isn't, the implications are completely different, and even the law thinks they're completely separate issues. Just like with copyright infringement. The only difference is that people take "rape" already seriously as is, so it doesn't have to try to _co-opt_ the term for another, separate crime. 'cause that's what the whole business with conflating copyright infringement with theft is _all about_. Nobody gives a shit about copyright infringement, so they try to leech off the badwill for the word "theft". Hell, maybe they should just say that copyright infringement is raping the artist. It's just as true, and there's even more badwill to be gathered.
Only reason they don't is that it'd take an even bigger moron to buy it.
So fuck this douche with his support for the copyright newspeak.
Tau is twice the constant Pi ever was!
I kinda did in my next sentence, but whatever..
But every implementation I've seen of a QR code reader in Android and IOS also gives you the option to inspect the content visually before acting on it. They ask if you want to proceed.
Of course one could argue the click-thru generation does not know enough to evaluate the content, but then these are the same people that no amount of malware/antivirus software can protect.
Is the confirmation something like OK/Cancel? I also tend to click OK buttons without hardly even reading them. That's why potentially security sensitive questions shouldn't have such simple buttons, but rather two (radio?) buttons that require you to read (and hopefully understand) what you're doing, such as: "Replace network settings from QR" and "Keep the existing network settings".
Yes, there are some advantages to using SQL database, like I said.. But I highly doubt "huge speed advantage" is one of them, unless you compare to a really badly set up system. I know people have switched from DBMail to Dovecot simply because Dovecot is so much faster..
Email isn't stored in SQL, because typically it's rather pointless. Full text search indexing doesn't require SQL, and it's more efficient without SQL anyway. There are some good use cases for storing emails in SQL database, but efficiency isn't one of them.
I wasn't planning on fixing all of security problems, but the typical case of clicking open random email attachments or running random programs from internet should and could be made safe, while still keeping the user interface user friendly. Those are the reasons for most of today's security problems.
Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker