lianlab / gamekit

Automatically exported from code.google.com/p/gamekit
0 stars 0 forks source link

utStringFormat needs work(portability issues). #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. On linux at least strings longer then the buffer size in utStringFormat 
itself get truncated.

What is the expected output? What do you see instead?
String should not get truncated, but should grow. String was truncated leading 
to test case failure.

What version of the product are you using? On what operating system?
trunk Linux(fails), WinNt[Win7](passes)

Please provide any additional information below.

Error checking needs to be done in a portable manner, and buffer should be 
grown or a failure condition raised.

Original issue reported on code.google.com by bsd...@gmail.com on 13 Mar 2011 at 12:12

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I will work on a fix for the noted issues before too long.

Original comment by bsd...@gmail.com on 13 Mar 2011 at 12:14

GoogleCodeExporter commented 9 years ago
 RUN      ] testUtString.testStringFormat
/media/sf_D_DRIVE/gamekit/UnitTests/OgreKitUnitTests/TestCase/testUtString.cpp:6
1: Failure
Value of: longString
  Actual: "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000091"
Expected: slong.c_str()
Which is: 
"0000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000009"
[  FAILED  ] testUtString.testStringFormat (0 ms)

Original comment by bsd...@gmail.com on 13 Mar 2011 at 12:17

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Fixed by r859. Thanks for reporting.

Original comment by harkon...@gmail.com on 14 Mar 2011 at 6:57

GoogleCodeExporter commented 9 years ago
Would someone mind reopening this ticket, the portability issues are still 
present, also I have some concern with the fixed sized buffer used and lack of 
error handling.

Original comment by bsd...@gmail.com on 14 Mar 2011 at 11:14

GoogleCodeExporter commented 9 years ago
Okay I reopen this issue.

utStringFormat's internal buffer size is 1024+1.
So, if the longString output is ended with '2', it is mean that internal buffer 
boundary is overwritten.
Otherwise if it is ended '911' or '91', internal buffer is safe. 
If a input string is longer than 1024, it will be cut by buffer size.
But I think, 1024 bytes is enough for one string size. 

Original comment by harkon...@gmail.com on 15 Mar 2011 at 4:13

GoogleCodeExporter commented 9 years ago
Close old issue.

Original comment by harkon...@gmail.com on 21 May 2011 at 4:47