10 ms·

Migrating to a pointer-size-pair string representation would be a better use of one's time.

• Gibbon1 5y ago
  I swear part of the problem is with C there is a cargo cult prohibition against passing small structs by value.
  • kzrdude 5y ago
    In other languages we create types for just about anything, and like you say, it's strange that we don't do this more in C.
    • Gibbon1 5y ago
      Big problem with C is the standards committee just flat out refuses to add an array type to C. It's deranged because if you had first class arrays it'd be a lot easier to generate code that takes advantage of SIMD instructions.
      • klodolph 5y ago
        You mean “add a second array type?” C has an array type, it’s just a bit wacky, and it doesn't play by the same rules as other types.
        • pjmlp 5y ago
          Yeah because requiring &array[0] instead of array is so much typing, UNIX V4 would never have been finished.
          • klodolph 5y ago
            You want to break existing code? If you made that change, you wouldn’t even be able to pass string constants into functions, because string constants are arrays (and not pointers, as some think). The C standard committee has a general policy of not breaking code. If you want something like C with a better type system and less of the broken stuff (hello, arithmetic conversions) you can try Zig or one of the others. Once you’re okay with breaking code, you call it a different language, and go in trying to fix lots of things. Unix V4 predates C standardization anyway.
            • Gibbon1 5y ago
              I think zig just blew a big gaping hole in the argument that the language needs to be tied to legacy code. Because zig can compile old C code and Zig into the same binary. Which means there is no reason you couldn't compile old legacy C code and new better C code into the same binary as well. The C standards committee need to be fired and replaced with people who aren't willfully holding the language back.
              • klodolph 5y ago
                Hm, I can understand where you’re coming from but I think you’re asking for something which provides negligible value and would require a significant amount of engineering effort. Additionally, the way in which you’re expressing your opinions about the C language is needlessly inflammatory. What’s most unreasonable about your comment is the way it attacks people. It seems like your issue here is really nothing more than the names of languages—your position is that there should be a language with clean semantics, interoperability with C, etc. and this language should furthermore be called “C”. A language exists—Zig—which seems to meet all your requirements except one. The only missing requirement, as far as I can tell, is that it is not called “C”. Let me know if there is something I misunderstand about your position, because I can’t think of a different way to interpret it. I can see where you’re coming from—but to be honest, unless I am misunderstanding your position, your position seems completely unreasonable, and again, the personal attacks are pointlessly inflammatory.
            • pjmlp 5y ago
              Who mentioned anything about breaking existing code? I already decided in 1992 that I don't want to use a broken language, unless when obliged by university work or work requirements. Unfortunely I have to use software written by people that don't share that opinion and apparently WG14 also has a general policy that improving C safety doesn't matter.
              • klodolph 5y ago
                > Who mentioned anything about breaking existing code? You did, when you proposed writing &array[0] to get the address to the first element of an array. Or maybe I misunderstand what you wrote, in which case you could clarify. > Unfortunely I have to use software written by people that don't share that opinion and apparently WG14 also has a general policy that improving C safety doesn't matter. What would WG14 be doing differently if they didn’t have this “policy”? Isn’t the obvious explanation that their top priority is to maintain compatibility with existing code? Is this explanation not satisfactory? It seems absurd—in the extreme—to expect a standards committee to break large swaths existing code to improve safety, in a language with such a large amount of legacy code such as C. I would expect that if the standards committee chose to do that, compilers wouldn’t implement it and users wouldn’t use it. If you are going to break existing code, why not use a different language?
  • saurik 5y ago
    It does suck that the usual 64-bit calling convention limits the size of strict passed by value to 64-bits :/.
    • thysultan 5y ago
      You could store two 32 bit fields and cast the second to a pointer when needed, and the first treat as a length.
    • gpderetta 5y ago
      At least linux AMD64 ABI allows passing (and returning) 128 bit structures by registers, which is perfect for the ptr/len case.
  • pjmlp 5y ago
    The cargo cult goes beyond that. The belief it was created alongside UNIX from the start, when it was used to port UNIX V4 into high level language. Micro-optimizing each line of code as it is written, "because it is fast", without even bothering to use a profiler. Even though lint was created alongside C to fix already known programmer faults using the language, in 1979, the belief that only bad programmers need such kind of tooling.
    • PaulDavisThe1st 5y ago
      > Micro-optimizing each line of code as it is written, "because it is fast", without even bothering to use a profiler. With the CPU, MMU and OS architectures of that period, it wasn't particularly hard to infer what was fast without profiling it. The slow rise in complexity at all 3 levels now makes it hard for even extremely experienced close-to-the-metal programmers to understand what will be fast or slow without a profiler. Times do change, in fact.
      • pjmlp 5y ago
        Yeah, except the world has moved on from PDP-11, no need to keep asserting something that isn't no longer true.
    • a1369209993 5y ago
      No, the problem on unix v4 (at least I think that's the version I'm talking about) was that the C compiler did not support passing structs - whether as arguments, return values, or any other expression. So, they didn't do that, because it wouldn't work, and it was less hassle to work around it than fix the compiler. The cargo cult is when people keep avoiding struct passing, even though that compiler deficiency has been fixed for decades now.
      • pjmlp 5y ago
        That isn't what I was talking about, rather that C only appeared on season 4 of the UNIX movie, when many think it was part of the original cast from the get go. So it gets a cargo cult status like UNIX was only possible because C was designed to make it happen and other bogus pocus that ignores almost 15 years of previous work in high level languages for systems programming.
  • b5n 5y ago
    It's not a cult, its just that the cases where the risks of passing by value would be worth any perceived advantage are so few that it just doesn't make sense to even consider it. It's not like it's a flimsy tribal based claim, the guidance is solid.
• radicalcentrist 5y ago
  Are there any recommended libraries for doing this, if I'd like to migrate my C codebase?
  • macintux 5y ago
    You might look at SDS. https://github.com/antirez/sds https://github.com/antirez/sds
  • deleted 5y ago
    [deleted]
• compiler-guy 5y ago
  And only works if you don't rely on any third-party libraries that take normal C strings. Which is to say, is unrealistic for many programs.
  • tgv 5y ago
    You can use a library that also adds a trailing \O. I used it to interface C++.
  • pjmlp 5y ago
    Depends on much they value security, even std::string has an extra null for c_str() calls.
  • habibur 5y ago
    Send the pointer from the pair to 3rd party and not the pair itself. You lose the efficiency in 3rd party, but still retain your gain in your own code. Better than before.