Agree! This will end this discussion! And it will make it clear what algorithm was used.
BR, Alan On Wed, Apr 9, 2025 at 9:07 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > I think the real problem here is that the function is called crc16() with > no details about which CRC polynomial is used. Maybe it's better not to > have this function at all and to have *only* functions with names like > crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being > called in other code and there will be no risk of breaking compatibility in > the future. > > On Wed, Apr 9, 2025 at 5:44 AM chao an <magicd...@gmail.com> wrote: > >> Seriously, I have no interest in crc16 at all, and I don't think your 15 >> years of experience in cryptography deserves my respect. >> These are all old technologies. I just want to help people who have >> problems in Nuttx. >> I also hope that every time someone asks about the implementation of >> crc16, you can reply to them as soon as possible instead of hiding behind >> emails. >> >> I won't reply to any messages from you anymore, I wish you all the best, >> thanks. >> >> BRs, >> >> Sebastien Lorquet <sebast...@lorquet.fr> 于2025年4月9日周三 17:17写道： >> >>> Why are you so unwilling to change your opinion? >>> >>> You are ready to break nuttx just for your comfort, in whatever way it >>> may take to advance your own agenda. That is very political. >>> >>> I dont like that. >>> >>> We need a consensus, and a majority of this thread is against the change >>> you want to make. So it should be cancelled. >>> >>> Rememeber this thread is a vote. My vote is No. Close the pull request. >>> Do another one that has chances to be consensually accepted. Let's vote >>> again. >>> >>> >>> I will paste the quote that Greg posted in the thread about the modlib >>> change: >>> >>> >>> Rules for voting are a little different for code changes. >>> >>> The required Apache voting process is here: >>> https://www.apache.org/foundation/voting.html >>> >>> For code changes, that document says: "Votes on code modifications follow >>> consensus >>> approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> >>> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In >>> this scenario, a negative vote constitutes a >>> veto<https://www.apache.org/foundation/voting.html#Veto> >>> <https://www.apache.org/foundation/voting.html#Veto>, which the voting >>> group (generally the PMC of a project) cannot override. Again, this model >>> may be modified by a lazy >>> consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> >>> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration >>> when the request for a vote is raised, but the full-stop nature of a >>> negative vote does not change. Under normal (non-lazy consensus) >>> conditions, the proposal requires three +1 votes and no -1 votes in order >>> to pass; if it fails to garner the requisite amount of support, it doesn't. >>> Then the proposer either withdraws the proposal or modifies the code and >>> resubmits it, or the proposal simply languishes as an open issue until >>> someone gets around to removing it." >>> And "For code-modification votes, +1 votes are in favour of the proposal, >>> but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> >>> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal >>> dead until all vetoers withdraw their -1 votes. >>> Unless the proposer declares that the vote is using lazy >>> consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> >>> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 >>> votes are required for a code-modification proposal to pass." >>> >>> >>> >>> >>> Sebastien >>> >>> >>> On 09/04/2025 10:20, chao an wrote: >>> >>> 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 >>>>> >>>>
