PythonとRubyの実装のエラー密度を比較する

学習を開始するプログラミング言語：PythonまたはRuby？ どちらが良いですか？ DjangoまたはRuby on Railsですか？ このような質問は、世界中のITフォーラムでよく見られます。 言語自体ではなく、それらのリファレンス実装であるCPythonとMRIを比較することを提案します。 インタープリターのエラーPVS-Studioで検出できるエラーについては、この記事で説明します。

はじめに

分析のために、最新のソースは主要なリポジトリ（ Ruby 、 Python ）から取得されました。 検証は、 PVS-Studioバージョン6.06静的コードアナライザーを使用して実行されました。 PythonはVisual Studioで適切に構築されており、Rubyの場合は、コンパイラー呼び出しの監視モードでスタンドアロンバージョンを使用できます。



プロジェクトにはそれほど多くの露骨なエラーはありませんでした。肯定的なもののほとんどはマクロの使用に関係しており、マクロはアナライザーの観点からは非常に疑わしいコードで開示されていますが、開発者の観点からは無害です。 マクロが悪であるかどうかについて長い間議論できますが、アナライザーがマクロを好まないことは確かです。 迷惑なマクロを取り除くために、誤検知を抑制するオプションがあります。 書くだけで十分です：

//-V:RB_TYPE_P:501
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、RB_TYPE_PマクロをトリガーするすべてのV501診断が消えます。

Python

フラグメントN1

 #ifdef MS_WINDOWS typedef SOCKET SOCKET_T; #else typedef int SOCKET_T; #endif typedef struct { PyObject_HEAD SOCKET_T sock_fd; /* Socket file descriptor */ .... } PySocketSockObject; static int internal_select(PySocketSockObject *s, int writing, _PyTime_t interval, int connect) { .... if (s->sock_fd < 0) // <= return 0; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V547式 's-> sock_fd <0'は常にfalseです。 符号なしの型の値が<0になることはありませんsocketmodule.c 655



WindowsのSOCKETタイプは符号なしなので、ゼロと比較しても意味がありません。 socket（）関数が有効な記述子を返したかどうかを確認するには、その値をINVALID_SOCKETと比較する必要があります。 Linuxでは、ソケットタイプとして符号付きintが使用され、-1の値がエラーを通知するため、この比較が正しく機能することに注意してください。 ただし、検証には特別なマクロまたは定数を使用することをお勧めします。



警告が発行された同様のチェック：

• V547式 's-> sock_fd <0'は常にfalseです。 符号なしの型の値が<0になることはありません。_ssl.c1702
• V547式 'sock-> sock_fd <0'は常にfalseです。 符号なしの型の値が<0になることはありません。_ssl.c2018

フラグメントN2

 int ASN1_PRINTABLE_type(const unsigned char *s, int len) { int c; int ia5 = 0; .... if (!(((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z')) || (c == ' ') || // <= ((c >= '0') && (c <= '9')) || (c == ' ') || (c == '\'') || // <= (c == '(') || (c == ')') || (c == '+') || (c == ',') || (c == '-') || (c == '.') || (c == '/') || (c == ':') || (c == '=') || (c == '?'))) ia5 = 1; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V501 「||」の左と右に同一の副次式「（c ==」「）」があります 演算子。 a_print.c 77



Copy-Pasteの結果として発生するエラーの典型的な例。 多くの場合、コピーされたブロックが多数あると、プログラマーは注意を失い、そのうちの1つの変数または定数を変更するのを忘れます。 したがって、この場合、大きな条件式では、変数cと比較される値が混同されます。 正確に言うことは不可能ですが、二重引用符 '' 'を忘れたようです。

フラグメントN3

 static PyObject * semlock_acquire(SemLockObject *self, PyObject *args, PyObject *kwds) { .... HANDLE handles[2], sigint_event; .... /* prepare list of handles */ nhandles = 0; handles[nhandles++] = self->handle; if (_PyOS_IsMainThread()) { sigint_event = _PyOS_SigintEvent(); assert(sigint_event != NULL); handles[nhandles++] = sigint_event; } /* do the wait */ Py_BEGIN_ALLOW_THREADS if (sigint_event != NULL) //<= ResetEvent(sigint_event); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V614潜在的に初期化されていないポインター 'sigint_event'が使用されました。 semaphore.c 120



_PyOS_IsMainThread（）関数がfalseを返す場合、 sigint_eventポインターは初期化されないままになります。 これにより、未定義の動作が発生します。 このようなエラーは、デバッグバージョンでは簡単に見落とされる可能性があります。デバッグバージョンでは、ポインターはほとんどの場合ゼロに初期化されます。

フラグメントN4

 #define BN_MASK2 (0xffffffffffffffffLL) int BN_mask_bits(BIGNUM *a, int n) { .... a->d[w] &= ~(BN_MASK2 << b); //<= .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V610未定義の動作。 シフト演算子「<<」を確認してください。 左のオペランド '（0xffffffffffffffffffLL）'は負です。 bn_lib.c 796



ほとんどの場合、コードは機能しますが、この式は標準では未定義の動作です。 Andrei Karpovの記事で、負の数のシフトについて詳しく読むことができます。「 フォードを知らないで、水に入らないでください。パート3 」。 結果が規格で保証されていない設計を回避する価値があるかどうかはあなた次第ですが、これを拒否する方が良いとアナライザーは警告しています。

 static PyObject * binascii_b2a_qp_impl(PyModuleDef *module, Py_buffer *data, int quotetabs, int istext, int header) { Py_ssize_t in, out; const unsigned char *databuf; .... if ((databuf[in] > 126) || (databuf[in] == '=') || (header && databuf[in] == '_') || ((databuf[in] == '.') && (linelen == 0) && (databuf[in+1] == '\n' || databuf[in+1] == '\r' || databuf[in+1] == 0)) || (!istext && ((databuf[in] == '\r') || (databuf[in] == '\n'))) || ((databuf[in] == '\t' || databuf[in] == ' ') && (in + 1 == datalen)) || ((databuf[in] < 33) && (databuf[in] != '\r') && (databuf[in] != '\n') && (quotetabs || (!quotetabs && ((databuf[in] != '\t') && // <= (databuf[in] != ' ')))))) { .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V728過剰なチェックを簡素化できます。 「||」 演算子は、反対の式「quotetabs」と「！quotetabs」に囲まれています。 binascii.c 1453



このフラグメントは誤りではありませんが、個別に検討する価値があります。 警告は主に助言的です： 'A ||形式の表現 （！A && B） 'A ||に簡略化できます。 B ' ：これにより、少し洗練されたコードを少し簡単に読むことができます。



同様の警告：

• V728過剰なチェックを簡素化できます。 「||」 演算子は、反対の式「！type」と「type」に囲まれています。 digest.c 167
• V728過剰なチェックを簡素化できます。 「||」 演算子は、反対の表現「！cipher」と「cipher」に囲まれています。 evp_enc.c 120

フラグメントN5

 static int dh_cms_set_peerkey(....) { .... int atype; .... /* Only absent parameters allowed in RFC XXXX */ if (atype != V_ASN1_UNDEF && atype == V_ASN1_NULL) goto err; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V590 「atype！=-1 && atype == 5」式の検査を検討してください。 表現が過剰であるか、誤植が含まれています。 dh_ameth.c 670



奇妙なことに、論理式のエラーは、大規模なプロジェクトでも非常に一般的です。 このフラグメントの論理式は冗長です。「 atype == V_ASN1_NULL 」に簡略化できます。 ほとんどの場合、コンテキストに基づいて、ここにエラーはありませんが、そのようなコードは疑わしいように見えます。

フラグメントN6

 static void cms_env_set_version(CMS_EnvelopedData *env) { .... if (env->originatorInfo || env->unprotectedAttrs) env->version = 2; env->version = 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V519 「 env- > version」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：907、908。cms_env.c 908



このコードの作成者が元々暗示していたものを言うのは困難です。 おそらく、ここに他の行方不明があります。 ifには意味がありません。変数 ' env-> version'の値はどの場合でも上書きされるためです。

フラグメントN7

 int _PyState_AddModule(PyObject* module, struct PyModuleDef* def) { PyInterpreterState *state; if (def->m_slots) { PyErr_SetString(PyExc_SystemError, "PyState_AddModule called on module with slots"); return -1; } state = GET_INTERP_STATE(); if (!def) return -1; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V595 nullptrに対して検証される前に、「 self- > extra」ポインターが使用されました。 行を確認してください：917、923。_elementtree.c 917



ほとんどすべてのプロジェクトで発生するヌルポインターの逆参照に関連する従来のエラー。 最初に、式'def-> m_slots'で、それらはあるアドレスを参照し、次にこのアドレスがゼロであることが判明しました。 結果として、nullポインターの逆参照が発生し、プログラムのクラッシュなどの未定義の動作につながるため、 nullptrのチェックは機能しません。

ルビー

フラグメントN1

 static void vm_set_main_stack(rb_thread_t *th, const rb_iseq_t *iseq) { VALUE toplevel_binding = rb_const_get(rb_cObject, rb_intern("TOPLEVEL_BINDING")); rb_binding_t *bind; rb_env_t *env; GetBindingPtr(toplevel_binding, bind); GetEnvPtr(bind->env, env); vm_set_eval_stack(th, iseq, 0, &env->block); /* save binding */ if (bind && iseq->body->local_size > 0) { bind->env = vm_make_env_object(th, th->cfp); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V595 nullptrに対して検証される前に、「バインド」ポインターが使用されました。 行を確認：377、382。vm.c 377



Rubyプロジェクトで同様のエラーを回避しませんでした。 「if（bind）」をチェックしても、上記のコードでバインドが逆参照されているため、トラブルからあなたを救うことはありません。 Rubyには30を超えるこのような警告がありましたが、それらすべてを警告する意味はありません。

フラグメントN2

 static int code_page_i(....) { table = realloc(table, count * sizeof(*table)); if (!table) return ST_CONTINUE; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V701 realloc（）リークの可能性：realloc（）がメモリの割り当てに失敗すると、元のポインタ 'table'が失われます。 realloc（）を一時ポインターに割り当てることを検討してください。 file.c 169



コードのこのセクションでは、realloc値は引数として使用されるのと同じ変数に格納されます。 reallocがnullptrを返す場合、ポインタの元の値は失われ、メモリリークが発生します。

フラグメントN3

 static int w32_symlink(UINT cp, const char *src, const char *link) { .... BOOLEAN ret; typedef DWORD (WINAPI *create_symbolic_link_func) (WCHAR*, WCHAR*, DWORD); static create_symbolic_link_func create_symbolic_link = (create_symbolic_link_func)-1; .... ret = create_symbolic_link(wlink, wsrc, flag); ALLOCV_END(buf); if (!ret) { int e = GetLastError(); errno = map_errno(e); return -1; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V724タイプ「DWORD」をタイプ「BOOLEAN」に変換すると、高位ビットが失われる可能性があります。 ゼロ以外の値は「FALSE」になる可能性があります。 win32.c 4974



BOOLEAN型は、WinAPIで論理型として使用されます。 次のように宣言されます。

 typedef unsigned char BYTE; typedef BYTE BOOLEAN;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DWORDは32ビットの符号なし数値です。 したがって、たとえば、DWORD値0xffffff00をBOOLEAN（または最下位ビットがゼロに等しい他の値）に設定すると、0、つまりFALSEになります。

フラグメントN4

 static VALUE rb_str_split_m(int argc, VALUE *argv, VALUE str) { .... char *ptr = RSTRING_PTR(str); long len = RSTRING_LEN(str); long start = beg; .... if (ptr+start == ptr+len) start++; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

V584 「==」演算子の両側に「ptr」値があります。 式が正しくないか、単純化できます。 string.c 7211



比較の両方の部分で、 ptrの追加が存在するため、省略できます。

 if (start == len)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの場合、このフラグメントにはエラーはありません。 ただし、そのような式では、多くの場合、2つの異なる変数を実際に比較したいと考えています。 したがって、このような比較に注意することをお勧めします。

まとめ

汎用診断によって発行されたすべての警告を分析し、すべての誤検知を削除した後、次のエラー分布に到達しました。







RubyのトリガーのほとんどはV610警告（369回のトリップ！）から発生しましたが、それらを除外しても状況は変わりません。Pythonでは、疑わしいスポットの数はまだ少ないです。



V595診断は最も頻繁に行われることが判明しました。Pythonコードでは 17回、Rubyコードでは37回発生しました 。



しかし、最も興味深いのはエラー密度比です。 この特性により、Pythonも優れています。 計算結果は次の表に記載されています。







それは多くの間違いのように見えるかもしれません。 そうではありません。 まず、見つかったエラーのすべてが重要なわけではありません。 たとえば、前述のV610診断は、C ++言語の観点からエラーを検出します。 ただし、実際には、使用されるコンパイラのセットに対して結果が常に正しい場合があります。 このエラーはエラーではなくなりませんが、現在プログラムに影響はありません。 第二に、チェックされたコードのサイズを考慮する必要があります。 したがって、これらのプロジェクトの高品質について話すことができます。 これまでは、テスト済みプロジェクトのエラー密度を計算していなかったため、この評価は主観的です。 ただし、後で比較できるように、将来的にはこれを実行しようとします。

おわりに

PythonおよびRuby言語は非常に人気があり、世界中の何百万人もの開発者によって書かれています。 このようなプロジェクトおよびコミュニティの活動、コードの質の高さ、優れたテスト、および静的分析の使用（両方のプロジェクトはCoverityを使用してチェックされます）では、多数のエラーを見つけることは困難です。 それにもかかわらず、PVS-Studioはいくつかの不審な場所を見つけることができました。 しかし、コードを定期的にチェックすることで、開発者の生活が大幅に楽になることを理解する価値があります。 変更がリポジトリに反映されてリリースされる直前にエラーを修正するのが最善です-静的アナライザーは、これを他に類をみずに行うのに役立ちます



誰もが自分のプロジェクトでPVS-Studioを試すことをお勧めします。





この記事を英語を話す聴衆と共有したい場合は、翻訳へのリンクを使用してください：Pavel Belikov。 PythonとRubyの実装をエラー密度で比較しました 。







更新する この記事には不正確な内容が含まれています。 CPythonとRubyプロジェクト検証の説明をご覧ください。