3 ms·

I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined be

I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.

waiseristy 4y ago
I would bet that the vast majority of undefined behavior encountered is when interacting with the standard library though. Which isn’t really the languages fault (But, I also totally concede that a language is inseparable from its std lib in reality)
- deleted 4y ago
  [deleted]
Espressosaurus 4y ago
The number of people I have interviewed that have used C and C++ for years and can't tell me what undefined behavior is is too damned high. I've had one or two, and only one of them could give me a coherent answer of what the compiler is allowed to do if it runs across it. In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them. Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.
- waiseristy 4y ago
  We’ve been really spoiled by modern compilers and operating systems which let you get away with large swaths of undefined behavior. You typically don’t know what is hidden from you
- simplotek 4y ago
  > Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field. Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those? I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.
- scotty79 4y ago
  > Which is stupid since undefined and unspecified behaviors are hugely important to ... Why are they though? Should they be?
mpweiher 4y ago
Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.
- the_why_of_y 4y ago
  Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
  - mpweiher 4y ago
    > Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Therefore Why therefore? > a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory. If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on. That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB. And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward. ¯\_(ツ)_/¯
  - scotty79 4y ago
    > Use-after-free or double-free is undefined behavior. It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.
- cycomanic 4y ago

I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.

waiseristy 4y ago

I would bet that the vast majority of undefined behavior encountered is when interacting with the standard library though. Which isn’t really the languages fault (But, I also totally concede that a language is inseparable from its std lib in reality)

deleted 4y ago
[deleted]

Espressosaurus 4y ago

The number of people I have interviewed that have used C and C++ for years and can't tell me what undefined behavior is is too damned high. I've had one or two, and only one of them could give me a coherent answer of what the compiler is allowed to do if it runs across it. In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them. Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.

waiseristy 4y ago
We’ve been really spoiled by modern compilers and operating systems which let you get away with large swaths of undefined behavior. You typically don’t know what is hidden from you
simplotek 4y ago
> Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field. Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those? I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.
scotty79 4y ago
> Which is stupid since undefined and unspecified behaviors are hugely important to ... Why are they though? Should they be?

mpweiher 4y ago

Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.

the_why_of_y 4y ago
Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
- mpweiher 4y ago
  > Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Therefore Why therefore? > a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory. If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on. That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB. And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward. ¯\_(ツ)_/¯
- scotty79 4y ago
  > Use-after-free or double-free is undefined behavior. It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.
cycomanic 4y ago