Replace string comparison functions

[MCUdude]

This PR replaces the strcmp/strncmp/strcasecmp/strncmp string comparison functions with Avrdude's own str_eq/str_starts/str_caseeq etc.

I've so far only modified jtag3.c, stk500v2.c, jtagmkii.c and jtagmki.c, but I can go through the entire code base if that's OK. When grepping for strcmp or strncmp, I realize there aren't that many occurrences left in the codebase.

I've also slightly simplified the way jtag3/jtagmkii/jtagmki/stk500v2 deals with the various fuses.

[stefanrueger]

Thanks for the PR, @MCUdude. I have been meaning to replace most memory string comparisons with testing bits in a new mem_type descriptor, see #1330 (comment) So, as an advance warning, some of the work that this PR does might be undone at some point if I get round to deal with #1330

[MCUdude]

That's totally fine @stefanrueger! Several other string comparisons are still done "the old way" that could be replaced. If you think you'll accept the PR once I'm finished, I can continue replacing the rest of the string comparisons in the other files as well, and deal with irregular formatting if I come across it.

[stefanrueger]

Thanks @MCUdude. Yes, the PR looks fine. I might have chosen a less permissive variant instead of `str_contains(m->desc, "fuse")` sth along the lines of ``` strlen(m->desc) <= 5 && (str_ends(m->desc, "fuse") || str_begins(m->desc, "fuse")) ``` that entertains the likes of "fuse", "fuse0" and "lfuse" but it's also OK as is. Unlikely Micochip will invent a memory `pwroffuse` or similar that contains "fuse" but isn't one.

[MCUdude]

I might have chosen a less permissive variant instead of str_contains(m->desc, "fuse") sth along the lines of

Good idea! I ended up using the following code instead, that's a little more compact but still does the same thing:

else if (str_contains(mem->desc, "fuse") && strlen(mem->desc) <= 5) 

I've updated the PR and replaced (almost) all strcmp/strncmp/strstr function calls. There are still a few left that I didn't dare to touch in case I screwed up something.

[stefanrueger]

a little more compact but still does the same thing

Well spotted!

Best to leave avrintel.c alone: it's written by a program that creates the relevant tables from .atdf files and other sources of knowledge incl errata.

[stefanrueger]

There are still a few [strcmp] left

Yes, some are actually needed to facilitate sorting, ie, provide an int that can be negative, postitive or zero.

[MCUdude]

Best to leave avrintel.c alone: it's written by a program that creates the relevant tables from .atdf files and other sources of knowledge incl errata.

Yes, I realized that shortly after pushing the commit. Fixed!
BTW, would it be a good idea to upload the mkavrintel.pl script into the tools folder in this repo? Using that script is the only sensible way to update the avrintel.c/h files.

Yes, some are actually needed to facilitate sorting, ie, provide an int that can be negative, postitive or zero.

I've tried to be as careful as I can and left strcmp/strncmp where ever non-boolean value (or a returned pointer) is needed.

[stefanrueger]

upload the mkavrintel.pl script into the tools folder

It's a complex, grown, haphazard project on its own with a lot of source files (incl avrlib, .atdf files) hand-curated errata lists in, ahem, perl that famously is one of the few languages that is easier to write than to read. mkavrintel.c relies on the output of other meta-programmes. The world is a better place with this program hidden away. It's better for my streed-cred as a programmer, too. ;)