shawxe

Thanks for letting me know, should be better now! :-)

First of all, there is no way the compiler is going to optimize a call to memset(&foo, 0, sizeof(foo)) when &foo is being interpreted as a void pointer. That doesn't even make sense.

Second of all, in a generic C interface keys are likely to be treated as void pointer and almost certainly are going to be moved around with memcpy etc. rather than returned/passed by value since doing so would make the interface non-generic.

sizeof(struct foo) is required to return the actual size, including padding, so

struct foo foo_inst; memset(&foo_inst, 0, sizeof(foo_inst));

will certainly result in all padding bytes being set to zero.

To be clear, there are obviously different/better ways to handle this in C++. We're talking about K&R C here.

Yeah, it's called memset. Not sure if this bug is supposed to be subtle or something, but if you require the padding bytes to be consistent then you need to consistently initialize your structs. Ignoring UB often leads to these sorts of bugs.

EDIT: Based on some of the comments I'm getting here, it seems like some of you have never implemented a hashmap/generic interface in vanilla C and it shows. If you want a hashmap that is generic and you don't want to write/specify a hashing function for keys on map initialization, then what you're likely to end up doing is ensuring that keys are initialized consistently, providing key size on map initialization, and simply performing a hash on the key as though it were a buffer of bytes.

Suggesting that this is somehow any more fragile than anything else in C or that templates should be used instead, which is an absurd comment since templates do not exist in C, is ridiculous. This comment is replying to a comment about how solutions to this problem have existed since K&R C--and they have. You don't need templates to not ignore UB, although if you are using C++ you can certainly use templates (and also take advantage of the stronger type system) to work around issues like this.

The point is that avoiding undefined behavior in C/C++ hashmap implementations is not something that has only recently become possible. C solutions may be more fragile, but that doesn't stop them from being "correct" in that will yield correct behavior unless an error is made elsewhere. Code that makes assumptions about the values of padding without explicitly setting those values is NOT correct and for anyone who works in a language like C/C++ regularly, that should be obvious.

DuckDuckGo itself supports this. Just start a query with !g to have it routed to Google. For example, "!g search on Google" would bring you to the Google search results page for "search on Google."

DuckDuckGo supports several other commands like this, which they refer to as "bangs."

https://duckduckgo.com/bang

This is fine, but it somewhat defeats the purpose of the opaquely prefixed header. I think the idea is just to be able to treat an SDS like a normal string. Unfortunately, there's no way to have that property not be commutative in C.

Seconded. The current title is misleading and not fact based.

That's what strlcpy() is for.

Yeah, not a lawyer outside of my armchair, but I don't really see how they could ever be convicted of any of this. It sounds like there's a very good chance they were contracted by a legitimate security auditing firm to do a job of a nature they had no reason to believe was not already outlined some statement of work agreed upon by all parties. Even if there was some misunderstanding, it sounds like the fault lies with the firm rather than with the contractors themselves. Obviously there are more facts that would need to be reviewed to come to definitively arrive at a conclusion like this, but at a glance this whole thing seems ridiculous.

Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."

Honestly, these doors are terrible. I just moved out of an apartment building where they were for some reason required and everything from carrying in furniture to carrying in groceries. I know this is extremely tangential, but if anyone can speak to exactly how/why these are supposed to improve outcomes in the event of a fire, I'd love to hear it.

But isn't that exactly what he's doing by inventing these signs--creating shorter names so that it isn't necessary to finger spell everything out explicitly?

Am I the only person who actually finds Esc easier than C-[ or Caps Lock? Maybe it's just heavy muscle memory at this point, but I've been using Esc for years and every time I try to use anything else it just feels clunky.

> 1. They will be exposed to Qwerty on devices where touch-typing is meaningless, such as smartphones and tablets.

I'm not sure having a keyboard layout completely interalized is ever really meaningless. For example, I typed this entire reply on my phone without looking at the keyboard once, based solely on knowledge of the positions of the different keys in relation to one another. Furthermore, even if I had been looking at the keyboard, having memorized the locations of everything in some part of my mind would definitely make it faster to type than if I had no idea where anything was. Besides, if someone were most familiar with a non-Qwerty layout, why wouldn't they just set their phone to that?

Why not just use int main(void)?

The book "Stat-Spotting: A Field Guide to Identifying Dubious Data" by Joel Best goes into a lot of this kind of stuff. Some of the examples here (and in that book) seem so obvious once you hear/see them from the right angle, but it can actually be surprisingly easy for otherwise intelligent people to be deceived by data trickery.

Am I the only one who is made extremely uncomfortable by the bizarre diagonal margins on the linked page?

I'd like to see such a comparison too. I've been considering switching to YouCompleteMe from ctags/cscope, but this looks like it might be even nicer, especially since a number of my teammates already use Intellisense with other editors.

When I'm forced to use Windows (which is pretty much just at work), I run an X server through Cygwin then use URxvt with GNU screen. I haven't found a Windows console application that doesn't play nicely with this when run through winpty, so for me it's the best of both worlds. I have used ConEmu and Cmndr, but I found them both to be nowhere near as reliable as my current setup (much like how WSL still can't touch Cygwin for my use case).

WSL filesystem performance is garbage, for one thing. Chances are good that if you're using Windows but you want to be using a Unix OS, it's your work that's forcing you to use Windows. And, if that's the case, chances are also good that the reason for that has something to do with a slew of legacy software that only runs on Windows. If both of those things are the case and you're trying desperately to develop a Unixy workflow, very clean integration with native Windows binaries is an unfortunate must. Cygwin delivers in that area much more effectively than WSL. Obviously Unix is my preference, but if I can't have Unix than I'd rather have Unix tools on the OS I'm being forced to use than a Unix sandbox will always be less than a real Linux/BSD install but fails to integrate properly with the OS I'm using by necessity.

The funny thing about both Cygwin and WSL is that, in my experience, many of the people who make use of them wish that they didn't have to make use of them. For me, Cygwin makes it a little easier for me to forget I'm not where I want to be (especially with things like winpty and apt-cyg). In Cygwin I can run URxvt just like at home, and run all the nonsense legacy software I need to for work, just like it were actually reasonable. In WSL, I can do none of that. It just doesn't work. I have a few co-workers who run WSL alongside cmd.exe. If I'm going to have to do that, I'd rather just stick to Cygwin.

The pipe is an operator overload. That said, while I wouldn't exactly call it idiomatic, it's not entirely unheard of in third party libraries. RxCpp (https://github.com/ReactiveX/RxCpp), the C++ ReactiveX library, makes use of a similarly overloaded pipe operator, for example.

Personally, I think I'd be more apt to use the "functional" style.