Okay, interesting point. During a download of a .DO file, TELCOM intercepts an <EOF> and prohibits it from from getting written into the file system. Sounds like you would argue that this is wrong as well?
On Tue, Feb 12, 2019 at 10:35 PM Brian White <[email protected]> wrote: > You said just one any one example, which I already gave, but here's > another for free. > > I try to write a checksum calculator, and I spend a million hours trying > to get the assembly or forth working right, but no matter what, the numbers > just never ever come out... > > On Wed, Feb 13, 2019, 12:27 AM Brian White <[email protected] wrote: > >> That places the obligation on the wrong party. >> >> This is computers not inpressionist art. If I am trying to figure out why >> something is, or is not working, or document something by experiment, it's >> wrong to have a low level tool responsible for handling data do something, >> *especially* without notice or configurability, like modify the data as it >> passes from point A to point B. >> >> If I have a file, that has some garbage data in it that is actually >> invalid, but it works *anyway*, because one of the tools I just happened to >> use did some clean up for me, then I now think I know what the correct data >> is. I just "proved" it because it worked. Meanwhile, it's actually bad >> data, and doesn't work in any other context. It wouldn't work on a real >> disk, or on any other emulator or device that didn't happen to have the >> same *backwards* idea about being "helpful". But I, not knowing any better, >> tried something, it worked, I wrote it all up on a web site, provided a >> download archive of all bad files, and years later someone else spends all >> day banging their head against the wall and throwing away their "broken" >> vintage machine because it isn't working... (In case we are not all up to >> speed, this is a hypothetical. I am not saying I actually did this as was >> so mystified and produced a load of bad files. You asked for an example.) >> >> In the last 20 years as a sysadmin, programmer, all around IT analyst >> dealing with all kinds of boring back-end integration projects; that >> feature of the "venerable" ftp has only ever caused grief and cost time and >> money over and over again. >> >> The reasons it's wrong to modify your payload unless that is your actual >> explicitly declared purpose is to *process* it in some way, are open-ended >> and infinite. You can't know the possible reasons or situations which might >> ever come up with the countless possible users in their countless possible >> contexts in the open-ended future years. But you don't have to. All you >> have to know is that if you don't make any assumptions, then you don't have >> to worry about breaking them, or failing to think of everything. >> >> Any example will by definition be a contrived example, which is too >> tempting (for some) to disregard. Any contrived example just sounds like >> some unlikely thing that isn't important to worry about. whatever the >> example is, you just say "oh that's all? who would do that? just don't do >> that, that's all" >> >> It's user-hostile, even if intending to be the opposite. It's a misguided >> concept of being helpful. >> >> >> On Tue, Feb 12, 2019, 10:08 PM Gary Weber <[email protected] wrote: >> >>> Brian, describe ANY scenario at all, where cleansing trailing <EOF> >>> characters from transmitted .DO files into a Model T file system, is a >>> wrong idea. I'm genuinely interested. :) >>> >>> On Tue, Feb 12, 2019 at 7:28 PM Brian White <[email protected]> wrote: >>> >>>> I referenced ftp as the canonical *anti-example* in my first comment >>>> and then again later. >>>> >>>> It proves how wrong the idea is, not how right it is. >>>> >>>> On Tue, Feb 12, 2019, 6:53 PM Gary L Phillips <[email protected] wrote: >>>> >>>>> I'll just add one small note here. >>>>> >>>>> No less venerable a program than ftp, as implemented on dozens of >>>>> environments, makes changes to data being transferred. It does so by >>>>> default and without warning, to adjust text files from one system standard >>>>> to another. The obvious case here is automatic conversion of line endings >>>>> between CR (as used by many early microcomputer systems,) LF (as used by >>>>> most *NIX compatibles and Apple systems,) or CR/LF (as used by PCDOS and >>>>> MS-DOS.) >>>>> >>>>> And yes, this does sometimes cause corruption or confusion when binary >>>>> data is transferred, unless the user specifies that the data is binary and >>>>> to be left untouched. >>>>> >>>>> Gary Phillips 😉 >>>>> >>>> >>> >>> -- >>> Gary Weber >>> [email protected] >>> >> -- Gary Weber [email protected]
