sprintf() 和 WriteFile() 影响字符串缓冲区

Question

我有一个非常奇怪的问题，我似乎无法弄清楚。 不幸的是，如果不描述我的整个应用程序，我什至不确定如何描述它。 我想做的是：

1) read a byte from the serial port
2) store each char into tagBuffer as they are read
3) run a query using tagBuffer to see what type of tag it is (book or shelf tag)
4) depending on the type of tag, output a series of bytes corresponding to the type of tag

我的大部分代码都已实现，并且我可以获得从串行端口发回的正确标签代码。 但是我添加了两行作为调试语句，当我尝试删除它们时，它们会导致我的程序停止工作。

这些行是最底部的两行：

    sprintf(buf,"%s!\n", tagBuffer);
    WriteFile(hSerial,buf,strlen(buf), &dwBytesWritten,&ovWrite);

如果我尝试删除它们，“tagBuffer”将只存储最后一个字符，而不是作为缓冲区。 下一行 WriteFile() 也是如此。

我认为 sprintf 和 WriteFile 是 I/O 函数，不会对变量产生影响。 我被困住了，我需要帮助来解决这个问题。

//keep polling as long as stop character '-' is not read
while(szRxChar != '-')
{
    // Check if a read is outstanding
    if (HasOverlappedIoCompleted(&ovRead))
    {
        // Issue a serial port read
        if (!ReadFile(hSerial,&szRxChar,1,
                &dwBytesRead,&ovRead))
        {
            DWORD dwErr = GetLastError();
            if (dwErr!=ERROR_IO_PENDING)
                return dwErr;
        }
    }

    // resets tagBuffer in case tagBuffer is out of sync
    time_t t_time = time(0);
    char buf[50];
    if (HasOverlappedIoCompleted(&ovWrite))
    {
        i=0;                                       
    }

    // Wait 5 seconds for serial input
    if (!(HasOverlappedIoCompleted(&ovRead)))
    {
        WaitForSingleObject(hReadEvent,RESET_TIME);
    }

    // Check if serial input has arrived
    if (GetOverlappedResult(hSerial,&ovRead,
            &dwBytesRead,FALSE))
    {
        // Wait for the write
        GetOverlappedResult(hSerial,&ovWrite,
            &dwBytesWritten,TRUE);

        if( strlen(tagBuffer) >= PACKET_LENGTH )
        {
            i = 0;
        }

        //load tagBuffer with byte stream
        tagBuffer[i] = szRxChar;
        i++;
        tagBuffer[i] = 0; //char arrays are \0 terminated

        //run query with tagBuffer  
        sprintf(query,"select type from rfid where rfidnum=\"");
        strcat(query, tagBuffer);
        strcat(query, "\"");
        mysql_real_query(&mysql,query,(unsigned int)strlen(query));

        //process result and send back to handheld
        res = mysql_use_result(&mysql);
        while(row = mysql_fetch_row(res))
        {
           printf("result of query is %s\n",row[0]);

           string str = "";
           str = string(row[0]);

           if( str == "book" )
           {
               WriteFile(hSerial,BOOK_INDICATOR,strlen(BOOK_INDICATOR),
                &dwBytesWritten,&ovWrite);
           }
           else if ( str == "shelf" )
           {
               WriteFile(hSerial,SHELF_INDICATOR,strlen(SHELF_INDICATOR),
                &dwBytesWritten,&ovWrite);
           }
           else //this else doesn't work
           {
               WriteFile(hSerial,NOK,strlen(NOK),
                &dwBytesWritten,&ovWrite);
           }
        }


        mysql_free_result(res);

        // Display a response to input
        //printf("query is %s!\n", query);
        //printf("strlen(tagBuffer) is %d!\n", strlen(tagBuffer));

        //without these, tagBuffer only holds the last character
        sprintf(buf,"%s!\n", tagBuffer);
        WriteFile(hSerial,buf,strlen(buf), &dwBytesWritten,&ovWrite);

    }
}

通过这两行，我的输出如下所示： s sh she shel架子架0架子00书码架子0001

没有它们，我发现tagBuffer和buf在任何时候都只存储最新的字符。

任何帮助都将不胜感激。 谢谢。

Answer 1

您在哪里分配标签缓冲区，它有多大？
您可能会覆盖“buf”，因为您写入的内容超出了标记缓冲区的末尾。

Answer 2

这两行似乎不太可能对正确的程序产生这种影响 - 也许您没有在 buf 中为 tagBuffer 中字符串的整个长度分配足够的空间？ 这可能会导致缓冲区溢出，从而掩盖了真正的问题？

Answer 3

我要说的第一件事是一条一般性建议：错误并不总是在您认为的位置。 如果你遇到了一些似乎没有意义的事情，这通常意味着你在其他地方的假设是错误的。

在这里，sprintf() 和 WriteFile() 似乎不太可能改变“buf”数组变量的状态。 但是，这两行测试代码确实写入“hSerial”，而主循环也从“hSerial”读取。 这听起来像是改变程序行为的秘诀。

建议：更改调试输出行以将输出存储在其他位置：对话框、日志文件或类似文件。 调试输出通常不应进入核心逻辑中使用的文件，因为这很可能会改变核心逻辑的行为方式。

Answer 4

在我看来，这里真正的问题是您试图从单个线程读取和写入串行端口，这使得代码比需要的更加复杂。 我建议您阅读以下文章并重新考虑您的设计：

• 来自 Joseph 的 串行端口 I/O新人网站。
• 来自 MSDN 的 Win32 中的串行通信。

在多线程实现中，每当读取器线程从串行端口读取消息时，您都会将其发布到应用程序的主线程。 然后，主线程将解析消息并查询数据库，然后将适当的响应排队到写入器线程。

这听起来可能比您当前的设计更复杂，但实际上并非如此，正如 Newcomer 所解释的那样。

我希望这有帮助！