<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I suppose there are situations where
the actual code for a function is based on preprocessor defines while we
want the type specs to encompass all possible implementations.</font>
<br>
<br><font size=2 face="sans-serif">A simple example could be a debug mode
which is to be enabled/disabled at build time:</font>
<br>
<br><font size=2 face="sans-serif">"""</font>
<br><font size=2 face="sans-serif">-module(foo).</font>
<br>
<br><font size=2 face="sans-serif">-export( [is_debug_mode_enabled/0]).</font>
<br>
<br><font size=2 face="sans-serif"> -spec is_debug_mode_enabled()
-> boolean().</font>
<br>
<br><font size=2 face="sans-serif"> -ifdef(debug_mode_is_enabled).</font>
<br>
<br><font size=2 face="sans-serif"> is_debug_mode_enabled() -></font>
<br><font size=2 face="sans-serif"> true.</font>
<br>
<br><font size=2 face="sans-serif"> -else.</font>
<br>
<br><font size=2 face="sans-serif"> is_debug_mode_enabled() -></font>
<br><font size=2 face="sans-serif"> false.</font>
<br>
<br><font size=2 face="sans-serif">-endif.</font>
<br><font size=2 face="sans-serif">"""</font>
<br>
<br><font size=2 face="sans-serif">(another example could be the use of
a random source based on crypto - if available, otherwise on the built-in
source)</font>
<br>
<br><font size=2 face="sans-serif">Dialyzer is right when telling that
"is_debug_mode_enabled/0 states that the function might also return
'false' but the inferred return is 'true'" (when the symbol debug_mode_is_enabled
is defined) , but I would like to be able to suppress this warning as the
same code built with a different preprocessor flag should offer the same
API/type spec to the user code.</font>
<br>
<br><font size=2 face="sans-serif">Of course I could define instead:</font>
<br>
<br><font size=2 face="sans-serif">"""</font>
<br><font size=2 face="sans-serif"> -ifdef(debug_mode_is_enabled).</font>
<br>
<br><font size=2 face="sans-serif">-spec is_debug_mode_enabled() ->
true.</font>
<br><font size=2 face="sans-serif"> is_debug_mode_enabled() -></font>
<br><font size=2 face="sans-serif"> true.</font>
<br>
<br><font size=2 face="sans-serif"> -else.</font>
<br>
<br><font size=2 face="sans-serif">-spec is_debug_mode_enabled() ->
false.</font>
<br><font size=2 face="sans-serif"> is_debug_mode_enabled() -></font>
<br><font size=2 face="sans-serif"> false.</font>
<br>
<br><font size=2 face="sans-serif">-endif.</font>
<br><font size=2 face="sans-serif">"""</font>
<br>
<br><font size=2 face="sans-serif">but then, I think it would not really
solve the problem as I suppose that Dialyzer would similarly complain then
in the user code relying on these functions, like in:</font>
<br>
<br><font size=2 face="sans-serif">"""</font>
<br><font size=2 face="sans-serif">-module(bar).</font>
<br><font size=2 face="sans-serif">-spec f() -> boolean()</font>
<br><font size=2 face="sans-serif">f() -></font>
<br><font size=2 face="sans-serif"> foo:is_debug_mode_enabled().</font>
<br><font size=2 face="sans-serif">"""</font>
<br>
<br><font size=2 face="sans-serif">(the problem would then be transferred
from foo to bar and all other places making use of foo)</font>
<br>
<br><font size=2 face="sans-serif">Am I missing something? Is there a way
to tell Dialyzer to ignore *for this particular function* the "underspecification"?
</font>
<br><font size=2 face="sans-serif">If not, maybe making Dialyzer support
Valgrind-like suppression files could help?</font>
<br>
<br><font size=2 face="sans-serif">Thanks in advance for any hint,</font>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">Olivier.</font>
<br><font size=2 face="sans-serif">---------------------------<br>
Olivier Boudeville<br>
<br>
EDF R&D : 1, avenue du Général de Gaulle, 92140 Clamart, France<br>
Département SINETICS, groupe ASICS (I2A), bureau B-226<br>
Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47
65 27 13</font><font face="monospace"><br>
<br>
<br>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.<br>
<br>
Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.<br>
<br>
Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.<br>
____________________________________________________<br>
<br>
This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.<br>
<br>
If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.<br>
<br>
E-mail communication cannot be guaranteed to be timely secure, error or virus-free.</font>