On 09 May 2013, at 14:39, Bruce Tulloch wrote: > Thanks José, I can see that might cause a problem given bar passes result > by reference to foo without initializing result first. My question to Jonas > or others more knowledgeable than me about what the compiler does, is > whether result (in your example and my own case) is guaranteed to be > initialized to nil when it first appears in scope (i.e. before it's been > assigned any value in our code).
Every instance of an automated type, whether it was explicitly declared or implicitly created as a temp, initially gets the value "nil". However, as Michael and Ludo explained, the "result" variable of a function returning an ansistring/unicodestring is not created inside that function itself. The compiler turns such functions into procedures with an implicit var-parameter and the *caller* passes the location where the function result should go via that parameter. This location can be a temporary location, but the compiler can also optimize this by directly passing the location of the variable to which you assign the result of that function call. Such optimizations only occur in safe situations (e.g., not when assigning to a global variable, because otherwise assigning something to the function result would immediately change the value of that global variable too), but as Ludo explains this means that you are looking in the wrong place for the data race. So you are probably writing in two threads to whatever you are assigning the result of that function to. Jonas_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
