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] >> >
