www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SAL at Microsoft

reply bearophile <bearophileHUGS lycos.com> writes:
It's the first time I read an article that explains the working life at
Microsoft:
http://foredecker.wordpress.com/2011/02/27/working-at-microsoft-day-to-day-coding/

This is one interesting thing:


Windows does have some Windows wide common coding practices. For example, we
use SAL annotations on all our code. This is non-negotiable and you can’t check
your code in unless it has SAL annotations – there are automated tools to check
this. SAL annotations are vitally important; they enable static analysis tools
to perform very deep analysis of native C/C++ code. This is a great bug finding
tool – especially for reliability and security bugs.<



The SAL (Microsoft's standard source code annotation language):
http://msdn.microsoft.com/en-us/library/ms235402%28VS.80%29.aspx

_deref/_deref_opt/_opt: In D I have suggested the   suffix to denote nonnull
pointers/references.

__checkReturn: GCC has a similar annotation, I have suggested something similar
for D too.

__fallthrough: we have discussed something related or better.

__format_string/__callback: interesting, but I don't understand why they are
useful.

_full/_part: seems interesting.

Bye,
bearophile
Feb 27 2011
next sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:


 _deref/_deref_opt/_opt: In D I have suggested the   suffix to denote nonnull
pointers/references.
 
 __checkReturn: GCC has a similar annotation, I have suggested something
similar for D too.


don't contracts do it already?


 __format_string/__callback: interesting, but I don't understand why they are
useful.


format string is effectively a kind of signature, against which arguments can
be typechecked.
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Kagamin:


 _deref/_deref_opt/_opt: In D I have suggested the   suffix to denote nonnull
pointers/references.

 __checkReturn: GCC has a similar annotation, I have suggested something
similar for D too.


 don't contracts do it already?


If you are referring to the _deref/_opt then the nonnull annotations can't be
replaced by contract tests because a contract is more verbose, currently in D
is verified at run-time, and first of all because a nonnull suffix creates a
new type, that's then usable in other parts of the program. A contract tests
just one execution path, a type system tests all possible paths, it's a much
stronger enforcement.

If you __checkReturn then contracts are not able to do it, this has a different
purpose.
It's similar to the "warn_unused_result" function attribute from GCC:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bwarn_005funused_005fresult_007d-attribute-2544

From that page:

The warn_unused_result attribute causes a warning to be emitted if a caller of
the function with this attribute does not use its return value. This is useful
for functions where not checking the result is either a security problem or
always a bug, such as realloc.<


See also:
http://d.puremagic.com/issues/show_bug.cgi?id=3882
http://d.puremagic.com/issues/show_bug.cgi?id=5464

The two main usages of  nodiscard:
- Exceptions are good, but in some situations you want something more
efficient, like a simple error return value.  nodiscard is useful to not ignore
error return values.
- Many functions are not pure but they are useful only for their result,
because their side effects are not important. Phobos is full of such functions.
If you don't use the result of such functions, you usually have a bug.
 nodiscard helps to catch them.
- pure functions are always  nodiscard, no need to add this annotation.



 __format_string/__callback: interesting, but I don't understand why they are
useful.





 format string is effectively a kind of signature, against which arguments can
be typechecked.


Time ago I have opened an enhancement request about that:
http://d.puremagic.com/issues/show_bug.cgi?id=4458

But I don't understand how a __format_string annotation helps here.

If you have code like this:

string f = "%d";
writeln(f, 10);

Adding that annotation (here translated to a D annotation) doesn't help the
compiler much:

 format_string string f = "%d";
writeln(f, 10);

On the other hand if you syntetize the format string (from parts or in another
way) it's not useful still, you can't even add the format string annotation
here:

string p1 = "%";
string p2 = "d";
writeln(p1 ~ p2, 10);

Bye,
bearophile
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
 But I don't understand how a __format_string annotation helps here.
 
 If you have code like this:
 
 string f = "%d";
 writeln(f, 10);
 
 Adding that annotation (here translated to a D annotation) doesn't help the
compiler much:
 
  format_string string f = "%d";
 writeln(f, 10);


There's a bug there, the code needs to be:

 format_string string f = "%d";
writefln(f, 10);

In most cases you don't want to print a format string, so if you write:

 format_string string f = "%d";
writeln(f, 10);

The compiler is probably able to show a warning, that says that you are using a
format string as first argument of a printing function that doesn't use a
format string :-) And this warning is enough to catch that bug.

Bye,
bearophile
Feb 28 2011
next sibling parent Kagamin <spam here.lot> writes:
bearophile Wrote:


 In most cases you don't want to print a format string, so if you write:
 
  format_string string f = "%d";
 writeln(f, 10);
 
 The compiler is probably able to show a warning, that says that you are using
a format string as first argument of a printing function that doesn't use a
format string :-) And this warning is enough to catch that bug.
 


In most cases you just throw format string wherever it goes without annotations
:)
What you want can be dealt with a usual struct wrapper aka strong typedef.

To catch bug with argument types you need to pass string literal directly to
the format parameter.
Feb 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 But I don't understand how a __format_string annotation helps here.

 If you have code like this:

 string f = "%d";
 writeln(f, 10);

 Adding that annotation (here translated to a D annotation) doesn't help the
compiler much:

  format_string string f = "%d";
 writeln(f, 10);


 
 There's a bug there, the code needs to be:
 
  format_string string f = "%d";
 writefln(f, 10);
 
 In most cases you don't want to print a format string, so if you write:
 
  format_string string f = "%d";
 writeln(f, 10);
 
 The compiler is probably able to show a warning, that says that you are using
a format string as first argument of a printing function that doesn't use a
format string :-) And this warning is enough to catch that bug.



Won't implement, see rationale
http://d.puremagic.com/issues/show_bug.cgi?id=4458#c6
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Won't implement, see rationale
http://d.puremagic.com/issues/show_bug.cgi?id=4458#c6


In the same place I have written good answers to your problems.

bearophile
Feb 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 Walter:
 

 Won't implement, see rationale
http://d.puremagic.com/issues/show_bug.cgi?id=4458#c6


 
 In the same place I have written good answers to your problems.


There's no technical reason why writef should be slower than printf, adding 
language features to compensate is the wrong way to fix that.

Similarly, template bloat is a language implementation issue that needs 
eventually to be addressed. Having a kludgy language feature that only
addresses 
printf is the wrong fix.

As for the rest, having specific compiler support for printf makes for sad 
sister support for anything else.
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Similarly, template bloat is a language implementation issue that needs 
 eventually to be addressed. Having a kludgy language feature that only
addresses 
 printf is the wrong fix.


I don't think you will find a magic solution to remove the problem of template
bloat.
In past I have shown you three very different ideas to reduce template bloat.
Just hoping in a better future is not enough. Like with cancer probably there
is no single solution to remove template bloat, you have to attack this problem
from many sides at the same time, and one of the sides is to not produce bloat
when possible, in some different ways.



 As for the rest, having specific compiler support for printf makes for sad 
 sister support for anything else.


Good "pluggable type systems" are a general solution usable for many other
purposes too, not just for printing functions. What's good of them is that you
don't need to modify the front-end because they are implemented in user code,
and you are able to restrict them to parts of a program or to just a program,
so they become problem-specific and don't make the language more complex for
all D software projects.

There are many ways to implement pluggable type systems. User annotations plus
static introspection are a possible syntax to define them. Time ago I have
discussed about a variable known at compile-time that's similar to the
__builtin_constant_p() of GCC (http://www.delorie.com/gnu/docs/gcc/gcc_81.html
), but to be good enough this has to work with libraries too even when you are
not using whole-program optimization (unlike __builtin_constant_p).

Even if you refuse to add this static tests to the printing functions, like
they are missing in C and present in both GCC/Clang and Microsoft static tools,
plus most C lints, they will be done by future D compilers or D lints. LDC is
possibly going to add this static test.

Bye,
bearophile
Feb 28 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 08:59 PM, bearophile wrote:

 I don't think you will find a magic solution to remove the problem of template
bloat.
 In past I have shown you three very different ideas to reduce template bloat.
Just hoping in a better future is not enough. Like with cancer probably there
is no single solution to remove template bloat, you have to attack this problem
from many sides at the same time, and one of the sides is to not produce bloat
when p


Language design meets ecology...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:


 Language design meets ecology...


A feature that's good in Python may be bad in D, or not having a feature in
Python may be bad, while missing it in D may be good. When you judge how much
good a language feature is, you must take a look at how the feature interacts
with all the other features of a language. Well designed languages have most of
their features well co-adapted to each other. The features of a language
interact with each other like species in a biota. Ecology is one of the topics
I have studied, and it's useful for quite more than just biology. Today ecology
is very important for medicine too (evolution of virulence), to understand and
fight cancer (cancer cells are alive and different, they create a different
ecosystem that's egoistical in a different way, etc).

To design a language you need some sociological thinking too beside ecology,
because the community of people that use a language are almost as important as
the language grammar rules.

Bye,
bearophile
Feb 28 2011
parent spir <denis.spir gmail.com> writes:
On 02/28/2011 09:50 PM, bearophile wrote:

 spir:


 Language design meets ecology...


 A feature that's good in Python may be bad in D, or not having a feature in
Python may be bad, while missing it in D may be good. When you judge how much
good a language feature is, you must take a look at how the feature interacts
with all the other features of a language. Well designed languages have most of
their features well co-adapted to each other. The features of a language
interact with each other like species in a biota. Ecology is one of the topics
I have studied, and it's useful for quite more than just biology. Today ecology
is very important for medicine too (evolution of virulence), to understand and
fight cancer (cancer cells are alive and different, they create a different
ecosystem that's egoistical in a different way, etc).

 To design a language you need some sociological thinking too beside ecology,
because the community of people that use a language are almost as important as
the language grammar rules.


Same about systemics.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 28 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
In many cases the format string is known at compile-time, so I am even able to
create a function like this, that performs library-defined compile-time tests
on the format string:

putfnl!"Data: %d %f"(10, 1.5);

Bye,
bearophile
Feb 28 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
 Good "pluggable type systems" are a general solution usable for many other
purposes too,


I guess you don't like this, right? If I ask you a special-purpose solution for
just printing functions, you answer me that it's a wired solution, etc. If I
answer with a more general solution like pluggable type systems, you think it's
too much work to implement, etc. So there's no way out.

Bye,
bearophile
Feb 28 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 So there's no way out.


Just accept the few kilobytes of unbearable bloat and use writef, or
write the necessary code yourself so all the burden isn't on Walter.
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 Just accept the few kilobytes of unbearable bloat and use writef,


It's not just template bloat, but also the printing bugs not caught at compile
time.
The point of the first post of this thread was to talk about SAL, that
Microsoft seems to consider very important. I think this part was missed,
focusing only a little part of the whole.



 or write the necessary code yourself so all the burden isn't on Walter.


I am able to write a printing template that takes the format as template
argument, and then tests it and calls writef/writetefln. It will take some more
years to be good enough to write a whole compiler for a sizeable language.

Bye,
bearophile
Feb 28 2011
parent Don <nospam nospam.com> writes:
bearophile wrote:

 Adam Ruppe:
 

 Just accept the few kilobytes of unbearable bloat and use writef,


 
 It's not just template bloat, but also the printing bugs not caught at compile
time.
 The point of the first post of this thread was to talk about SAL, that
Microsoft seems to consider very important. I think this part was missed,
focusing only a little part of the whole.


You completely missed the point, I think, bearophile. D is not C.

It is an important C bug. No doubt about that. And it's such a common, 
hard to diagnose bug that they have put a massive hack into the compiler 
to detect it. Make no mistake, that's what it is: it's a hack. A really 
ugly one.

It is not an important D bug. writef doesn't have the problems that 
printf does. The ugly hack is not justified.
Mar 01 2011