[PPL-devel] ppl_io_asprint_* behavior for null pointers?

[Basile STARYNKEVITCH]

Hello All and Roberto & Enea.

May I suggest that all the ppl_io_asprint_* C functions in ppl_c.h & 
libppl_c.so accept a null pointer as the PPL thing?

More precisely, I was expecting
  char* s = 0;
  Polyhedron_t poly= NULL;
  ppl_io_asprint_Polyhedron(&s,poly);
would not crash, but it does crash. I was supposing it would either 
leave s as it was, or fill it will a null pointer, an empty string, or 
eg a string like "{null polyhedron}" or just "*null*". I was not 
expecting it to crash.

Of course, one could imagine that this does not happen. As a case in 
point, under Linux or GNU libc, a printf("%s\n", (char*)NULL); output 
(null). And I know that it "should" crash according to Posix or C 
standard lawyers (IIRC, it did crash under older versions of Sun Solaris).

A simpler for you solution would be to document explicitly that 
ppl_io_asprint_Polyhedron expects a proper Polyhedron_t pointer (not a 
null pointer).
 
The documentation 
http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-c-interface-0.10.2-html/ 
states that

int  	ppl_io_asprint_Polyhedron 
<http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-c-interface-0.10.2-html/interfaceppl__Polyhedron__tag.html#6b5c73b1f3f864c8a10c39810b4711ce> 
(char **strp, ppl_const_Polyhedron_t 
<http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-c-interface-0.10.2-html/group__Datatypes.html#gbc52e1474c4b78458b4c13ddbfdc8e56> 
x)
  	Prints |x| to a malloc-allocated string, a pointer to which is 
returned via |strp|.


You could at least say:
   Prints |x| to a malloc-allocated string, a pointer to which is 
returned via |strp|. Both x and strp should be proper pointers 
(undefined behavior if either is nil).


Selfishly, I would prefer that the documentation explicitly says for 
instance
  Prints |x| to a malloc-allocated string, a pointer to which is 
returned via |strp|. Does nothing if either strp or x is a nil pointer.
or
  Prints |x| to a malloc-allocated string, a pointer to which is 
returned via |strp|. Does nothing if strp is nil. If x is nil, return 
via strp an strdup-ed string duplicating "{null polyhedron}"
and of course that the function behave as documented in the bizarre case 
when strp or x are nil.


Please accept my apologies for using your ppl_io_asprint_Polyhedron 
<http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-c-interface-0.10.2-html/interfaceppl__Polyhedron__tag.html#6b5c73b1f3f864c8a10c39810b4711ce> 
function in such a bizarre situation. I have the habit of initializing 
all my pointers to nil, and I do know (and do code) that 
ppl_Polyhedron_t is a pointer to some opaque structure tagged 
ppl_Polyhedron_tag. 
<http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-c-interface-0.10.2-html/interfaceppl__Polyhedron__tag.html>
BTW, I was suprized to read the tag word in this context in your 
documentation. for me, ppl_Polyhedron_tag is the name (not a tag) of an 
opaque (or private) struct-ure, not its tag : I tend to associate tags 
to discriminated unions,  or to magic like the Tag_hd macro of 
<caml/mlvalues.h>. But I would expect the ppl_Polyhedron_tag identifier 
to stay, since the documentation mentions it! [So for me, a tag is known 
at runtime, while a name is for compile-time].


Still, a very big thanks for PPL. You definitely should be proud of it.

Regards.

PS. Totally unrelated, but you might be interested: J.Pitrat's latest 
book http://www.iste.co.uk/index.php?f=x&ACTION=View&id=257 "Artificial 
Beings - conscience of a conscious machine" ISBN: 97818482211018 explain 
a bit an interesting approach to constraint satisfaction problems. I 
enjoyed reading this book.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***