09-28-2011 02:48 PM
I am running a 64-bit data-logging application under Windows 7 Pro using LabWindows 2010 (10.0.1). Our program contains a logging function called from a callback. Depending on how the program is used, the callback can be triggered either by receiving data from an Ethernet message or by a timer.
In the following code, fgetpos() is supposed to store the file size in pos._offset, an unsigned 64-bit integer. We found that it sometimes fills the upper 32 bits of pos._offset with junk, causing the program to stop logging and throw an error message. It seems to happen especially when the user moves the mouse or attempts to close the program window:
status = fgetpos(fd_log, &pos); /* determine cur file pos */
if((pos._offset+log_block_size) > /* if 2GB limit reached ... */
0x7FFFFFFF)
{
DisplayViewType(LOG_OFF); /* disable log mode */
fclose(fd_log); /* close log file */
MessagePopup("Log Error",
"Log file has reached 2GB size limit - logging disabled.\r" \
"Start a new log session if you wish to continue logging.");
}
Has anyone else seen this problem?
Rich Ferrara, Telephonics
09-29-2011 05:23 PM
Rich,
Thank you for bring this to our attention. We believe this may actually be a bug introduced when upgrading functions for use with 64-bit systems. Essentially, the header was changed to use a 64-bit data type, but the implementation is still using a 32-bit data type. Therefore, if you are returning this value to a local variable, then it will not be initialized to 0 and you may have unexpected values for the upper 4 bytes. I have created a bug report (# 317147) that can be tracked and should be fixed in the next release of CVI.
You may be able to avoid this by setting the pos._offset to 0 before calling fgetpos.