Interesting that you did this as part of a course! It makes a lot of sense, as I agree shell has a lot of conditionals to handle. I would say that the segfaults are an instance of the "else-idgaf anti-pattern" where the corner cases are undefined/broken. This seems to happen a lot in bash.
I use regular languages a lot in the Oil shell precisely because it forces every state and transition to be defined:
It looks like "else-idgaf" is meant to describe not considering all cases. What do you think about pushing input validation to the caller; you write code that explicitly considers some subset of all possible inputs and thoroughly document that subset -- behavior for other inputs is not guaranteed.
I think if you have an assert() for the invalid input, that makes sense. I don't think documentation is enough in practice.
In my experience, you can write "don't call this with 0" in the comments, or you can write it in the documentation -- it doesn't matter. Someone will call it in an unexpected way. They will make it work for the happy path and not consider the other cases, because that takes time. (And that includes myself in many instances.)
So the only way to be sure is to blow up and make it a hard bug.
----
I'll also note that very few functions are public APIs with documentation. I'm thinking about the bash codebase, which has 140K lines of C written over 30 years. There are a lot of informal internal APIs, and few documented APIs.
They are kinda stable but also subject to change. So I think assert() is the best way of "documenting" the expected invariants in these cases, which comprise the vast majority of coding situations.
I use regular languages a lot in the Oil shell precisely because it forces every state and transition to be defined:
https://lobste.rs/s/jyyuhn/decision_table_patterns#c_o49q52
Related: How to Parse Shell Like a Programming Language http://www.oilshell.org/blog/2019/02/07.html
also related: https://lobste.rs/s/jyyuhn/decision_table_patterns#c_yukvlr