I like your second option, so could we remove the implementation of both crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
BRs, Sebastien Lorquet <sebast...@lorquet.fr> 于2025年4月9日周三 16:00写道： > Hello, > > once again, the number of usage is unimportant and irrelevant. > > The ONLY thing that matters is that when I call function POOP, it always > does POOP. Not something else. > > Because users you are unaware of expect this function to do POOP and they > may not be able to change their code. > > If you want different crc functions, use something else. > > > A better example than the building: the zip format > > zip uses adler32 which is not even a proper crc and is largely suboptimal. > > zip developers NEVER changed this in decades, even if they know it's bad. > Why? because otherwise, old zip files would become completely unusable. > > We have the same issue. > > The default crc is bad? OK, deal with it. Add better functions. Document > everywhere that the default crc is deprecated and should not be used > because more accurate functions are available. > > But dont change the damn thing. > > I am against changing the default implementation of the legacy function > silently. > > I would be less mad if you REMOVED the old function rather than silently > changing its behaviour. (that would still be bad, however) > > Sebastien > > > On 09/04/2025 05:12, chao an wrote: > > I can empathize. But we just don't want to fill this regret again in the > new building. > The lack of standards is currently the biggest issue hindering the > promotion of this proposal. > Another interesting thing, I'd like to share another data from github: > if we search for the lookup table of crc16 on GitHub, you'll find that > CRC-16/IBM with a higher use rate: > > CRC-16/IBM: 3.1k > > https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code > [image: image.png] > > CRC-16/XMODEM: 304 > > https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code > > [image: image.png] > > BRs, > > Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道： > >> On Wed, Apr 9, 2025 at 3:45 AM chao an <magicd...@gmail.com> wrote: >> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lwa...@gmail.com> >> wrote: >> > > > > An open source project's ability to innovate should not be >> > > > > held up by your preferences. >> > > > >> > > > The last sentence is completely wrong. Its not about "preference" >> but >> > > > impacting self-compatibility and long term maintenance. Messing the >> > > > foundations and defaults is not innovation. Try building a home when >> > > > the project constantly changes during the process, when you have 10 >> > > > floors ready and suddenly you need to change pavements. Innovation >> is >> > > > when you create new functionality and give users a choice without >> > > > breaking existing working stuff. >> > >> > So you think it's more important to maintain your current 10 floors >> > building, and it's none of your business if a 100 floors skyscraper >> appears >> > in the future? so could you afford all the developer time spent on this >> > kind of problem? >> >> Anchao, what I meant was to finish 10 floor building as planned >> (development), let people live inside that building (maintenance), and >> move development resources to 100 floor building as planned, without >> changing plans in the middle of construction, not getting stuck on 10 >> floor building construction because plans change all the time and >> never getting to that 100 floor building. Its good to have solid >> immutable tools that you can depend on. Imagine there are devices >> already deployed out there that may not be possible to update, yes >> maintenance (in terms of keeping them inter-operational) may be the >> priority in that case, because replacing all devices may wipe out the >> company and leave owner with ubearable financial debt. >> >> I know this CRC is an important and quite hard problem, and I hope >> there can be a win-win solution where users have choice when they need >> one, thank you for bringing this up to the attention.. to be honest I >> have no clue what is the best solution here if there is no standard to >> relay on :-) >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> >
