I think I may have found a bug in viPrintf (NI-VISA 15.5.0, Windows 7) which exhibits when using the "%s" format specifier and a very large string argument.
I wrote a program to reproduce the bug which sends "*CLS;*ESE 1;*SRE 32\n" to an instrument to configure it to generate a service request when operations complete, followed in a separate transaction by the "*OPC" command. Since no overlapped commands are in progress, the instrument should immediately generate a service request (and it does).
Then I started prepending space characters before the "*OPC" command to see what happens. With NI IO Trace running, I see very strange behavior when the length of the command crosses the 510/511-byte boundary. If I viPrintf a 510 byte command, the VISA library does a formatted viWrite with a 510 byte payload, as expected. If I viPrintf a 511 byte command, the VISA library does a formatted viWrite with a 1021 byte payload, and I have no idea where those other 510 bytes came from. I have verified that the string argument passed to viPrintf is properly nul-terminated.
I am attaching the source code I used to reproduce the bug. It compiles into a Windows console application, which takes one (optional) command line argument: an integer specifying the length of the whitespace-padded "*OPC" command. I am also attaching to NI IO Trace captures, the first from running the program with the argument 510, the second with 511. In the former, the formatted viWrite correctly writes 510 bytes to the instrument, in the latter it writes 1021.
I am using a USBTMC instrument for which I am developing the firmware, and have verified that the device dependent bulk-out transfers match the sizes reported by NI IO Trace.
Thanks.
