4 ms·

I haven't looked that deeply, but I don't see many sins in this source code, either, except for the K&R style, weird formatting and doing too much in one line,

I haven't looked that deeply, but I don't see many sins in this source code, either, except for the K&R style, weird formatting and doing too much in one line, like this line in the file CAT.C: if(*(Ptr = argv[i]) == '-') { Older C compilers did let you get away with more, like using integers as pointers, and dereferencing pointers as though they were struct pointers when they aren't. But I don't see that in this code.

fuzztester 3y ago
>Older C compilers did let you get away with more, like using integers as pointers In older C compilers (maybe pre-ANSI, or later, can't remember), you could literally write i[a] instead of a[i], where a was an array and i was an int, and it would work equivalently, i.e. no compiler error, and give the same result as a[i]. This was because a was the address of the start of the array, and i was an offset, so a[i] actually meant *(a + i), which, by the commutative property of arithmetic, was equivalent to *(i + a), which was equivalent to i[a]. I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible. Never forgot it, because it was counter-intuitive, unless you knew the above reason. And tried it out in one or more C compilers at that approximate period, and it worked as stated.
- krackers 3y ago
  This still works iirc.
- trealira 3y ago
  This is still true, and it's mandated by the ISO C standard that a[i] is equivalent to (*((a)+(i))) (yes, they specify it with that many parentheses). You're still able to compile code that treats a[i] and i[a] interchangeably. https://godbolt.org/z/37Kv44o1b https://godbolt.org/z/37Kv44o1b > I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible. I haven't read the Microsoft C Bible, but it does say this in K&R while explaining pointers.
  - fuzztester 3y ago
    >This is still true, and it's mandated by the ISO C standard ... Wow, good to know. >but it does say this in K&R Then that must be where I had read it.
duskwuff 3y ago
The "sin" I was referring to was calling undeclared functions -- which is how there are so few #include directives in much of this code. Most of the files I looked at include <stdio.h> (probably required for variadic arguments on printf-type functions) and <file.h> (for the FILE type), and call other functions blindly.
- trealira 3y ago
  That does make sense. My bad, I should have looked closer and noticed the implicitly defined functions. It's not even a good idea to do that on modern computers, because implicitly declared functions do type promotions from float to double and char/short to int, and on the System V ABI, it has to pass in the number of floating point arguments there are in register eax.
  - jart 3y ago
    It's not a good idea to do that in production code. FTFY. If you're writing research, experimental, or one-off programs then it can be a real productivity boon. I say do it for fun. You have a right to enjoy yourself and it'll still come out 10x more readable than Perl at the end of the day, let's be real.
    - rezonant 3y ago
      > it'll still come out 10x more readable than Perl at the end of the day, let's be real. A low bar, really :-P
- queuebert 3y ago
  Wait til you see old Fortran codes.
deleted 3y ago
[deleted]

fuzztester 3y ago

>Older C compilers did let you get away with more, like using integers as pointers In older C compilers (maybe pre-ANSI, or later, can't remember), you could literally write i[a] instead of a[i], where a was an array and i was an int, and it would work equivalently, i.e. no compiler error, and give the same result as a[i]. This was because a was the address of the start of the array, and i was an offset, so a[i] actually meant *(a + i), which, by the commutative property of arithmetic, was equivalent to *(i + a), which was equivalent to i[a]. I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible. Never forgot it, because it was counter-intuitive, unless you knew the above reason. And tried it out in one or more C compilers at that approximate period, and it worked as stated.

krackers 3y ago
This still works iirc.
trealira 3y ago
This is still true, and it's mandated by the ISO C standard that a[i] is equivalent to (*((a)+(i))) (yes, they specify it with that many parentheses). You're still able to compile code that treats a[i] and i[a] interchangeably. https://godbolt.org/z/37Kv44o1b https://godbolt.org/z/37Kv44o1b > I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible. I haven't read the Microsoft C Bible, but it does say this in K&R while explaining pointers.
- fuzztester 3y ago
  >This is still true, and it's mandated by the ISO C standard ... Wow, good to know. >but it does say this in K&R Then that must be where I had read it.

duskwuff 3y ago

The "sin" I was referring to was calling undeclared functions -- which is how there are so few #include directives in much of this code. Most of the files I looked at include <stdio.h> (probably required for variadic arguments on printf-type functions) and <file.h> (for the FILE type), and call other functions blindly.

trealira 3y ago
That does make sense. My bad, I should have looked closer and noticed the implicitly defined functions. It's not even a good idea to do that on modern computers, because implicitly declared functions do type promotions from float to double and char/short to int, and on the System V ABI, it has to pass in the number of floating point arguments there are in register eax.
- jart 3y ago
  It's not a good idea to do that in production code. FTFY. If you're writing research, experimental, or one-off programs then it can be a real productivity boon. I say do it for fun. You have a right to enjoy yourself and it'll still come out 10x more readable than Perl at the end of the day, let's be real.
  - rezonant 3y ago
    > it'll still come out 10x more readable than Perl at the end of the day, let's be real. A low bar, really :-P
queuebert 3y ago
Wait til you see old Fortran codes.

deleted 3y ago

[deleted]