> (ps i was talking about the code on the server side; not chromium)
Oh I see.
> on the server side, it looks like the problem could have been avoided with better types - it seem that there was a confusion between status values that can include 0 and those that cannot (alternatively, perhaps better, there was no status for the case where the status was undefined?)
From what I understood, they are talking about protocol buffer types. The sync server sent message to chromium to throttle for all types say A, B, and C. Chromium didn't know about type C, some code returned 0 for unspecified type, another piece of code calculates index based on what is returned in the previous step, and then due to the 0, a negative index was accessed in the bitset leading to out of bound exception.
The issue is server sent all types to clients rather than sending only types known to the client, and the client didn't gracefully handle unknown types. I don't think a better type system would have helped the server - that looks like a logic bug, not a typing bug.
what i was trying to say is that you can (often) push this kind of logic bug into the type system - by having, if you like, different types of statuses, or a special type for unknown values (a "maybe status").
if you can do that then you can get the "infallible" compiler to provide the "this branch will not be executed" logic. but there may be efficiency trade-offs, or it may be so directly tied to low level protocols that it is impossible.
five ten years ago i would not have thought of the problem in this way - i would have agreed with you (and the bug report) that it is just logic. but slowly i am starting to learn to rely more on types. but i don't know enough here to suggest details...
Oh I see.
> on the server side, it looks like the problem could have been avoided with better types - it seem that there was a confusion between status values that can include 0 and those that cannot (alternatively, perhaps better, there was no status for the case where the status was undefined?)
From what I understood, they are talking about protocol buffer types. The sync server sent message to chromium to throttle for all types say A, B, and C. Chromium didn't know about type C, some code returned 0 for unspecified type, another piece of code calculates index based on what is returned in the previous step, and then due to the 0, a negative index was accessed in the bitset leading to out of bound exception.
The issue is server sent all types to clients rather than sending only types known to the client, and the client didn't gracefully handle unknown types. I don't think a better type system would have helped the server - that looks like a logic bug, not a typing bug.