8 ms·

I agree, it's very click-baity. C is actually great and is only really dangerous because it gives the programmer so much control.

by aogl 8y ago

willtim 8y ago
C actually gives one rather limited control over modern hardware with it's memory hierarchies and superscaler CPUs. Programming language research has also moved on a lot since the 70's, which is why we should be considering less dangerous languages (e.g. better type systems and less undefined behaviour). Languages like ATS and Rust also support explicit memory management, whilst being a whole lot safer.
- millstone 8y ago
  Are you suggesting that other languages provide more control over modern hardware?
  - willtim 8y ago
    Yes. Currently access to modern hardware features are either via cumbersome APIs (e.g. NUMA, AVX intrinsics), handled via the OS (e.g. paging, scheduling), or handled via the hardware itself (cache memory hierarchy). The problem will get worse as modern CPUs and machines continue to diverge from those originally targetted by C in the 1970s.
- pjmlp 8y ago
  Even in the 70's there was NEWP, PL/I, PL/S, PL/8, Concurrent Pascal, Mesa, BLISS, Modula-2, .... C wins them all in implicit conversions and opportunities for memory corruption. Their major sin was to be tied to commercial OSes, instead of one with source code available for a symbolic price to universities.
- vardump 8y ago
  C alone doesn't provide the control directly, but you as a programmer can absolutely leverage C to take control of the memory hierarchies by controlling your data access patterns. IOW, high locality of reference. Good C-compilers will most of the time take care of the superscalar CPU friendliness. When they don't, you can always drop down to the assembler level, and it'll mesh well with C.
  - willtim 8y ago
    High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell has support for this). But this is a long way from having complete control how each memory heirarchy is used. Likewise most static languages defer to the compiler for CPU-specific performance optimisations and will permit foreign native calls into C or ASM where necessary. So I don't see how this is an argument in C's favour.
    - vardump 8y ago
      > High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell supports this). You often also need correct alignment. Cache-line or page. Your unboxed access across two pages can cause two TLB misses, L1 misses etc. Not to mention two page faults. Sometimes you need to ensure two (or more) buffers are NOT aligned in a particular way to avoid interfering with CPU caching mechanisms.
      - willtim 8y ago
        The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.
        vardump 8y ago
        That's not true. You can also control data alignment in various ways. For example, you don't need to write to the beginning of an allocated buffer, but skip to the point where low order address bits are what you want. Something like this for example: char* aligned_buf; char* buf; size_t max_align_offset = (1<<align) - 1; buf = malloc(length_needed + max_align_offset); aligned_buf = (buf + max_align_offset) & ~max_align_offset; In the example, if align==8, you have 256 byte alignment. If it's 12, 4kB alignment.
        8y ago
buboard 8y ago
"Programmers using C are considered dangerous"
pietroglyph 8y ago
> C is actually great and is only really dangerous because it gives the programmer so much control. This doesn't actually refute the assertion that C is dangerous :) Control and increased safety are not mutually exclusive. I'll take safe-by-default, unsafe-when-asked any day. It's not 1972 anymore.
simias 8y ago
I'm a C coder first and foremost and I strongly disagree with this mentality (even though I know it's extremely pervasive in our circles). "Footguns don't make bugs, coders do" is technically true but if we could keep the footguns at a minimum and only get them out of the locker when truly necessary instead of having them spread all over the place all the time I'm sure it wouldn't hurt. C is a very useful language and one you basically have to know if you're interested in low level software but it's very, very far from flawless. If you look at many high profile software vulnerabilities of late (heartbleed, goto fail, etc...) many can be traced to the lack of safety and/or bad ergonomics of the C language. We need to grow up as an industry and accept that using a seatbelt doesn't mean that you're a bad driver. Shit happens.

I agree, it's very click-baity. C is actually great and is only really dangerous because it gives the programmer so much control.

by aogl 8y ago

I agree, it's very click-baity. C is actually great and is only really dangerous because it gives the programmer so much control.

willtim 8y ago

C actually gives one rather limited control over modern hardware with it's memory hierarchies and superscaler CPUs. Programming language research has also moved on a lot since the 70's, which is why we should be considering less dangerous languages (e.g. better type systems and less undefined behaviour). Languages like ATS and Rust also support explicit memory management, whilst being a whole lot safer.

millstone 8y ago
Are you suggesting that other languages provide more control over modern hardware?
- willtim 8y ago
  Yes. Currently access to modern hardware features are either via cumbersome APIs (e.g. NUMA, AVX intrinsics), handled via the OS (e.g. paging, scheduling), or handled via the hardware itself (cache memory hierarchy). The problem will get worse as modern CPUs and machines continue to diverge from those originally targetted by C in the 1970s.
pjmlp 8y ago
Even in the 70's there was NEWP, PL/I, PL/S, PL/8, Concurrent Pascal, Mesa, BLISS, Modula-2, .... C wins them all in implicit conversions and opportunities for memory corruption. Their major sin was to be tied to commercial OSes, instead of one with source code available for a symbolic price to universities.
vardump 8y ago
C alone doesn't provide the control directly, but you as a programmer can absolutely leverage C to take control of the memory hierarchies by controlling your data access patterns. IOW, high locality of reference. Good C-compilers will most of the time take care of the superscalar CPU friendliness. When they don't, you can always drop down to the assembler level, and it'll mesh well with C.
- willtim 8y ago
  High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell has support for this). But this is a long way from having complete control how each memory heirarchy is used. Likewise most static languages defer to the compiler for CPU-specific performance optimisations and will permit foreign native calls into C or ASM where necessary. So I don't see how this is an argument in C's favour.
  - vardump 8y ago
    > High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell supports this). You often also need correct alignment. Cache-line or page. Your unboxed access across two pages can cause two TLB misses, L1 misses etc. Not to mention two page faults. Sometimes you need to ensure two (or more) buffers are NOT aligned in a particular way to avoid interfering with CPU caching mechanisms.
    - willtim 8y ago
      The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.
      - vardump 8y ago
        That's not true. You can also control data alignment in various ways. For example, you don't need to write to the beginning of an allocated buffer, but skip to the point where low order address bits are what you want. Something like this for example: char* aligned_buf; char* buf; size_t max_align_offset = (1<<align) - 1; buf = malloc(length_needed + max_align_offset); aligned_buf = (buf + max_align_offset) & ~max_align_offset; In the example, if align==8, you have 256 byte alignment. If it's 12, 4kB alignment.
        8y ago

buboard 8y ago

"Programmers using C are considered dangerous"

pietroglyph 8y ago

> C is actually great and is only really dangerous because it gives the programmer so much control. This doesn't actually refute the assertion that C is dangerous :) Control and increased safety are not mutually exclusive. I'll take safe-by-default, unsafe-when-asked any day. It's not 1972 anymore.

simias 8y ago

I'm a C coder first and foremost and I strongly disagree with this mentality (even though I know it's extremely pervasive in our circles). "Footguns don't make bugs, coders do" is technically true but if we could keep the footguns at a minimum and only get them out of the locker when truly necessary instead of having them spread all over the place all the time I'm sure it wouldn't hurt. C is a very useful language and one you basically have to know if you're interested in low level software but it's very, very far from flawless. If you look at many high profile software vulnerabilities of late (heartbleed, goto fail, etc...) many can be traced to the lack of safety and/or bad ergonomics of the C language. We need to grow up as an industry and accept that using a seatbelt doesn't mean that you're a bad driver. Shit happens.