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

[Enea Zaffanella]

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-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].

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.
>