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