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-ht... 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} ***