Re: serious problems in GDB / LLDB debugger
Re: serious problems in GDB / LLDB debugger
- Subject: Re: serious problems in GDB / LLDB debugger
- From: J <email@hidden>
- Date: Wed, 17 Aug 2011 01:33:07 +0200
you're right. though this function is only accessed in a
single thread, it's a mistake to do this. thanks for pointing it out.
On Aug 17, 2011, at 1:20 AM, Jeffrey Walton wrote:
>> static char txt[256];
> This should be a stack variable, not a static local. Drop the static.
> If you are running threads and two or more enter this operator at the
> same time, you will surely corrupt the resulting string.
>
> On Tue, Aug 16, 2011 at 6:25 PM, J <email@hidden> wrote:
>>
>> hi Lance,
>>
>> Of course you're right, I should've given the code for the << operator on
>> Mat4, here it is:
>>
>> std::ostream & operator << ( std::ostream & s, const Mat4 & v ) {
>> static char txt[256];
>> sprintf( txt, "%g %g %g %g %g %g %g %g %g %g %g %g %g %g %g %g", \
>> v[ 0 ], v[ 1 ], v[ 2 ], v[ 3 ], \
>> v[ 4 ], v[ 5 ], v[ 6 ], v[ 7 ], \
>> v[ 8 ], v[ 9 ], v[ 10 ], v[ 11 ], \
>> v[ 12 ], v[ 13 ], v[ 14 ], v[ 15 ] );
>> s << txt;
>> return s;
>> }
>>
>>
>> On Aug 16, 2011, at 11:48 PM, lbland wrote:
>>
>>
>> The << infix operator doesn't need to print in order of the memory layout?
>> What is the implementation for << in the class?
>>
>> thanks!-
>>
>> -lance
>>
>>
>> Is there anyone who can explain the discrepancy between the left and right
>> panes in the image linked to below ? the right pane - the printed output is
>> the expected output.
>> However, the variables view shows a completely different layout of the
>> values in the
>> matrix, which has a float m_v[16] member which is printed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden