ctl breaks <complex.h> and uses reserved identifiers (longer internal names are required)

[camel-cdr]

If you use <complex.h> before you include a file from ctl you'll get name collisions for the I macro.
I generally recommend using longer names or a prefix like CTL_I, CLT_A...
This also applies to clt.h, since names like CAT are often used by other code.
You should also consider using different include guards, since e.g. __CTL_H__ is a reserved identifier, because it begins with two underscores.

[glouw]

lol fixed

[HalosGhost]

@glouw, would you be interested in a PR to namespace internal functions/macros (and fix the use of reserved identifiers)?

[glouw]

@HalosGhost Yes, please. I've had many such requests to fix the global namespacing but considering we have a core group of industry users in the wild it's imperative we don't break the defines in ctl.h, or the usage of #define P or #define T. Anything internal like HOLD or __STR_H__, or the defines for A, B, C, D, or Z (for iterators) can be prefixed with CTL_.

I think that will remove most of the clutter. The fix for @camel-cdr's request was to rename #define I to #define Z, which while being the wrong fix, was the right fix given my time constraints :P

[HalosGhost]

That makes a lot of sense. I have a few things going on right now, so no promises on timeline, but I'll take a crack at it when I have a moment!

[HalosGhost]

@glouw, random question here. One of the reserved-identifier checks I always make is use of _t (reserved by POSIX, despite it being in wide-spread use). The code base only has one reserved use of _t, but the way it's used makes it clear where it comes from. The default aliasing the code does puts whatever P is at the end of the typedef (e.g., vec_size_t). So, technically, use of the CTL with any type that ends in _t (even if that wouldn't be a reserved use) results in a reserved use.

Practically speaking, this is very unlikely to ever be a problem for anyone, but I wanted to ask if you think it makes sense for me to consider potential solutions. Let me know; either way, there are other things for me to look at first. ☺

[glouw]

You could typedef size_t to size and go from there. It really depends on the use case. It's not something I plan on including as posix is out of my scope. One could just say that vec_size_t is an extension of posix itself, if they were to be so bold.

[HalosGhost]

That makes a lot of sense. On further thought, CTL already supports defining the resulting type name anyway, so that's more of a “if you were worried about that level of posix compliance, you should use the mechanism already built-in to support it” case than anything else. ☺