Yes.

This function was not carefully specified, we just have to acknowledge that. it was a past mistake, but now it's here, and we need to support it in a stable way.

About that function, the only thing to do is to properly document what it actually does, and keep it that way. There is no reason to change the behaviour.


At one point, this badly specified function could be deprecated, before being removed in a later release.

It is easy to add deprecation warnings and recommendations not to use with alternative api indications.


Here is a proposal for a timeline

-now:

* document that crc16 is deprecated and will be removed. do not change its behaviour.

* add code and accurate documentation for any well specified crc16 function that is required, based on a common implementation or not, not important. it's just optimization at this point.

-later:

* remove the legacy crc16

* do the same for any other crc function like crc32 if available.


What does the community think about that ?


Sebastien


On 09/04/2025 14:05, Nathan Hartman 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
            
<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.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
            
<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.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

Reply via email to