• pryre@lemmy.world
    link
    fedilink
    English
    arrow-up
    86
    arrow-down
    2
    ·
    2 天前

    I think the other takeaway here is that it was found in a section marked “unsafe”. At the very least, that’s a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere.

    • hummingbird@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      19 小时前

      The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code.

      • KexPilot@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        16 小时前

        No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.

        Tldr: the problem lies in the unsafe part

      • pryre@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        19 小时前

        I’ll admit, I haven’t looked at the code. I would stand by my comment of the unsafe block being a start point.

        Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it’s down to the people that identified it and fixed it at the end of the day to say if there was any benefit.