There was no diatribe this time. I had the same single argument the
whole time: for long term self compatibility, we can not change the
behaviour of existing critical code. That's what matter.
We just added the complete deletion idea later.
The addition of new, well specified CRC routines is very valuable. But
it does not distract me from the modification of the existing routine.
I will never stop fighting for innocent users that don't post on this ml
and will get silently broken code behind their back. That is a priority
over contributor satisfaction to see PRs merged.
This is definitely a political (or policy) reason. Another name for this
is "project management".
We cant just throw any code we like in a large shared project. We're not
just coding for ourselves at this point.
Sebastien
On 09/04/2025 17:58, Lwazi Dube wrote:
Too late. If I am reading the PR correctly, he has changed the subject and
we are back to the original default.
uint16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16xmodempart(src, len, 0);
}
He fought for a couple of days before giving up. I don't blame him. This
suggestion, which is good, should have come at the beginning. The preceding
diatribe didn't help.
On Wed, 9 Apr 2025 at 10:15, Alan C. Assis <acas...@gmail.com> wrote:
Agree! This will end this discussion! And it will make it clear what
algorithm was used.
BR,
Alan
