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 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
prev sibling next sibling parent 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
prev sibling 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