Am 19.01.23 um 02:39 schrieb Jeff King: > > Though I do find the use of strlen() in decode_tree_entry() > a little suspicious (and that would be true of the current code, as > well, since it powers hash-object's existing parsing check). strlen() won't overrun the buffer because the first check in decode_tree_entry() makes sure there is a NUL in the buffer ahead. If get_mode() crosses it then we exit early. Storing the result in an unsigned int can overflow on platforms where size_t is bigger. That would result in pathlen values being too short for really long paths, but no out-of-bounds access. They are then stored as signed int in struct name_entry and used as such in many places -- that seems like a bad idea, but I didn't actually check them thoroughly. get_mode() can overflow "mode" if there are too many octal digits. Do we need to accept more than two handfuls in the first place? I'll send a patch for at least rejecting overflow. Hmm, what would be the performance impact of trees with mode fields zero-padded to silly lengths? René
