[CJefferson]

On the other hand, why not have implementations assert if they are given a string longer than 72 chars? It feels to me like no-one would ever do that on purpose, so it's a massive issue which is easy to accidentally make with a really important function.

[Tostino]

Don't disagree there. I asked my self the same question the first few times I had to use it.

Silently truncating the data is about the worst way to deal with it from a security standpoint. No idea why that decision was made back in the day.

[zorgmonkey]

It is almost never I good idea to assert in a library, unless the error is truly unrecoverable. I think returning an error code\throwing an exception would be very reasonable and a much better API than failing silently though.

[thayne]

> almost never I good idea to assert in a library, unless the error is truly unrecoverable

Like getting an input that is too long? :)

I think a library asserting that the preconditions of its arguments are true is fine.

[Dylan16807]

An exception is fine if the language has them. I don't think "assert" was meant super literally and exactly the way C does it.

An error code is risky.

[CJefferson]

Honestly, I would assert. Returning an error code just gives users another thing to ignore, and incorrectly use the return value (if implemented like C, where you usually get a single internet back, treating the error code as a hash would be even worse!)

Apps crashing with assets is awfully, but at least it screams at your when you failed to read the docs, target than incorrectly storing users data for the rest of time.