Basile STARYNKEVITCH wrote:
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).
Hello Basile.
Under my point of view, the ppl_io_asprint_* functions are similar to all the other functions taking as input (an opaque pointer to) a PPL object. Hence, they require that such an input parameter refers to a properly initialized PPL object (in principle, these pointers are meant to model C++ references). Anyway, you are right in noting that such a requirement is not mentioned in the C interface documentation: I will try and correct it.
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].
Strictly speaking, we were considering these opaque structures "so" private that the user should not even be concerned about knowing their names. However, when documenting the public interface with Doxygen, I wasn't able to use the typedef name ppl_Polyhedron_t as a container for the related functions ... as a workaround, I ended up abusing the Doxygen concept of "interface" for the ppl_Polyhedron_tag identifier. This had the undesired side-effect of making these names appear in the user documentation. I know this is suboptimal ... but I still haven't found a better solution.
Cheers, Enea.
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.