Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Outputing of string without EOL-marker is possible _only_ at next read iteration
of output buffer of working process. But process can be aborted earlier than
it will be done.
Fixed in r21757.
What do you mean by "aborting" the process? If the process is aborted by the user explicitly, that means they don't need the output.
Workflow into a read iteration:
1. Abort-flag == true ? break : ;
2. read buffer
3. output terminated substrings (with EOL)
4. possible output unterminated string (without EOL)
Before bug's fixing step 4 is impossible at the current read iteration but possible _only_ at the next read iteration. And you can see that the read iteration begins with the Abort-check.
Expression "possible output" in the step 4 does not related to abort of the process.
Thanks for explaining how the loop works. However that is not the answer to my question, please reread it. I will try with another one with a hope of better understanding:
Is the problem you fix something that may happen to the user? In what conditions? Could you provide steps to reproduce the problem? I'll repeat: if the user aborts the process using the Stop button, he doesn't want the full output. I'm interested in what kind of "abort" you fix here.
I am not sure if the way the problem is fixed is correct, but first I would like to know what we are fixing.
Most possible this problem will never happen to the user.
If it happens then most serious consequence, which user can have, is that he does not see the last string in the Console when he has aborted working process and the last string is unterminated.
"Last string" is the current string, which the Console has been outputing when user aborts the process.
And I fixed no aborts.
If we are unable to reproduce the error and it affects only manual process abortion, I think we can skip this workaround. Alan, what's your opinion?