W 3.6% przetestowanych repozytoriów Pythona brakowało błędów w postaci przecinków

Opublikowano wyniki badania dotyczącego podatności kodu Pythona na błędy związane z nieprawidłowym użyciem przecinków w kodzie. Problemy wynikają z faktu, że Python podczas wyliczania automatycznie łączy ciągi znaków na liście, jeśli nie są oddzielone przecinkiem, a także traktuje wartość jako krotkę, jeśli po wartości następuje przecinek. Po przeprowadzeniu automatycznej analizy 666 repozytoriów GitHub z kodem Pythona badacze zidentyfikowali możliwe problemy z przecinkami w 5% badanych projektów.

Dalsza ręczna kontrola wykazała, że ​​rzeczywiste błędy występowały jedynie w 24 repozytoriach (3.6%), a pozostałe 1.4% to fałszywe alarmy (na przykład można było celowo pominąć przecinek między wierszami w celu połączenia wielowierszowych ścieżek plików, długich skrótów, kodu HTML bloki lub wyrażenia SQL). Warto zauważyć, że wśród 24 repozytoriów z prawdziwymi błędami znalazły się tak duże projekty jak Tensorflow, Google V8, Sentry, Pydata xarray, Rapidpro, Django-colorfield i Django-helpdesk. Jednak problemy z przecinkami nie są specyficzne dla Pythona i często pojawiają się w projektach C/C++ (przykładami ostatnich poprawek są LLVM, Mono, Tensorflow).

Główne rodzaje badanych błędów:

  • Przypadkowy brak przecinka na listach, krotkach i zestawach powoduje łączenie ciągów zamiast interpretacji ich jako oddzielnych wartości. Na przykład w Sentry w jednym z testów pominięto przecinek między ciągami „releases” i „discover” na liście, co spowodowało sprawdzenie nieistniejącego modułu obsługi „/releasesdiscover” zamiast sprawdzania „/releases” i „ /odkryj” osobno.
    W 3.6% przetestowanych repozytoriów Pythona brakowało błędów w postaci przecinków

    Innym przykładem jest brak przecinka w RapidPro, który spowodował połączenie dwóch różnych reguł w linii 572:

    W 3.6% przetestowanych repozytoriów Pythona brakowało błędów w postaci przecinków

  • Brakujący przecinek na końcu jednoelementowej definicji krotki, powodujący przypisanie zwykłego typu, a nie krotki. Przykładowo wyrażenie „wartości = (1,)” spowoduje przypisanie do zmiennej krotki jednego elementu, natomiast „wartości = (1)” spowoduje przypisanie typu całkowitego. Nawiasy w tych przypisaniach nie mają wpływu na definicję typu i są opcjonalne, a obecność krotki jest określana przez parser tylko na podstawie obecności przecinków. REST_FRAMEWORK = { 'DEFAULT_PERMISSION_CLASSES': ( 'rest_framework.permissions.IsAuthenticated' # zostanie przypisany ciąg znaków zamiast krotki. ) }
  • Odwrotną sytuacją są dodatkowe przecinki podczas przypisywania. Jeśli na końcu przypisania przypadkowo zostanie pozostawiony przecinek, jako wartość zamiast zwykłego typu zostanie przypisana krotka (na przykład, jeśli zamiast „wartość = 1” podano „wartość = 1”).

Źródło: opennet.ru

Dodaj komentarz