Kod z błędem ze StackOverflow był kopiowany do tysięcy programów

Jeśli choć próbowałeś programować, na pewno trafiłeś na stronę StackOverflow. To ogromna baza przykładów i gotowych rozwiązań różnych problemów z komentarzami, objaśnieniami, a przede wszystkim możliwością kopiowania fragmentów kodu do własnych projektów. Niestety nie masz gwarancji, że ten kod będzie działał prawidłowo. Najczęściej kopiowany fragment kodu w Javie miał błąd… przez 9 lat!

Kod z błędem ze StackOverflow był kopiowany do tysięcy programów
Kod z błędem ze StackOverflow był kopiowany do tysięcy programów

05.12.2019 12:47

Gdyby nie naukowcy…

Fragment, o którym mowa, to odpowiedź na pytanie o wyświetlanie rozmiaru pliku. Konkretnie chodziło o wyświetlenie 123 456 789 bajtów w postaci zrozumiałej dla ludzi: 123,5 MB. Uwagę na tę odpowiedź zwróciła publikacja naukowa z 2018 roku. Naukowcy badali stopień wykorzystania fragmentów ze StackOverflow w projektach Open Source. Ten fragment trafił do ponad 6 tys. projektów na samym GitHubie, co jest rekordem dla programów napisanych w Javie. Kto wie, do ilu jeszcze projektów mógł trafić.

Autorem tego przykładu jest znany w środowisku Andreas Lundblad, programista i jeden z najbardziej cenionych członków społeczności StackOverflow. To dzięki tej publikacji Lundblad wrócił do swojego kodu i ponownie mu się przyjrzał. Sam znalazł błąd i przyznał się do tego na blogu. Przeliczanie bajtów do postaci przyjaznej dla ludzi jest wykonywane nieprawidłowo.

Lundblad poprawił swój kod i opublikował wersję działającą prawidłowo. Jeśli w swoim programie wykorzystujesz tę funkcję konwertującą, zamień ją na nową. Oto ona:


// From: https://programming.guide/the-worlds-most-copied-so-snippet.html
public static strictfp String humanReadableByteCount(long bytes, boolean si) {
    int unit = si ? 1000 : 1024;
    long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);
    if (absBytes < unit) return bytes + " B";
    int exp = (int) (Math.log(absBytes) / Math.log(unit));
    long th = (long) (Math.pow(unit, exp) * (unit - 0.05));
    if (exp < 6 && absBytes >= th - ((th & 0xfff) == 0xd00 ? 52 : 0)) exp++;
    String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i");
    if (exp > 4) {
        bytes /= unit;
        exp -= 1;
    }
    return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
}

To pikuś w porównaniu z innymi błędami

Myślę, że pan Lundblad nie obrazi się, jeśli napiszę, że była to niegroźna pomyłka w zupełnie trywialnej funkcji. Błąd był przez 9 lat kopiowany do tysięcy programów, ale nie wywołał żadnych szkód. Tę historię należy potraktować jak dobrą bajkę… ciekawą i zawierającą przestrogę.

Teraz wyobraź sobie, że ta funkcja nie przeliczała rozmiaru pliku, ale coś potrzebnego przy szyfrowaniu danych, komunikacji sieciowej albo podobnie wrażliwej czynności. Tak, zdarza się, że kod na StackOverflow ma luki bezpieczeństwa i są na to naukowe dowody (PDF). Naprawianie błędu po 9 latach byłoby bezcelowe. Badanie pokazało skalę ponownego wykorzystywania kodu i nawet jeśli założymy, że każdy z 6 tys. projektów jest wciąż utrzymywany, poprawienie wszystkich trwałoby latami.

Niedawno opisywałam przykłady „dziedziczenia” luk zabezpieczeń przez tysiące aplikacji z ogólnodostępną biblioteką. Nietrudno wyobrazić sobie sytuację, w której programiści kopiują kod z błędem ze StackOverflow. Wszyscy wiedzą, że to kiepski pomysł, ale i tak to robią. Co gorsza, programiści nie informują, skąd fragmenty pochodzą, przez co ich współpracownicy nie mają pojęcia o potencjalnym zagrożeniu.

Programy

Zobacz więcej
Wybrane dla Ciebie
Komentarze (71)