3 ms·

> Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Wh

by pxc 4y ago

> Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Why not? Alternatively, who said the decision was 'conscious'? It doesn't take a dumb person to make a dumb mistake. Brilliant people get things wrong all the time, and anyone can be hasty or careless in a moment.

kazinator 4y ago
I believe I cover all your remarks with the discussion about distracted coding. If it was a coding mistake, it would have to have been something like that. It's not a coding mistake where some wrong identifier was used or other typo; coding the proper test requires more instructions. You have to check that there is either a 0 byte after the first '.', or else another '.' byte that is followed by a 0. Here is how someone could be distracted halfway through and forget to finish it. Suppose the code has a structure like this: for (;;) { if (getnext(name) < 0) break; /* code added to skip . and .. */ if (name[0] != '.') /* if it doesn't start with a dot, print it */ goto print; /* This can be continued here with more logic without changing the above line; But it would already skip . and .. with just the above line. */ if (name[1]) { /* two or more chars */ if (name[1] != '.') /* Dot followed by non-dot: print it */ goto print; if (name[2] != 0) /* Two dots, followed by non-dot: print it */ goto print; /* confirmed dot-dot */ } /* confirmed dot or dot-dot */ continue; print: puts(name); } And the code does have this structure: it tests for the . character, and branches forward if not equal. Whenever that bne branch is taken, the situation is correct. cmpb (r3),$'. bne 2f sub $8.,r1 br 1b 2: jsr r5,gstat br 1b So this could be corrected with further refinements by adding more instructions after the bne where the branch is not taken, without changing the prior instructions. If the behavior was indeed not intended, this would be a case of incomplete code. Incomplete code can happen by distraction. You turn your attention to something else, perhaps for the span of several days, and then don't remember the incomplete state. The brain had visualized the complete state, leaving a false memory of that having been done. On a related note, one element that is gapingly absent from all historic Unix sources is ... test cases! Compiler test cases, shell test cases, utility test cases, library function (and system call) test cases ... They are nowhere to be seen.

by pxc 4y ago

kazinator 4y ago

I believe I cover all your remarks with the discussion about distracted coding. If it was a coding mistake, it would have to have been something like that. It's not a coding mistake where some wrong identifier was used or other typo; coding the proper test requires more instructions. You have to check that there is either a 0 byte after the first '.', or else another '.' byte that is followed by a 0. Here is how someone could be distracted halfway through and forget to finish it. Suppose the code has a structure like this: for (;;) { if (getnext(name) < 0) break; /* code added to skip . and .. */ if (name[0] != '.') /* if it doesn't start with a dot, print it */ goto print; /* This can be continued here with more logic without changing the above line; But it would already skip . and .. with just the above line. */ if (name[1]) { /* two or more chars */ if (name[1] != '.') /* Dot followed by non-dot: print it */ goto print; if (name[2] != 0) /* Two dots, followed by non-dot: print it */ goto print; /* confirmed dot-dot */ } /* confirmed dot or dot-dot */ continue; print: puts(name); } And the code does have this structure: it tests for the . character, and branches forward if not equal. Whenever that bne branch is taken, the situation is correct. cmpb (r3),$'. bne 2f sub $8.,r1 br 1b 2: jsr r5,gstat br 1b So this could be corrected with further refinements by adding more instructions after the bne where the branch is not taken, without changing the prior instructions. If the behavior was indeed not intended, this would be a case of incomplete code. Incomplete code can happen by distraction. You turn your attention to something else, perhaps for the span of several days, and then don't remember the incomplete state. The brain had visualized the complete state, leaving a false memory of that having been done. On a related note, one element that is gapingly absent from all historic Unix sources is ... test cases! Compiler test cases, shell test cases, utility test cases, library function (and system call) test cases ... They are nowhere to be seen.