Hacker News Reader

Comment by brohee | Hacker News Reader

The girl spewing some bullshit may lead to an interview ended early. Clearly bright, but not as bright as she think she actually is... Come back in a few years with a bit more humility... Hard to decide if the other guy is bad or inexperienced without a resume...

"If you compile in debug mode the runtime might try to be helpful and memset your stack memory to 0"

This is a retarded explanation (pages are set to 0 when they are recycled by the OS so you don't end up having data from dead processes mapped in your memory, with all the security implications). Also, actually randomizing memory in a debug context would actually be more helpful to trigger those initialization bugs...

People that think they know everything are a lot more dangerous than people actually aware of their limitation and safely working within them.

View on HN

Okay, you are assuming an Intel architecture? Plenty of embedded environments don't have OSes, let alone pages or virtual memory.

IOW, I've worked in environments where, yes, the value in memory is based on what the compiler does in debug mode, not what the OS might be doing. I'd say the girl's answer is, while not exhaustive, certainly correct. Without more context, we don't know why the value was 0.

You have printf, and the interviewer says "on my machine, I actually get 1, then 2, then 3". Those two hint very strongly at a general purpose computer, thus paging etc.

What really annoyed me is the suggestion that zeroing is more helpful than randomization in a debug context. Randomizing everything not defined by the standard is a good way to trigger lots of bugs based on false assumptions...

There are two legitimate concerns in a debug context. The first is predictability / repeatability; zeroing is substantially more helpful than randomization in this context.

The second is revealing incorrect assumptions / fuzzing / stress testing; zeroing is substantially less helpful than randomization in this context.

Ideally, both options would be available. When someone says "give me a debug build", I think it's probably correct that they are caring more about the former, but really it should be clear and controllable.

Predictability and randomization are not mutually exclusive, you only need a way to specify the seed for the PRNG used during randomization.

No, that addresses reproducibility, which is worthwhile but is not the same as predictability.

Predictability in this context means simplifying the problem. If uninitialized memory is nulled, then I know what I'm looking for/at more quickly. Likewise if it's set to any other particular, known value. I know it will (or won't) be failing null checks, and I know that it will (or won't) be segfaulting if dereferenced. This helps with characterizing and fixing bugs, (related to but distinct from detecting bugs in the first place). Relying on this to make the program work is bad, but that's not the same thing.

Slide #4 says: "Suppose you are about to interview a candidate for a position as a C programmer for various embedded platforms..."

MS Visual C initializes it to 0xCCCC so it's easy to spot. It helped me find a few errors.

Also 0xCC is the breakpoint opcode (INT3) on x86 architecture, so if the program were to start executing at that point, the debugger would be notified (or probably an immediate application crash if no debugger attached).

Reply on news.ycombinator.com