3 ms·

This sort of standards-purism goes too far, IMHO. The map is not the territory: C compilers are real, concrete things that have real behavior regardless of whe

This sort of standards-purism goes too far, IMHO. The map is not the territory: C compilers are real, concrete things that have real behavior regardless of whether that behavior is defined by an international treaty. "What does the C standard require of an implementation when given this program" and "based on your experience, how might you expect a typical implementation to react to this?" are different questions, but both are interesting. None of this implies, of course, that I think it's a good idea to write UB! But I think an ideal candidate would both know what UB is and also some of the ways it manifests in practice. If you don't know that code often segfaults on null dereference, you are going to have a very hard time debugging segfaults that you see in the real world.

Gibbon1 7y ago
Far as I've seen on systems with MMU's generally you get page fault. And then the OS handles that and issues a seqfault. Which is what happens usually when you start trying to poke at random addresses. On an ARM Cortex, if you try and read a null pointer you get the top of stack address. Least on my machine/compiler. If you try and write, then you get a bus fault. Beacuse flash memory is mapped to that address. On an AVR, I think reading gives you the reset vector. And write to address 0 is useally a nop. I think with some magic though you can write to that page of flash. So yeah. Kinda depends.
gravypod 7y ago
The only correct answer would be "you dereference a null pointer". That is the only part of this equation the c language interacts with. That's the entire reason SIGSEGV is a signal to your process. Page faults or access violations are manifested as interrupts in most systems. In some systems there are no such restrictions. Even in C & x86 within RING 0 you should be able to access ((char )0). I've even made an example branch on an old kernel I was making when I was in highschool to test this and it does work [0]. What is unfortunate is that everyone is looking for a different kind of person. If I'm applying to a job, saying "segfault" might be the right answer OR it will be the wrong answer and the interviewer will leave thinking I don't know how this fundamental functionality (in some industries) works. I could also give the more correct answer and look like a know-it-all which, when I'm trying to sell myself based on what I know, is somehow a bad thing. It's a loss no matter which way I play it. I distinctly remember one interview where someone asked me to define a RESTful API for a chat service. So I naturally defined the different objects (ChatRoom, Message, User) and defined what CREATE, LIST, DELETE on them all did. The interviewer was confused because CREATE&LIST are not HTTP methods and I explained that RESTful design isn't really coupled to HTTP and these objects and the operations we can perform with them could be implemented over an RPC or HTTP/json and I listed the steps for both of these approaches. He cut the interview short and I never heard from that company again. [0] - https://github.com/gravypod/Simple-OS/commit/b7a608500b2e70dc0cc2b939ba1bd6381e555bd8#diff-cdd8f39dc4ace4d761440f54b310f2f6R23 https://github.com/gravypod/Simple-OS/commit/b7a608500b2e70d...
- umanwizard 7y ago
  You make it sound like there is no right answer, but why couldn't you just explain to the interviewer everything you wrote in this post? "Well, according to the C standard it is undefined behavior. In context X it performs like Y" and so on.
amluto 7y ago
How about “are you aware that this ‘segfault’ may be turned into RCE by a clever compiler plus a clever attacker”? This may not be such a good interview question but, in most industries, C programmers should internalize this.
gizmo686 7y ago
An ideal candidate would have been bitten by bugs where the segfualt never happens because the offending code got optimized away. Once you've been bitten by that once, it become hard to answer with just "segfault".
- umanwizard 7y ago
  I am not suggesting someone should answer with "segfault" and in fact I think that might be a worse answer than just "UB". A good answer would be something like "UB according to the standard, but often segfault in real-world code on x86"...
- deathanatos 7y ago
  I'm not sure it even has to get optimized away. Stuff like, Foo *ptr = NULL; ptr->member... isn't going to access address 0, even w/o optimizations, despite the only pointer here being null. (It depends on the offset of "member", and if that offset is large enough, it might not be in the first page anymore. What's mapped at 0x1000 and later?)

Gibbon1 7y ago

Far as I've seen on systems with MMU's generally you get page fault. And then the OS handles that and issues a seqfault. Which is what happens usually when you start trying to poke at random addresses. On an ARM Cortex, if you try and read a null pointer you get the top of stack address. Least on my machine/compiler. If you try and write, then you get a bus fault. Beacuse flash memory is mapped to that address. On an AVR, I think reading gives you the reset vector. And write to address 0 is useally a nop. I think with some magic though you can write to that page of flash. So yeah. Kinda depends.

gravypod 7y ago

The only correct answer would be "you dereference a null pointer". That is the only part of this equation the c language interacts with. That's the entire reason SIGSEGV is a signal to your process. Page faults or access violations are manifested as interrupts in most systems. In some systems there are no such restrictions. Even in C & x86 within RING 0 you should be able to access ((char )0). I've even made an example branch on an old kernel I was making when I was in highschool to test this and it does work [0]. What is unfortunate is that everyone is looking for a different kind of person. If I'm applying to a job, saying "segfault" might be the right answer OR it will be the wrong answer and the interviewer will leave thinking I don't know how this fundamental functionality (in some industries) works. I could also give the more correct answer and look like a know-it-all which, when I'm trying to sell myself based on what I know, is somehow a bad thing. It's a loss no matter which way I play it. I distinctly remember one interview where someone asked me to define a RESTful API for a chat service. So I naturally defined the different objects (ChatRoom, Message, User) and defined what CREATE, LIST, DELETE on them all did. The interviewer was confused because CREATE&LIST are not HTTP methods and I explained that RESTful design isn't really coupled to HTTP and these objects and the operations we can perform with them could be implemented over an RPC or HTTP/json and I listed the steps for both of these approaches. He cut the interview short and I never heard from that company again. [0] - https://github.com/gravypod/Simple-OS/commit/b7a608500b2e70dc0cc2b939ba1bd6381e555bd8#diff-cdd8f39dc4ace4d761440f54b310f2f6R23 https://github.com/gravypod/Simple-OS/commit/b7a608500b2e70d...

umanwizard 7y ago
You make it sound like there is no right answer, but why couldn't you just explain to the interviewer everything you wrote in this post? "Well, according to the C standard it is undefined behavior. In context X it performs like Y" and so on.

amluto 7y ago

How about “are you aware that this ‘segfault’ may be turned into RCE by a clever compiler plus a clever attacker”? This may not be such a good interview question but, in most industries, C programmers should internalize this.

gizmo686 7y ago

An ideal candidate would have been bitten by bugs where the segfualt never happens because the offending code got optimized away. Once you've been bitten by that once, it become hard to answer with just "segfault".

umanwizard 7y ago
I am not suggesting someone should answer with "segfault" and in fact I think that might be a worse answer than just "UB". A good answer would be something like "UB according to the standard, but often segfault in real-world code on x86"...
deathanatos 7y ago
I'm not sure it even has to get optimized away. Stuff like, Foo *ptr = NULL; ptr->member... isn't going to access address 0, even w/o optimizations, despite the only pointer here being null. (It depends on the offset of "member", and if that offset is large enough, it might not be in the first page anymore. What's mapped at 0x1000 and later?)