Has someone encountered similar issues with -cov?

[Patrick Schluter via Digitalmars-d]

On Friday, 1 July 2016 at 20:30:30 UTC, Steven Schveighoffer 
wrote:
> On 7/1/16 4:08 PM, Andrei Alexandrescu wrote:
>> On 7/1/16 2:46 PM, Steven Schveighoffer wrote:
>>> On 7/1/16 2:15 PM, Andrei Alexandrescu wrote:
>>>> On 7/1/16 2:05 PM, Chris wrote:
>>>>> On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu 
>>>>> wrote:
>>>>>> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
>>>>>
>>>>> I fail to see why it should not mark it as uncovered in the 
>>>>> `cube`
>>>>> example. After all the statement is never covered, because 
>>>>> `do`
>>>>> executes
>>>>> before the condition in `while` is checked. Unless you mean 
>>>>> it
>>>>> should be
>>>>> optimized away by the compiler, which in turn has nothing 
>>>>> to do with
>>>>> -cov.
>>>>
>>>> Yah it's a bit subtle. That line is in fact pure 
>>>> punctuation, so even
>>>> though there's no flow through it that's totally fine (as 
>>>> much as you
>>>> wouldn't expect a line with a "}" to show no coverage). -- 
>>>> Andrei
>>>
>>> Suppose one wants to check if you've covered all cases inside 
>>> the while
>>> loop (with breaks or returns). Then, one would WANT to see 0 
>>> coverage
>>> there (non-zero coverage would mean an error in logic).
>>>
>>> To remove that feedback would mess up someone else's use case.
>>
>> This argument is phony. Unconvinced. -- Andrei
>
> I don't use while(0), so I have to invent a hypothetical use 
> case. It's not phony. I could just as easily say that your 
> coding style is illegitimate, and you should use while(true) 
> instead (and thereby get 100% coverage analysis). But I'm not 
> saying that.
>
> There is a legitimate difference between breaking out of the 
> while loop using breaks, and breaking out using the while(0) 
> condition. Why do you want coverage analysis to ignore that 
> difference? Why would someone else's use case that relies on 
> executing or not executing while(0) be invalid?
>
> -Steve

The do {} while(0) "trick" is generally used in C as a poor mans 
scope(exit) construct without using goto. It is to have one point 
where the resources used by a function can be freed without 
duplicating the code everywhere, especially if the function has 
multiple return points. So in practice it is only "useful" on 
complex functions with acquisition of resources (memory, files 
etc) and several exit points (error variants). These kind of 
functions already have difficult execution flows and adding a 
level of obfuscation on top of it is not the right solution. 
Using a goto, while not being the best solution, has at least the 
merrit of providing a searchable and meaningfull label (goto 
error or goto finally or goto cleanup are obvious, break not so 
much) to find the exit. With break it's a little bit more 
difficult. Add loops and switch's to the equation and you're in 
for a very confusing debugging session.