Not initialized out argument error

[bearophile via Digitalmars-d]

Thank you for your answers Walter.

>> I have not used SAL so I can't tell. It has nonnull 
>> compile-time
>> tests, and tests of copy or write of the _whole_ span of an
>> array, that look nice and are missing in D.

>I have no idea what that would be 'nice' for, except some 
>optimizations.<

If your function is supposed to initialize or modify every item 
of an array, with that annotation you can express this semantic 
fact (with _Out_writes_all_(s). Such long annotations are created 
concatenating different pieces almost freely). Then if you by 
mistake don't write on all array items (example: because of wrong 
for loop intervals, you have missed the last item), you have 
introduced a bug. If the static analysis is able to catch this, 
you have avoided one bug.


This is an example of code that contains a bug that SAL2 is able 
to spot:
http://msdn.microsoft.com/en-us/library/hh916383.aspx


wchar_t * wmemcpy(
    _Out_writes_all_(count) wchar_t *dest,
    _In_reads_(count) const wchar_t *src,
    size_t count)
{
    size_t i;
    for (i = 0; i <= count; i++) { // BUG: off-by-one error
       dest[i] = src[i];
    }
    return dest;
}


Once the LDC2/GDC2 compilers are able to optimize very well 
range-heavy D code (currently they are not yet at this level, 
this was shown by the recent contest based on the K-Nearest 
Neighbour code, where Rust has shown to optimize Range-like code 
much better than D for still unknown reasons. The Rust community 
has also improved the Rust compiler a bit more on the base of the 
results of that benchmark, unlike us) we can avoid many raw loops 
in D, and avoid such silly off-by-one errors.


>Nor do I think that, in general, such an attribute is 
>mechanically checkable.<

I have not used SAL1/SAL2 so I don't know. I know that verifying 
statically the SAL annotations takes quite more time than 
compiling the program. I have read that SAL is good and it's 
widely used by Microsoft, and it helps catch and avoid a large 
number of bugs for device drivers and similar Windows software. 
And I know SAL2 is the second version of this annotation language 
(so eventual design mistakes of SAL1 are now fixed, and probably 
they have removed useless parts), I know that its designers are 
intelligent and that Microsoft has some of the best computer 
scientists of the world. So I don't know how much SAL2 is able to 
statically check the annotations like this one, but I assume in 
many important cases SAL2 is able to do it.


>The assumption that a .init value is not meaningful is 
>completely arbitrary.<

What I was trying to say is that I think most times you don't 
want and need to return a .init, you want to return something 
different.


>But I don't believe that at all implies that they are equivalent 
>in error-proneness.<

OK, and I agree on this.

I think the D "out" arguments are a bit a failure, they are 
rarely used, and I think returning a tuple (like in Python, 
Haskell, Go, Rust, etc) is usually safer and looks cleaner. So I 
think that once D gets a built-in syntax to manage tuples well, 
the usage of out arguments will become even less common.

Bye,
bearophile