Writing to a Text File 101
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
David Kentley wrote:
when any of the variables has more digits than was allocated in the Format call
Does that ever actually happen?
-
David Kentley wrote:
when any of the variables has more digits than was allocated in the Format call
Does that ever actually happen?
aspdotnetdev wrote:
Does that ever actually happen?
Yes, as I discovered today when I had to track down a customer reported bug. It is an usual case, but it's completely possible and even legitimate. I had no idea what I would find under the rock I kicked over.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
rewrite it in COBOL, it's good at that sort of stuff ;P
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
Such constructs aren't so rare... in a company I worked years ago, we had to import lots of different file formats, and I'd say, 50% of them used a similar "design". Not to mention that our fantastic database also almost worked like that - yay! No wonder that company doesn't exist anymore.
-
Such constructs aren't so rare... in a company I worked years ago, we had to import lots of different file formats, and I'd say, 50% of them used a similar "design". Not to mention that our fantastic database also almost worked like that - yay! No wonder that company doesn't exist anymore.
Doesn't the fact that the company is now defunct mean that such constructs are, at least, getting rarer...? :)
-
Doesn't the fact that the company is now defunct mean that such constructs are, at least, getting rarer...? :)
Only in theory. For every horrible coder out of the race two new ones come to replace him. And the odds are good that the one who did this is still at large somewhere out there.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
-
Only in theory. For every horrible coder out of the race two new ones come to replace him. And the odds are good that the one who did this is still at large somewhere out there.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
It's enough to make ya cry into your beer... :(( P.S. I like your sig.
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
Sometimes you just have to hope for the best until you get the next job - at least, this was the credo of more than one programmer who I've met in person or simply in the trash they left behind :sigh:
-
for(i = 0; i < num; i++)
{
// Add data from each entry, each line is EXACTLY 105 bytes
strIntString.Format(_T("%3d,%#9.*f,%#9.*f,%#9.*f,%#9.*f,%#6.*f,%#6.*f,%#6.*f,%#6.*f,%02d:%02d:%02d,%3d,%4d,%1d,%5d,%1d,%3d\r\n"),
newObject->m_nIndex,
temp.prec[0], newObject->val1[0], temp.prec[1], newObject->val1[1],
temp.prec[2], newObject->val1[2], temp.prec[3], newObject->val1[3],
temp.prec2[0], newObject->val2[0], temp.prec2[1], newObject->val2[1],
temp.prec2[2], newObject->val2[2], temp.prec2[3], newObject->val2[3],
newObject->m_nHours, newObject->m_nMinutes, newObject->m_nSeconds,
newObject->m_nNext, newObject->m_nTotal, newObject->m_nGroup,
newObject->m_Extra, newObject->m_nMode, options);//write this line out to the file numOut=strIntString.GetLength(); m\_File->Seek(HEADERLEN+(105\*i),CFile::begin); m\_File->Write(strIntString,numOut); strIntString.Empty();}
Guess what happens when any of the variables has more digits than was allocated in the Format call. Right, the line is no longer "EXACTLY" 105 bytes. File becomes a messy pile of bytes. The only thing I changed from the actual code were the variable names. This is in production code, currently being run by thousands of customers. You should see how these files are read in. It's worse, but too long to post. Sigh.
He said, "Boy I'm just old and lonely, But thank you for your concern, Here's wishing you a Happy New Year." I wished him one back in return.
I had something similar in production to fix. File had fixed length lines, every column meant something and couldn't change. But it did, suddenly some lines were one char too long, so some columns were invalid. A 2 char field was supposed to be 01, 02, or 03. An int was being used to calculate, and got incremented up to 98, 99, 100, .... More than 2 characters. The program was using C char* with strcpy and strcat, so this field being too long shifted the position of all following fields, bad data! I corrected the field to only be 1, 2 or 3 (zero prepended to make 2 chars), and added checks for the line length before outputting to a the required file. And starting using C++ class std::string instead of char* in my newer code to help my sanity.