I suggest to not use clock_t as the typedef name, because
in OpenBSD that is already defined in sys/types.h
What would you suggest as an alternative?
What would be the impact of changing it?
To solve the problem I search and replaced clock_t to _clock_t.
And then when I submitted it I search and replaced it back.
The impact is that on OpenBSD, and probably the other BSDs
as well, is that it’s a compile error to have use the same name
as something already defined in sys/types.h.
- I just used the underscore version as a convention when I
quickly want a variable name that’s related but different to
another variable. When I program C, I usually don’t typedef
structs, but i realize that’s a minority opinion.
Would your underscore convention be clear enough to other students? On Pyret and Racket, we sometimes add “my” to the front of functions to avoid shadowing a built-in. my_clock_t or custom_clock_t might be more understandable. It would be helpful for students if we surface why we did this in an instructions append. After all, a good bit of programming is working around a language’s limitations, and different platforms having different types defined seems relevant.
When I added this exercise to x86-64, we had the same problem because the test file uses C. If I remember correctly, we renamed the struct from clock_t to clock_time_t.
That clock_time_t sounds good, like it’s clear.
It looks better than my_ or custom_ i think.
Alright, since we have a proposed change (clock_t to clock_time_t) and a rationale (compile errors on BSD platforms), let’s loop in the C track maintainers to continue this discussion. This would likely break the existing 1,259 submitted solutions for this exercise. We broadly speaking want to avoid that if possible, but that’s not always avoidable and sometimes a breaking change is worth it. If the maintainers explicitly approve the proposed changes, they can work with you on updating the Clock exercise implementation.
I’m okay with this change