On Thu Nov 3 18:25:18 2022 +0000, Francisco Casas wrote:
Well, my memory of why I did this is fuzzy. I remember that I spent a lot of time adding `const` modifiers until I settled into this. I think that the problem went along these lines: In C, a double pointer `type **` cannot be casted implicitly to `const type **` without a warning. e.g.:
int main() { int a = 2; int *p = &a; int **pp = &p; const int **cpp = pp; }(there is an interesting SO thread here: https://stackoverflow.com/questions/5055655/double-pointer-const-correctness...) So, adding the const as the argument of `hlsl_type_get_component_type()` was more of a requirement to avoid this. I could have settled on doing:
struct hlsl_type *hlsl_type_get_component_type(struct hlsl_ctx *ctx, struct hlsl_type *type, unsigned int index) { cont struct hlsl_type *ctype = type; while (!type_is_single_component(type)) traverse_path_from_component_index(ctx, &ctype, &index); return (struct hlsl_type *) ctype; }but adding the `const` in the signature of `hlsl_type_get_component_type()` makes it a little more correct. OTOH if I went full `const`, and I were to add `const` to the return type of `hlsl_type_get_component_type()` (which in principle seems to be the correct thing to do), then I would have to add it to the `struct hlsl_type *` variables in the callers:
[const] hlsl_type *type; type = hlsl_type_get_component_type(·);But these same variables are passed to other functions, and we have a lot of functions that receive `struct hlsl_type *` instead of `const struct hlsl_type *`, so we would have to change those signatures too, and probably in the `struct hlsl_type *` members in structs like `struct hlsl_ir_var` too. Now, I must confess that I don't recall what was the motivation for this specific patch, besides performing a little step towards const correctness. I don't remember if we discussed this many moons ago... I guess I could remove it from the series if it just adds noise.
Propagating const to more functions is probably desirable in general. The problem is that it may be a losing battle, given "bytecode_offset". I'm not sure that avoiding that would be an improvement, though...