gh-129173: Use _PyUnicodeError_GetParams in PyCodec_NameReplaceErrors

[picnixz]

I extracted the logic of rendering hexadecimal digits but this requires a double pointer (alternatively, I could make the function return the number of characters that were written and advance the pointer after the call).

If inlined calls are preferred, then we can convert the function into a macro to avoid duplications but I think a function call is not that slow (especially if I add the inline qualifier to force a bit the compiler to inline it and then allow it to possibly vectorize it if it's smart). Ideally, I would like to extract that logic from PyCodec_XMLCharRefReplaceErrors as well but it's the only place where we use the decimal base instead. OTOH, if we extract the logic, it's a bit cleaner to read.

After the refactoring of surrogate handlers has been done, I will wrap up this list of PRs by cleaning up the handlers that I fixed previously (I just didn't want to do both cleanup and fixes in the same PR). The idea is to extract the handling of each unicode error type into a separate function (unless the handler only handles a single exception type as it's the case for the namereplace handler).

• Issue: Refactor codecs error handlers to use _PyUnicodeError_GetParams and extract complex logic into separate functions #129173

[picnixz]

Since I will be leaving for two weeks and won't be able to commit or review anything (except on mobile), I kept it as a draft and we'll discuss about it later. What remains do to on the codecs part is mainly refactoring so it's just a feature.

[encukou]

If inlined calls are preferred, then we can convert the function into a macro to avoid duplications but I think a function call is not that slow (especially if I add the inline qualifier to force a bit the compiler to inline it and then allow it to possibly vectorize it if it's smart).

static inline functions are definitely preferred to macros :)

[picnixz]

In this case, it's just that I need to pass a double pointer, which made it a bit more ugly, but I think it's better like that rather than keeping everything in the loop (it's much more harder to actually see what's happening and I doubt this will really slow down the handler by much).

[encukou]

Well, I wouldn't want to see *(*p)++ on a whiteboard at an interview, but in existing code its purpose should be rather clear to readers :)