Integrate certain fixes for issues found in `c-string` into `c-vector`.

[german-one]

These are some issues that I already resolved in the c-string lib. I'd like to contribute the solutions to the c-vector lib, too. Tracking them in only one report should be good enough.

Warnings

One of the disadvantages of a macro lib is that macros are expanded into the user code and, thus, suppressing certain warnings in the header file is not effective. We cannot control what warnings the users enabled. In the consequence they might find themself lost in too many warnings caused by our lib, not being able to find the warnings caused by their code anymore. Since we certainly don't want to force users to disble warnings that might be useful from their point of view, we should do our best to avoid making too many noises.

• -Wshadow
  • Currently, variables declared in the macros have duplicate names within the lib. This causes cv_sz__ being shadowed in cvector_grow whenever cvector_resize is called. There is a certain risk that also other variables are shadowed if users nest macro calls.
  • Possible solution: Having unique names for all variables declared across all macros of the lib both solves the issue faced and protects us from potential issues of that kind. PR avoid variable shadowing #83
• -Wcast-align
  • cvector_vec_to_base performs a type cast from a pointer to element type to a pointer to cvector_metadata_t. Depending on the size of the element type, compilers may throw a warning that casting would change the data alignment.
  • Possible solution: Insert a preliminary cast to void * to emphasize our intention and appease the compiler. PR avoid cast-align warnings #86

Potential memory leaks

• Overridden functions
  • Allocation, reallocation, and deallocation functions need to be harmonized whenever they get overridden. They must not belong to different libraries.
  • Possible solution: At least ensure that either all or none of the used memory management functions are overridden. PR ensure harmonized memory management functions #87

[german-one]

@eteran If you'd rather I keep #83 lean by only addressing the cv_sz__ finding, just give me a hint.

[eteran]

Well, what Ive been considering, is how ugly we should be willing to make our internal identifiers 🤣.

Maybe we prefix them all with something like cv_reserve_cap__ so they are unique per macro but still have somewhat readable names?

[eteran]

I am just not loving the "add more underscores" solution, LOL.

[german-one]

Got it. It's not a big deal to update the names again, just a Ctrl+H thing in the editor. I'm going to do that later today.

[eteran]

Ok, I think we got good coverage of the improvements you had in mind.

Thanks! I think we can close this issue now 👍

[german-one]

Just to add ...

I would've been in favour of as many underscores as needed. They just emphasize that the names belong to an implementation detail. Besides of that, you don't actually read them.

if (candy_____ < 0) {
    a = 3210;
    x = y + dandy_____ - 123;
}

In contrast, we are used to reading from left to right. IMO, the prefix makes it more difficult to distinguish names.

if (some_pretty_long_prefix_dandy__ < 0) {
    a = 3210;
    x = y + some_pretty_long_prefix_candy__ - 123;
}

spoiler

At first glance, did you recognize that the variable names were reversed in the 2nd example? (No encouragement to respond.)

However, my personal preference is definitely not representative. I just tried to tell where I originally came from 😅