<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
(french translation afterwards)<br>
<br>
In my experience, most of the bugs comes from a call on NULL.<br>
(I'm writing this because I found a call on NULL in the compiler)<br>
<br>
Now, ideally, a good programmer should write contracts like this:<br>
<br>
<tt> - my_slot arg2:TYPE keyword arg2:TYPE :TYPE <-<br>
[<br>
</tt><tt> -? {arg1 != NULL};<br>
</tt><tt> -? {arg2 != NULL};<br>
</tt><tt> ]<br>
(<br>
... // Implementation<br>
)<br>
[<br>
+? { Result != NULL };<br>
];<br>
<br>
</tt>But now, in this ideal world, we add good programmers.<br>
By definition, good programmers are lazy.<br>
And good programmers don't want to write these contracts each time they
define a slot for the first time (thankfully, assertions are inherited).<br>
<br>
So, instead of crashing on an assertion (the closest to the error) we
crash on the call on NULL.<br>
<br>
<br>
Now, Bertrang Meyer's version of Eiffel have something to avoid calls
on NULL:<br>
<a class="moz-txt-link-freetext" href="http://bertrandmeyer.com/2009/08/04/void-safety-getting-rid-of-the-spectre-of-null-pointer-dereferencing/">http://bertrandmeyer.com/2009/08/04/void-safety-getting-rid-of-the-spectre-of-null-pointer-dereferencing/</a><br>
<a class="moz-txt-link-freetext" href="http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf">http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf</a><br>
<br>
<br>
We could also imagine something that will automatically write contracts
to check NULL values.<br>
Here I see two problems:<br>
<ul>
<li>if we create an external tool that rewrite the source code, how
do you tell where to check for NULL and where NULl might be legitimate</li>
<li>if it is included in the Lisaac compiler, how to make it work
(the ?{} construction is implemented in the library)</li>
</ul>
<br>
<br>
<br>
Now, do you have any ideas?<br>
<br>
<hr size="2" width="100%"><br>
Dans mon expérience, la plupart des bugs sont causés par des appels sur
NULL (call on NULL)<br>
(j'en parle maintenant parce que j'ai justement un call on NULL dans le
compilateur)<br>
<br>
Idéalement, un programmeur devrait écrire:<br>
<br>
<tt> - my_slot arg2:TYPE keyword arg2:TYPE :TYPE <-<br>
[<br>
</tt><tt> -? {arg1 != NULL};<br>
</tt><tt> -? {arg2 != NULL};<br>
</tt><tt> ]<br>
(<br>
... // Implementation<br>
)<br>
[<br>
+? { Result != NULL };<br>
];<br>
<br>
</tt>Dans ce monde idéal, ajouton de bons programmeurs<br>
Les bons programmeurs par définition sont fainéants<br>
Donc, un bon programmeur n'écrire pas ces contrats à chaque fois qu'ils
définissent un nouveau slot (heureusement, les contrats sont hérités).<br>
<br>
Au lieu de planter sur une assertion (au plus près de l'erreur), on
plante donc sur un appel sur NULL.<br>
<br>
<br>
La version d'Eiffel de Bertrand Meyer a corrigé ce problème pour éviter
tout appel sur NULL:<br>
<a class="moz-txt-link-freetext" href="http://bertrandmeyer.com/2009/08/04/void-safety-getting-rid-of-the-spectre-of-null-pointer-dereferencing/">http://bertrandmeyer.com/2009/08/04/void-safety-getting-rid-of-the-spectre-of-null-pointer-dereferencing/</a><br>
<a class="moz-txt-link-freetext" href="http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf">http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf</a><br>
<br>
<br>
On peut imaginer quelque chose dans le même goût, ou on pourrait
imaginer quelque chose qui écrirait ces contrats à notre place pour
vérifier les valeurs NULL. Mais je vois deux problèmes:<br>
<ul>
<li>Si on crée un outil extérieur qui va réécrire le code source,
comment savoir où placer ces contrats (et où les valeurs NULL sont
légitimes)?</li>
<li>Si c'est inclus dans le compilateur, je vois mal comment faire,
sachant que la construction ?{} est implémentée en lib.<br>
</li>
</ul>
Maintenant, avez vous des idées ?<br>
<br>
Mildred<br>
<pre class="moz-signature" cols="72">--
Mildred Ki'Lya
╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
│ Jabber, GoogleTalk: <a class="moz-txt-link-rfc2396E" href="mailto:mildred@jabber.fr"><mildred@jabber.fr></a>
│ Website: <a class="moz-txt-link-rfc2396E" href="http://ki.lya.online.fr"><http://ki.lya.online.fr></a> GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
</pre>
</body>
</html>