The problem in the present case is that the caller is not made aware of the limitation, so can’t be expected to prevent passing unsupported input, and has no way to handle the overflow case after the fact.

▲

skydhash 14 hours ago | parent [-]

Do you not review libraries you add to your project? A quick scan of the issues page if it's on a forge? Or just reading through the code if it's small enough (or select functions)?

Code is the ultimate specification. I don't trust the docs if the behavior is different from what it's saying (or more often fails to mention). And anything that deals with recursive structures (or looping without a clear counter and checks) is my one of the first candidate for checks.

> has no way to handle the overflow case after the fact.

Fork/Vendor the code and add your assertions.

	▲	layer8 14 hours ago \| parent \| next [-]
		Obviously I just did review it, and my conclusion was to not use that code. In the spirit of the article you linked, I’d rather write my own version.
	▲	jama211 13 hours ago \| parent \| prev \| next [-]
		If it has limitations they should be documented though right? especially if they’re security concerns.
	▲	knowitnone2 7 hours ago \| parent \| prev [-]
		If you review libraries, why do you need to quick scan the issues? You would have already identified all the issues right? Right?