6 ms·

Why use C in 2024?

• Taniwha 3y ago
  strace works on anything that makes a system call - written in any language
  • amelius 3y ago
    Except it doesn't work on programs that call strace.
    • Retr0id 3y ago
      Why not? A simple "strace strace date" works on my machine.
      • amelius 3y ago
        Ok, well this used to be not the case.
        • Retr0id 3y ago
          It's always been the case, as far as I know. You may be thinking of the fact that you can't ptrace a process that's already being ptraced, which includes processes that are ptracing themselves.
          • amelius 3y ago
            Doesn't strace use the ptrace() system call under the hood?
            • Retr0id 3y ago
              Correct, which is why I'm mentioning it here. Stracing another instance of strace does not involve any of the processes ptracing themselves, though, and I don't think it ever has.
              • amelius 3y ago
                So they implemented recursion/reentrance as a special case?
                • deleted 3y ago
                  [deleted]
                • Retr0id 3y ago
                  The only constraint is that each process (or maybe each thread, I'm not sure off the top of my head) has at most one tracer. That constraint is not violated here. In the case of strace -> strace -> date, the middle strace has one parent and one child. That's fine. You can even have mutually recursive ptracing (occasionally used as an anti-debug strategy), since that doesn't violate the constraint either.
                • zbentley 3y ago
                  This isn't recursion. "strace strace foo" first runs the "strace" binary (PID X), which attaches one ptrace to "foo" (PID Y) and runs an I/O loop printing retrieved trace data. The outer "strace" call launches as PID Z, and attaches a ptrace to PID Y: the inner strace. The inner strace is not itself being ptraced until that happens, so there's no special case needed to allow "stracing strace". However, you may be referring to a different scenario: multiple ptrace calls do hit the same process if you (for example) run "strace -p PID" for the same PID more than once simultaneously. In that case, strace invocations after the first one will fail with an error like 'strace: attach: ptrace(PTRACE_SEIZE, PID): Operation not permitted'.
• LAC-Tech 3y ago
  strace is language agnostic. Any program that interacts with the OS - interacting with files, allocating memory, etc - will have to make system calls. Whether it's in C, Rust, Zig, Haskell, APL or Prolog.
  • senkora 3y ago
    I want to note that this is also true for “managed” languages like Java and Python. However, because these languages have a far heavier runtime than the “systems” languages, it is usually possible to trace them at the runtime level rather than the syscall level, and doing that will typically give a better experience.
• larschdk 3y ago
  You troll, but I'll feed you. There is no universally better language for portable high-performance system programming for resource constrained platforms. Every single alternative have unacceptable trade-offs.
  • flanked-evergl 3y ago
    What is the unacceptable tradeoff of rust?
    • larschdk 3y ago
      Not easily portable to most microcontroller targets: No SDK for our target SoCs and official SoC/µC support. Increased code size (which is also a performance issue in many SoCs). High cost of retraining engineers. High cost of reenginering existing code base and tooling. Lack of commercial support. I'm optimistic about Rust, and it taken great strides to replace C, but there are still many hurdles that prevent it replacing C in microcontrollers and SoCs. Even if it wasn't for the lack of a platform SDK and porting existing code, the risk is too great with lack of official support for many commercial SoCs.
      • flanked-evergl 3y ago
        Thanks for the response, this provides valuable insight to those not working in the industry.
      • genmud 3y ago
        What SoC are you using out of curiosity? ARM cortex, riscv and espresif all seem like they have first class support. Unless you are talking about peripherals in which case, why would you expect the language to write/maintain low level drivers? The hurdles to replace it in micros might be worth it depending on the team size and requirements. Personally, I wouldn't expect it to ever replace existing code bases, but could be a reasonable choice for greenfield designs.
        • larschdk 3y ago
• lelanthran 3y ago
  > Why use C in 2024? Jesus Christ, it's 2024! Enough with this constant insecurity that forces people to derail every damn unrelated thread with drive-by comments about how C programs should be rewritten in a different language.