5 ms·

Soooo, those C compilers cheat on the language as defined in K&R etc.!!! WOW!! With that cheating, C gets to catch up with, say, what PL/I was doing with stri

Soooo, those C compilers cheat on the language as defined in K&R etc.!!! WOW!! With that cheating, C gets to catch up with, say, what PL/I was doing with string manipulations in, say, 1969!!! So, this is the 50th anniversary!! C string handling is right up to date as of 50 years ago!!! There is still the issue of a C programmer having to calculate array indices that Fortran and PL/I can do back, way back there, 50+ years ago!!!! What was it, Fortran 66 or some such???

monocasa 7y ago
It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well. Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.
- graycat 7y ago
  > It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. As I read K&R, strcpy, etc., where there, in a library of external functions, as a convenience and optional for the user, and NOT part of the definition of the C language. Your YMMV. The situation definitely is "cheating": In K&R, strcpy is clearly, syntax, semantics, original implementation, an external library function. K&R has the definition of the language. One of the most important parts of C is that it doesn't change. It was clear in K&R that strcpy could be implemented by any user in their own external code. So, a compiler that implements strcpy with its own in-line, not with external names, code is cheating on the language definition. C as in K&R was designed to run in a DEC computer with 8 KB of main memory. So, the K&R definition of C was primitive. Since strings in C as in K&R are so primitive, really a disaster, a situation well understood when K&R was written, some programmers might have done a much better string implementation via external function calls. So, given some old C code, they could have linked in their own external calls not mentioned in K&R and for parts of the old code that called strcpy linked in their own version of that function that worked with the new string functionality. All to have been expected. So, some compiler writers have gotten more performance from C by cheating some on the language and put in compiler options to justify the cheating. With this cheating, the compiler writers are making my main point: Functionality defined in the language and implemented in the compiler via in-line code can be faster than functionality implemented in external function calls. That is, the more recent C compiler writers so strongly agreed with this point that they cheated on the language definition to get the gains. This point was made very clearly by IBM as they pointed out that the string functionality in the PL/I language and the IBM compilers was faster than the many Fortran string packages implemented by external functions. Being faster than K&R style C is easy. So, here I was struck by the point that Rust is not always a LOT faster than C, that is, K&R C. But, maybe Rust IS a lot faster than C with a compiler that does no cheating!
  - leni536 7y ago
    The currently used C standards have no direct relationship with K&R and they define both the language and the standard library functions.
    - graycat 7y ago
      Then they changed the language. C was not supposed to change.
      - monocasa 7y ago
        Who said that C wasn't supposed to change at all from it's roots? Certainly not Kernighan or Ritchie, as they were some of the leads on ANSI C.
      - rswail 7y ago
        Who said? K&R is pre ANSI C, so pre any standardization. The concept of the C standard library post-dates ANSI C, so to say that they "changed" the language in that they more closely documented the behavior of the language and the standard library means that, for all intents and purposes, the standard library is part of the language. Which is exactly the point you are making about FORTRAN and PL/1. That they have standardized functions that perform in a documented manner and so can therefore be optimized by the compiler. That C compilers understand the defined behavior of strcpy et al means that they are allowed to optimize the implementation.

monocasa 7y ago

It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well. Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.

graycat 7y ago
> It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. As I read K&R, strcpy, etc., where there, in a library of external functions, as a convenience and optional for the user, and NOT part of the definition of the C language. Your YMMV. The situation definitely is "cheating": In K&R, strcpy is clearly, syntax, semantics, original implementation, an external library function. K&R has the definition of the language. One of the most important parts of C is that it doesn't change. It was clear in K&R that strcpy could be implemented by any user in their own external code. So, a compiler that implements strcpy with its own in-line, not with external names, code is cheating on the language definition. C as in K&R was designed to run in a DEC computer with 8 KB of main memory. So, the K&R definition of C was primitive. Since strings in C as in K&R are so primitive, really a disaster, a situation well understood when K&R was written, some programmers might have done a much better string implementation via external function calls. So, given some old C code, they could have linked in their own external calls not mentioned in K&R and for parts of the old code that called strcpy linked in their own version of that function that worked with the new string functionality. All to have been expected. So, some compiler writers have gotten more performance from C by cheating some on the language and put in compiler options to justify the cheating. With this cheating, the compiler writers are making my main point: Functionality defined in the language and implemented in the compiler via in-line code can be faster than functionality implemented in external function calls. That is, the more recent C compiler writers so strongly agreed with this point that they cheated on the language definition to get the gains. This point was made very clearly by IBM as they pointed out that the string functionality in the PL/I language and the IBM compilers was faster than the many Fortran string packages implemented by external functions. Being faster than K&R style C is easy. So, here I was struck by the point that Rust is not always a LOT faster than C, that is, K&R C. But, maybe Rust IS a lot faster than C with a compiler that does no cheating!
- leni536 7y ago
  The currently used C standards have no direct relationship with K&R and they define both the language and the standard library functions.
  - graycat 7y ago
    Then they changed the language. C was not supposed to change.
    - monocasa 7y ago
      Who said that C wasn't supposed to change at all from it's roots? Certainly not Kernighan or Ritchie, as they were some of the leads on ANSI C.
    - rswail 7y ago
      Who said? K&R is pre ANSI C, so pre any standardization. The concept of the C standard library post-dates ANSI C, so to say that they "changed" the language in that they more closely documented the behavior of the language and the standard library means that, for all intents and purposes, the standard library is part of the language. Which is exactly the point you are making about FORTRAN and PL/1. That they have standardized functions that perform in a documented manner and so can therefore be optimized by the compiler. That C compilers understand the defined behavior of strcpy et al means that they are allowed to optimize the implementation.