On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote: > You talk to the wrong person given that other people added that > mechanism and put it into practical use.
Yeah unfortunately, as Kevin admitted, this feature was never discussed here when it was implemented, so those who care about any of that are having the conversation now. But that doesn't matter... I was specifically responding to YOUR point, which was a logical fallacy. You seemed to be making a point that implied that if you aren't aware of clients that are negatively impacted, then it doesn't matter. That's bad logic. There's a difference between bugs caused by the implementer of the receiver failing to correctly implement what is normal and expected, and bugs caused by the implementer of the sender intentionally implementing behavior that is outside what is normal and expected. The former affects only the user of that software. The latter affects everyone else but the user of that software (at least potentially). Responsible developers should strive to avoid both, but the latter clearly has a more serious impact on more people, and exactly the wrong people. It is the whole reason the robustness principle exists. Outlook is famous for this sort of thing, and it's one of the reasons people hate Microsoft/Outlook. > (And regarding this -- i think this works out fine. Except for > dumb clients like mine which do not get the thing and do not map > those headers into the place of the main ones. Yet.) You have no proof that this is true, among the hundreds if not thousands of e-mail clients that exist. That is the nature of undefined behavior. There's nothing special about that term in the context of ISO C or otherwise. And since there isn't any sort of official standard, it's probably rather unlikely that the majority of clients will ever addopt this. You can't call them dumb for not implementing a standard that doesn't exist. > You can expect anything in it is what is said. Of course, MUAs > which do not understand maximally visualize those header lines in > addition to the main ones (what mine does), or totally ignore them > (what i expect graphical ones to do). That is not "undefined > behaviour". These are not the only possibilities, since again, the behavior is undefined. Headers could be incorrectly repeated (which could lead to additional bugs, since that also is outside the spec), the "wrong" version of the header could be the one the client uses. Or the structure you're using to hold the headers could overflow, causing memory corruption and/or crashes. Etc.. Those things might be unlikely or impossible to happen in the absence of the undefined behavior. It's hard to be robust against problems you didn't forsee, on account of them being well outside the norm. Undefined behavior is... undefined. When the input data deviates from what is expected, any variety of resulting bugs is LIKELY. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
