PVS-Studio 6.22静的コードアナライザーは、ARMコンパイラーに適合しています（Keil、IAR）

PVS-Studioは、C、C ++、およびC＃プログラムのコードのエラーおよび潜在的な脆弱性を検索するための静的コードアナライザーです。 オープンなプロジェクトをチェックし、見つかったエラーを分析することで、長い間ブログの読者を喜ばせてきました。 アナライザーは組み込みデバイスのコードをチェックすることを学んだので、私たちの記事はさらに興味深いものになる可能性があります。 いくつかのARMコンパイラーをサポートしました。これについては、この記事で詳しく説明します。 組み込みデバイスおよびロボットのエラーは、アプリケーションプログラムのエラーよりもさらに大きくなる可能性があります。 内蔵デバイスのエラーは、単にプログラムのクラッシュ/フリーズまたは不適切な画像ではありません。 これはクレイジーなWi-Fiケトルで、沸騰して温度ヒューズが作動するまで水を沸騰させます。 一般的に、組み込みシステムの世界ではエラーが発生するため、すべてがより面白く、悪化しています。

私の最も壮大なバグ

プログラマーとしてのキャリアの中で、コードに多くの間違いを犯しました。 しかし、間違いはある意味退屈でした。 何かがそのように機能しなかった、どこかでNULLポインターが逆参照された、など。 はい、これらは修正が必要な本当の間違いでした。 しかし、その場しのぎのロボットを楽しんでいる間、私は自分の間違いについて最も鮮明な印象を受けました。

ロボット工学では、私はアマチュアであり、私の作品はすべて実験的で面白い性質のものです。 工芸品の1つは、リモートコントロールから制御され、ロボフットボールと「ネズミを捕まえる」ことができる4つの小さなロボットの作成でした。 詳細には触れませんが、乗る、ボールを打つ、爪をつかむ、音を出す、LEDを点滅させる方法を知っていることだけに注意します。 実際、根拠がないように、ここにロボットの1つがあります。



ボットは、ATmega8Aマイクロコントローラー（8 Kバイトフラッシュ、512バイトEEPROM、1 KバイトRAM）に基づいて実装されています。 プログラムの最初のバージョンでは、マイクロコントローラーのタイマーの1つが割り込みを生成し、そのプロセッサーでリモートコントロールからのコマンドが読み取られました。 コマンドがある場合、それらはFIFOバッファに書き込まれ、そこからメインプログラムサイクルで抽出および実行されます。 チームは次のようなものでした。 左/右に曲がってください。 少し左に曲がって進みます。 マウスをつかみます。 ボールを蹴るなど。

実際、すべてを再複雑化しました。 その後、FIFOバッファーを取り除き、一般的にますますシンプルかつ美しく書き込みました。

想像してみてください。マイクロコントローラーに新しいプログラムをアップロードし、ロボットの電源を入れると...突然、ロボットは自分の生活を始めます！

ボットは不規則に床を走り、爪をクリックし、存在しないボールを押し、点滅します。 さらに、行動は私には完全に理解不能です。 私の意見では、ロボットにはこのようなアクションを引き起こす可能性のあるコードはありません。

これは、プログラミングのすべての年に受け取ったプログラムエラーの最大の印象でした。 スタックオーバーフローが原因でプログラムがクラッシュする場合と、狂気のロボットが目の前に装着されている場合の1つです。 このアクションと私の感情をバックグラウンドで撮影することを推測しなかったのは残念です:)。

短い試行の後、最も古典的なプログラミングエラーの1つを行ったことがわかりました。FIFOバッファーに未処理のコマンドの数を格納する変数が初期化されていないことが判明しました。 ロボットはコマンドのランダムシーケンスの実行を開始し、バッファからデータを読み取り、すでにバッファの後にあるデータを読み取りました。

なぜこの話をしたのですか？ マイクロコントローラプログラムのエラーがもっと壮観になる可能性があることを示すためだけに、将来、興味深い出版物で読者を喜ばせたいと思います。 それでは、PVS-Studioアナライザーの新しいバージョンのリリースに関する記事のメイントピックに戻りましょう。

PVS-Studio 6.22

PVS-Studio 6.22アナライザーの新しいバージョンでは、次のタイプのプロジェクトをチェックするためのインフラストラクチャをチームが完成させました。

1. Keil uVision 5の一部としてARMコンパイラ5およびARMコンパイラ6のサポートが追加されました。
2. Keil DS-MDK環境の一部としてのコンパイラARMコンパイラ5およびARMコンパイラ6。
3. IAR Embedded Workbenchの一部として、ARM向けIAR C / C ++コンパイラをサポートしています。

RTスレッドプロジェクト

PVS-Studioの新機能を実証するには、オープンプロジェクトが必要でしたが、RT-Threadを選択しました。 このプロジェクトは、gcc / keil / iarモードで組み立てることができます。 アナライザーの追加テストのために、KeilモードとIARモードの両方でテストしました。 レポートはほとんど同じだったので、後でどちらを使用したか覚えていません。

RT-Threadプロジェクト自体について少し話しましょう。

RT-Threadは中国のオープンソースIoTオペレーティングシステムであり、強力なスケーラビリティを備えています。たとえば、ARM Cortex-M0、Cortex-M3 / 4/7などの小さなコアで実行される小さなカーネルから、実行される豊富な機能システムまで、 MIPS32、ARM Cortex-A8、ARM Cortex-A9 DualCoreなど

公式ウェブサイト： rt-thread.org

ソースコード： rt-thread

RT-Threadオペレーティングシステムは、PVS-Studioを使用してテストされた最初の組み込みプロジェクトになる非常に良い候補だと思います。

RT-Threadプロジェクトで気づいたエラー

私はPVS-Studioアナライザーのレポートをざっと見て、95の警告を選択しました。これは、私の意見では、最も興味深いものでした。 完全なHTMLレポートを含むrt-thread-html-log.zipアーカイブをダウンロードすることで、それらに慣れることができます。 最近この形式を実装しましたが、すべてのユーザーがこの形式を知っているわけではありません。 それで、私は機会についてそれについて再び書くことにしました。 Firefoxでは、このレポートは次のようになります。

このレポートは、Clangアナライザーによって生成されたHTMLレポートとの類推によって作成されます。 レポートにはソースコードの一部が保存され、プログラムの警告のどの部分に属しているかをすぐに確認できます。 警告の1つを表示するのは次のとおりです。

これらの多くは類似しているため、記事内の95個の警告すべてを考慮することは意味がありません。 この記事では、何らかの理由で説明に値すると思われる14個のコードスニペットのみを提供します。

ご注意 重大なエラーを示す重要な警告を見逃していた可能性があります。 したがって、RT-Thread開発者には、95個の警告を含むレポートだけに頼るのではなく、プロジェクトを自分で分析するように頼みます。 さらに、RT-Threadプロジェクトを適切に理解せず、その一部のみを確認したようです。

フラグメントN1。 CWE-562：スタック変数アドレスの戻り

void SEMC_GetDefaultConfig(semc_config_t *config) { assert(config); semc_axi_queueweight_t queueWeight; /*!< AXI queue weight. */ semc_queuea_weight_t queueaWeight; semc_queueb_weight_t queuebWeight; .... config->queueWeight.queueaWeight = &queueaWeight; config->queueWeight.queuebWeight = &queuebWeight; } 

PVS-Studio警告： V506 CWE-562ローカル変数「queuebWeight」へのポインターは、この変数のスコープ外に保存されます。 そのようなポインターは無効になります。 fsl_semc.c 257

この関数は、2つのローカル変数（ queueaWeightおよびqueuebWeight ）のアドレスを外部構造に書き込みます。 関数を終了すると、変数は存在しなくなりますが、構造体はこれらの既に存在しないオブジェクトへのポインターを保存して使用します。 実際、ポインターはスタック上の何でもできる場所を指します。 これは非常に厄介なセキュリティバグです。

PVS-Studioアナライザーは、最後の不審な割り当てのみを報告します。これは、その操作の内部機能に関連付けられています。 ただし、最後の割り当てが削除または修正されると、アナライザーは最初の割り当てについて警告を開始します。

フラグメントN2。 CWE-570：式は常に偽です

 #define CAN_FIFO0 ((uint8_t)0x00U) /*!< receive FIFO0 */ #define CAN_FIFO1 ((uint8_t)0x01U) /*!< receive FIFO1 */ uint8_t can_receive_message_length(uint32_t can_periph, uint8_t fifo_number) { uint8_t val = 0U; if(CAN_FIFO0 == fifo_number){ val = (uint8_t)(CAN_RFIFO0(can_periph) & CAN_RFIFO_RFL0_MASK); }else if(CAN_FIFO0 == fifo_number){ val = (uint8_t)(CAN_RFIFO1(can_periph) & CAN_RFIFO_RFL0_MASK); }else{ /* illegal parameter */ } return val; } 

PVS-Studio 警告 ： V517 CWE-570「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 行を確認してください：525、527。gd32f4xx_can.c 525

fifo_number引数がCAN_FIFO0と等しくない場合、関数は常に0を返します。コードはほとんどの場合、Copy-Pasteを使用して記述されており、コピーされたフラグメントで、 CAN_FIFO0定数をCAN_FIFO1で置き換えるのを忘れてしまいました 。

フラグメントN3。 CWE-571：式は常に真です

 #define PECI_M0D0C_HITHR_M 0xFFFF0000 // High Threshold #define PECI_M0D0C_LOTHR_M 0x0000FFFF // Low Threshold #define PECI_M0D0C_HITHR_S 16 #define PECI_M0D0C_LOTHR_S 0 void PECIDomainConfigGet(....) { unsigned long ulTemp; .... ulTemp = HWREG(ulBase + PECI_O_M0D0C + (ulDomain * 4)); *pulHigh = ((ulTemp && PECI_M0D0C_HITHR_M) >> PECI_M0D0C_HITHR_S); *pulLow = ((ulTemp && PECI_M0D0C_LOTHR_M) >> PECI_M0D0C_LOTHR_S); } 

PVS-Studioの警告：

• V560 CWE-571条件式の一部は常に真です：0xFFFF0000。 peci.c 372
• V560 CWE-571条件式の一部は常に真です：0x0000FFFF。 peci.c 373

2つの厄介なタイプミス：2つの演算子の代わりに、&&演算子が2回使用されました。

このため、 pulHigh変数は常に0に設定され、 pulLow変数は0または1に設定されます。これは明らかにプログラマーが意図したものではありません。

Cに慣れていない人への説明。式の結果（ulTemp && PECI_M0D0C_xxxxx_M）は常に0または1です。その後、0または1が右にシフトされます。 0/1から16ビットを右にシフトすると、常に0になります。0/ 1で0/1にシフトしても、0または1になります。

フラグメントN4。 CWE-480：不適切な演算子の使用

 typedef enum _aipstz_peripheral_access_control { kAIPSTZ_PeripheralAllowUntrustedMaster = 1U, kAIPSTZ_PeripheralWriteProtected = (1U < 1), kAIPSTZ_PeripheralRequireSupervisor = (1U < 2), kAIPSTZ_PeripheralAllowBufferedWrite = (1U < 2) } aipstz_peripheral_access_control_t; 

PVS-Studioの警告：

• V602 CWE-480「（1U <1）」式の検査を検討してください。 「<」は、おそらく「<<」に置き換える必要があります。 fsl_aipstz.h 69
• V602 CWE-480「（1U <2）」式の検査を検討してください。 「<」は、おそらく「<<」に置き換える必要があります。 fsl_aipstz.h 70
• V602 CWE-480「（1U <2）」式の検査を検討してください。 「<」は、おそらく「<<」に置き換える必要があります。 fsl_aipstz.h 71

名前付き定数は2のべき乗で、次の値に等しい必要があります。1、2、4、4。 その結果、次の値が取得されます。

• kAIPSTZ_PeripheralAllowUntrustedMaster = 1
• kAIPSTZ_PeripheralWriteProtected = 0
• kAIPSTZ_PeripheralRequireSupervisor = 1
• kAIPSTZ_PeripheralAllowBufferedWrite = 1

フラグメントN5。 CWE-834：過剰な反復

 static int ft5x06_dump(void) { uint8_t i; uint8_t reg_value; DEBUG_PRINTF("[FTS] Touch Chip\r\n"); for (i = 0; i <= 255; i++) { _ft5x06_read(i, &reg_value, 1); if (i % 8 == 7) DEBUG_PRINTF("0x%02X = 0x%02X\r\n", i, reg_value); else DEBUG_PRINTF("0x%02X = 0x%02X ", i, reg_value); } DEBUG_PRINTF("\n"); return 0; } 

PVS-Studio 警告 ： V654 CWE-834ループの条件 'i <= 255'は常に真です。 drv_ft5x06.c 160

タイプuint8_tの変数は[0..255]の範囲の値を格納できるため、条件i <= 255は常に真です。 このため、ループはデバッグデータを際限なく出力します。

フラグメントN6。 CWE-571：式は常に真です

 #define RT_CAN_MODE_NORMAL 0 #define RT_CAN_MODE_LISEN 1 #define RT_CAN_MODE_LOOPBACK 2 #define RT_CAN_MODE_LOOPBACKANLISEN 3 static rt_err_t control(struct rt_can_device *can, int cmd, void *arg) { .... case RT_CAN_CMD_SET_MODE: argval = (rt_uint32_t) arg; if (argval != RT_CAN_MODE_NORMAL || argval != RT_CAN_MODE_LISEN || argval != RT_CAN_MODE_LOOPBACK || argval != RT_CAN_MODE_LOOPBACKANLISEN) { return RT_ERROR; } if (argval != can->config.mode) { can->config.mode = argval; return bxcan_set_mode(pbxcan->reg, argval); } break; .... } 

PVS-Studio警告： V547 CWE-571式は常に真です。 ここでは、おそらく「&&」演算子を使用する必要があります。 bxcan.c 1171

ケースRT_CAN_CMD_SET_MODEは常に正しく処理されません。 実際には、 （x！= 0 || x！= 1 || x！= 2 || x！= 3）という形式の条件は常に真です。 ほとんどの場合、別のタイプミスを扱っているため、実際には次のように記述する必要があります。

 if (argval != RT_CAN_MODE_NORMAL && argval != RT_CAN_MODE_LISEN && argval != RT_CAN_MODE_LOOPBACK && argval != RT_CAN_MODE_LOOPBACKANLISEN) 

フラグメントN7。 CWE-687：引数値が正しく指定されていない関数呼び出し

 void MCAN_SetSTDFilterElement(CAN_Type *base, const mcan_frame_filter_config_t *config, const mcan_std_filter_element_config_t *filter, uint8_t idx) { uint8_t *elementAddress = 0; elementAddress = (uint8_t *)(MCAN_GetMsgRAMBase(base) + config->address + idx * 4U); memcpy(elementAddress, filter, sizeof(filter)); } 

アナライザーは、2つの異なる警告でエラーをすぐに示します。

• V579 CWE-687 memcpy関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 3番目の引数を調べます。 fsl_mcan.c 418
• V568 「sizeof（）」演算子がクラスへのポインタのサイズを評価するのは奇妙ですが、「filter」クラスオブジェクトのサイズは評価しません。 fsl_mcan.c 418

memcpy関数は、 mcan_std_filter_element_config_t型の構造全体をコピーするのではなく、1つのポインターのサイズに等しい部分のみをコピーします。

フラグメントN8。 CWE-476：NULLポインター逆参照

ポインタがチェックされる前に間接参照される場合、RT-Threadコードにエラーはありませんでした。 これは非常に一般的なタイプのエラーです。

 static rt_size_t rt_sdcard_read(rt_device_t dev, rt_off_t pos, void *buffer, rt_size_t size) { int i, addr; struct dfs_partition *part = (struct dfs_partition *)dev->user_data; if (dev == RT_NULL) { rt_set_errno(-EINVAL); return 0; } .... } 

PVS-Studio警告： V595 CWE-476 nullptrに対して検証される前に、「dev」ポインターが使用されました。 チェック行：497、499。sdcard.c 497

フラグメントN9。 CWE-563：使用しない変数への割り当て

 static void enet_default_init(void) { .... reg_value = ENET_DMA_BCTL; reg_value &= DMA_BCTL_MASK; reg_value = ENET_ADDRESS_ALIGN_ENABLE |ENET_ARBITRATION_RXTX_2_1 |ENET_RXDP_32BEAT |ENET_PGBL_32BEAT |ENET_RXTX_DIFFERENT_PGBL |ENET_FIXED_BURST_ENABLE |ENET_MIXED_BURST_DISABLE |ENET_NORMAL_DESCRIPTOR; ENET_DMA_BCTL = reg_value; .... } 

PVS-Studio警告： V519 CWE-563 'reg_value'変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：3427、3428。gd32f4xx_enet.c 3428

割り当てreg_value = ENET_ADDRESS_ALIGN_ENABLE | ....は、変数reg_valueの以前の値を粉砕します。 意味のある計算の結果は変数に格納されるため、これは奇妙です。 ほとんどの場合、コードは次のようになります。

 reg_value = ENET_DMA_BCTL; reg_value &= DMA_BCTL_MASK; reg_value |= ENET_ADDRESS_ALIGN_ENABLE |ENET_ARBITRATION_RXTX_2_1 |ENET_RXDP_32BEAT |ENET_PGBL_32BEAT |ENET_RXTX_DIFFERENT_PGBL |ENET_FIXED_BURST_ENABLE |ENET_MIXED_BURST_DISABLE |ENET_NORMAL_DESCRIPTOR; 

フラグメントN10。 CWE-665：不適切な初期化

 typedef union _dcp_hash_block { uint32_t w[DCP_HASH_BLOCK_SIZE / 4]; uint8_t b[DCP_HASH_BLOCK_SIZE]; } dcp_hash_block_t; typedef struct _dcp_hash_ctx_internal { dcp_hash_block_t blk; .... } dcp_hash_ctx_internal_t; status_t DCP_HASH_Init(DCP_Type *base, dcp_handle_t *handle, dcp_hash_ctx_t *ctx, dcp_hash_algo_t algo) { .... dcp_hash_ctx_internal_t *ctxInternal; .... for (i = 0; i < sizeof(ctxInternal->blk.w) / sizeof(ctxInternal->blk.w[0]); i++) { ctxInternal->blk.w[0] = 0u; } .... } 

PVS-Studio警告： V767ループ内の定数インデックスによる「w」配列の要素への疑わしいアクセス。 fsl_dcp.c 946

アナライザーはこの警告でCWE IDと一致しませんでしたが、意味的にはCWE-665：不適切な初期化であるべきです。

ループでは、値0が常に配列のゼロ要素に書き込まれ、残りの要素は初期化されません。

フラグメントN11。 CWE-571：式は常に真です

 static void at91_mci_init_dma_read(struct at91_mci *mci) { rt_uint8_t i; .... for (i = 0; i < 1; i++) { /* Check to see if this needs filling */ if (i == 0) { if (at91_mci_read(AT91_PDC_RCR) != 0) { mci_dbg("Transfer active in current\n"); continue; } } else { if (at91_mci_read(AT91_PDC_RNCR) != 0) { mci_dbg("Transfer active in next\n"); continue; } } length = data->blksize * data->blks; mci_dbg("dma address = %08X, length = %d\n", data->buf, length); if (i == 0) { at91_mci_write(AT91_PDC_RPR, (rt_uint32_t)(data->buf)); at91_mci_write(AT91_PDC_RCR, .....); } else { at91_mci_write(AT91_PDC_RNPR, (rt_uint32_t)(data->buf)); at91_mci_write(AT91_PDC_RNCR, .....); } } .... } 

PVS-Studioの警告：

• V547 CWE-571式「i == 0」は常に真です。 at91_mci.c 196
• V547 CWE-571式「i == 0」は常に真です。 at91_mci.c 215

ループの本体は1回だけ実行されます。 意味がありません なぜサイクルを書くのですか？

さらに、ループ本体では変数iが常に0であるため、一部の条件は常に真であり、コードの一部が満たされることはありません。

実際、開発者はサイクルの本体を2回実行することを計画していたようですが、タイプミスをしました。 おそらく、次のようなループ条件を作成する必要があります。

 for (i = 0; i <= 1; i++) 

この場合、機能コードが意味をなします。

フラグメントN12。 CWE-457：初期化されていない変数の使用

関数本体の大きな断片を持ってきたことをおpoびします。 これは、変数kが値を読み取る前に実際にはどこでも初期化されていないことを示すために必要です。

 void LCD_PutPixel (LCD_PANEL panel, uint32_t X_Left, uint32_t Y_Up, LcdPixel_t color) { uint32_t k; uint32_t * pWordData = NULL; uint8_t* pByteData = NULL; uint32_t bitOffset; uint8_t* pByteSrc = (uint8_t*)&color; uint8_t bpp = bits_per_pixel[lcd_config.lcd_bpp]; uint8_t bytes_per_pixel = bpp/8; uint32_t start_bit; if((X_Left >= lcd_hsize)||(Y_Up >= lcd_vsize)) return; if(panel == LCD_PANEL_UPPER) pWordData = (uint32_t*) LPC_LCD->UPBASE + LCD_GetWordOffset(X_Left,Y_Up); else pWordData = (uint32_t*) LPC_LCD->LPBASE + LCD_GetWordOffset(X_Left,Y_Up); bitOffset = LCD_GetBitOffset(X_Left,Y_Up); pByteData = (uint8_t*) pWordData; pByteData += bitOffset/8; start_bit = bitOffset%8; if(bpp < 8) { uint8_t bit_pos = start_bit; uint8_t bit_ofs = 0; for(bit_ofs = 0;bit_ofs <bpp; bit_ofs++,bit_pos++) { *pByteData &= ~ (0x01 << bit_pos); *pByteData |= ((*pByteSrc >> (k+bit_ofs)) & 0x01) << bit_pos; // <= } } .... } 

PVS-Studio警告： V614 CWE-457初期化されていない変数 'k'が使用されました。 lpc_lcd.c 510

変数kは 、式で使用されるまでどこでも初期化されません。

 *pByteData |= ((*pByteSrc >> (k+bit_ofs)) & 0x01) << bit_pos; 

フラグメントN13。 CWE-670：常に正しくない制御フローの実装

 HAL_StatusTypeDef FMC_SDRAM_SendCommand(....) { .... /* wait until command is send */ while(HAL_IS_BIT_SET(Device->SDSR, FMC_SDSR_BUSY)) { /* Check for the Timeout */ if(Timeout != HAL_MAX_DELAY) { if((Timeout == 0)||((HAL_GetTick() - tickstart) > Timeout)) { return HAL_TIMEOUT; } } return HAL_ERROR; } return HAL_OK; } 

PVS-Studio警告： V612 CWE-670ループ内の無条件の「戻り」。 stm32f7xx_ll_fmc.c 1029

ループの本体は1回しか実行されません。 ifステートメントを使用して同じ動作を取得する方が論理的であるため、これは非常に疑わしいです。 おそらく、何らかの論理エラーがあります。

フラグメントN14。 その他

先ほど言ったように、私はこの記事でいくつかのエラーのみを引用しました。 選択した警告の完全なリストは、HTMLレポート（レポートとともにアーカイブ： rt-thread-html-log.zip ）にあります。

明らかなエラーに加えて、不審なコードを示す警告もレポートに残しました。 コードにエラーがあるかどうかはわかりませんが、このコードはRT-Thread開発者が必ず確認する必要があります。 そのような警告の例を示します。

 typedef unsigned long rt_uint32_t; static rt_err_t lpc17xx_emac_init(rt_device_t dev) { .... rt_uint32_t regv, tout, id1, id2; .... LPC_EMAC->MCFG = MCFG_CLK_DIV20 | MCFG_RES_MII; for (tout = 100; tout; tout--); LPC_EMAC->MCFG = MCFG_CLK_DIV20; .... } 

PVS-Studio警告： V529 CWE-670奇数セミコロン ';' 「for」演算子の後。 emac.c 182

プログラマーはループを使用して、わずかな遅延を作成しました。 間接的ではありますが、アナライザーはこれに注目します。

コンパイラを最適化する私の世界では、これは明らかな間違いです。 コンパイラは単にこのループをスローし、遅延は発生しません。 toutは通常の不揮発性変数です。 組み込みの世界で物事がどのようになっているのかはわかりませんが、コードがまだ正しくないか、少なくとも信頼性が低いと思われます。 コンパイラーがそのようなサイクルをスローしなくても、遅延の持続時間と十分であるかどうかは明確ではありません。

私の知る限り、そのようなシステムにはsleep_usのような関数があります。 小さな遅延に使用する必要があります。 コンパイラは、 sleep_us関数の呼び出しを通常の単純なループに変えることもできますが、これらは実装機能です。 このような遅延サイクルを書く手はくて危険です。

おわりに

読者が、参加している開発中の組み込みシステムのプロジェクトをチェックアウトすることをお勧めします。 最初にARMコンパイラをサポートしましたが、オーバーレイが存在する場合があります。 したがって、発生したすべての質問をサポートするために私達に連絡することをheしないでください。

PVS-Studioのデモ版はこちらからダウンロードできます。

組み込みシステムの多くのプロジェクトは非常に小さく、ライセンスを取得することは実際的ではないことを理解しています。 そのため、無料のライセンスオプションを提供しています。詳細については、「 PVS-Studioを無料で使用する方法 」の記事を参照してください。 無料のライセンスオプションの大きな利点は、オープンなプロジェクトだけでなく、クローズドプロジェクトでも使用できることです。

あなたの注意と不注意なロボットに感謝します！

サイトリンク

この記事は、新しい視聴者を魅了します。 したがって、PVS-Studioツールにまだ慣れていない人のために、次の記事を読むことをお勧めします。

1. ドキュメンテーション LinuxでPVS-Studioを実行する方法 。
2. アンドレイ・カルポフ。 EFLコアライブラリの例を使用したPVS-Studioアナライザーの特性、誤検知の10〜15％ 。
3. アンドレイ・カルポフ。 静的コード分析に関する議論 。
4. アンドレイ・カルポフ。 PVS-Studioプロジェクトが10年前に始まった経緯 。
5. アンドレイ・カルポフ。 Unreal Engine開発プロセスの一部としての静的解析 。
6. セルゲイ・クレノフ。 SonarQubeのプラグインとしてのPVS-Studio
7. エフゲニー・リジコフ。 静的コード分析の哲学：プログラマーは100人いますが、アナライザーはエラーをほとんど見つけませんでしたが、役に立たないのですか？
8. セルゲイ・ヴァシリエフ。 PVS-Studioは脆弱性の検索にどのように役立ちますか？
9. アンドレイ・カルポフ。 プログラマーが読むべきではないマネージャー向けの静的コード分析に関する記事 。
10. アンドレイ・カルポフ。 静的アナライザーが偽陽性と戦う方法と理由 。
11. ヴセヴォロド・ルトビノフ。 Eclipse CDT（Linux）にPVS-Studioを組み込みました 。
12. アンドレイ・クズネツォフ。 PVS-StudioをAnjuta DevStudio（Linux）に組み込みました 。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 Static Code Analyzer PVS-Studio 6.22は、ARMコンパイラー（Keil、IAR）をサポートするようになりました 。