4 ms·

I've done kernel implementation for 20 years, and this question is absolutely terrible -- unless the answer that one is looking for is an intelligent explanatio

I've done kernel implementation for 20 years, and this question is absolutely terrible -- unless the answer that one is looking for is an intelligent explanation of why this is such a terrible question. It's an awful question because the kernel may not be involved at all on a user-level call to malloc() (e.g., a caching allocator like libumem or a traditional allocator that needn't extend the break for a given allocation), may be involved in a minor capacity if the break must be extended (on most systems, a system call and some VM interaction), or could be involved substantially if the allocator is a mapping allocator and page faults are induced (text and data) or scheduling events or anything else that necessitates kernel involvement. For whatever it's worth, when I have historically interviewed university hires for kernel positions, the question I ask is much simpler; namely, what does "* ((int *)NULL)" do? Sadly, most university students -- even ones who have done very well in their university computer science courses -- don't get this right. And it's sad because it's not really the question, but rather just the segue to the actual question: when a candidate correctly answers that NULL is dereferenced and the program crashes[1], I ask them to write the program (statement, really) in an assembly of their choosing (most graduates have MIPS or SPARC on the resume) and I then ask for everything that happens between the execution of that instruction and the resulting core dump and return of control to the shell. With a qualified candidate, this could easily be a multi-hour jaunt through microprocessor architecture and operating systems implementation. All of that said: I don't really do that anymore, but rather look to a candidate's open source works. The last kernel engineer I hired had done open source work that was so impressive that my interview consisted only of me determining that he had done the work himself -- which took all of 30 seconds or so. (He had, I hired him and he's been an absolutely terrific engineer.) Easiest interview ever! [1] Except on AIX and any other asinine system that maps NULL.

gizmo686 13y ago
>what does "* ((int * )NULL)" do Technically speaking, that is undefined. "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined...Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer,..."[1] [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 79
- bcantrill 13y ago
  Yes, yes. What I actually do is write about a five line program which -- absent fancy alias disambiguation -- can't be optimized out of crashing. You're hired, okay? ;)
elnate 13y ago
Is that an almost correct piece of code? What sort of situation would something like that come up in?
- gizmo686 13y ago
  Every hear of segfaults? They are almost always the result of de-referencing NULL.
  - thaumasiotes 13y ago
    I think of segfaults as being caused by accessing an out-of-bounds index in an array, personally. Yes, you can do the same thing by dereferencing NULL, but in my (university only) experience, overrunning an array came up much more often.
    - lubomir 13y ago
      In C it is quite common for functions to indicate failure by returning NULL. Not checking for these errors is another very common reason for segfaults.
    - kabouseng 13y ago
      In C, accessing an out of bounds array index does not necessarily cause a segmentation fault. It's called buffer overrun and regularly used in malicious exploits / attacks. What does occur many times is you mess up your stack, or mess with other memory in your heap, causing segmentation faults for various other reasons.
foobarbazqux 13y ago
> [1] Except on AIX and any other asinine system that maps NULL. It's pronounced "aches" for a reason.

gizmo686 13y ago

>what does "* ((int * )NULL)" do Technically speaking, that is undefined. "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined...Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer,..."[1] [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 79

bcantrill 13y ago
Yes, yes. What I actually do is write about a five line program which -- absent fancy alias disambiguation -- can't be optimized out of crashing. You're hired, okay? ;)

elnate 13y ago

Is that an almost correct piece of code? What sort of situation would something like that come up in?

gizmo686 13y ago
Every hear of segfaults? They are almost always the result of de-referencing NULL.
- thaumasiotes 13y ago
  I think of segfaults as being caused by accessing an out-of-bounds index in an array, personally. Yes, you can do the same thing by dereferencing NULL, but in my (university only) experience, overrunning an array came up much more often.
  - lubomir 13y ago
    In C it is quite common for functions to indicate failure by returning NULL. Not checking for these errors is another very common reason for segfaults.
  - kabouseng 13y ago
    In C, accessing an out of bounds array index does not necessarily cause a segmentation fault. It's called buffer overrun and regularly used in malicious exploits / attacks. What does occur many times is you mess up your stack, or mess with other memory in your heap, causing segmentation faults for various other reasons.

foobarbazqux 13y ago

> [1] Except on AIX and any other asinine system that maps NULL. It's pronounced "aches" for a reason.