Hacker News Reader

Comment by chopin | Hacker News Reader

I am not sure whether I understand rule #2 correctly. My main use case for loops is iterating over an array or a list of statically unknown size, therefore the loop is limited to the actual size of the array or list. Would that count as statically provable? At least in Java, these cannot hold more than 2^31 elements for the standard library collections. For this use case, would it be required to have a hard-coded upper bound additionally?

View on HN

It's closely coupled with rule #3. An array at least in the safety critical embedded software have a fixed size determined at initialization. You may have a sentinel value you're looking for, but, the loop should never exceed the preallocated size.

There are another set of arguments /against/ using stopping the loop at the sentinel values because it may make the software less deterministic. But, that's another topic.

An example wold be to use memcpy() instead of strcpy().

memcpy() always copies n bytes, regardless of actual string size so is very deterministic and (commonly) inlined so is static. strcpy() on the other hand would loop infinitely until it found a null-terminator, it also is not deterministic.

memcpy() is easily analysable. strcpy() isn't.

Less deterministic? Isn't it quite deterministic if something stops when a static limit is exceeded?

This helps ensure that if your software runs in 10ms on the test data set, then it will always run in 10ms on all data sets. In general, it is recommended to avoid "best case" optimization, so that your critical software is always running with "worst case" performance.

EDIT: On re-reading your message and the message it is responding to, I believe you are meaning opposite things by "sentinel".

> For this use case, would it be required to have a hard-coded upper bound additionally?

Yes. It can be a few orders of magnitude higher than your expected array size: the goal is to prevent infinite loops. If you're looping over short user provided strings, if you hit an arbitrary counter of 1M, something probably went wrong, and the code should error out appropriately.

It's interesting to note that Intrado's recent 9-1-1 service outage was due to a hard-coded limit on the total number of calls that could pass through their system. Took them many hours to get the system back online after the limit was hit and further calls rejected.

Though I suppose in real safety critical systems, you often review these limits and make sure they still apply.

Right. You'd also want a soft limit. Your regular diagnostics would notice the counter was over the soft limit and turn on the equivalent of a 'check engine' light.

Reply on news.ycombinator.com