Inline-C-Cookbook might over-simplify passing strings.

[daoswald]

While the example of passing a string to a C function in the Inline-C-Cookbook is not technically inaccurate, it doesn't mention two important gotchas. Certainly it's not our job to inform the user of every way he can get into trouble, I think in this case we could do a little more without becoming nannies.

First: Passing a string that is treated as a char* by C is not useful if the Perl string has been upgraded to Unicode semantics. It is wrong to treat a Unicode string as bytes, and that's exactly what would happen in a naive approach.

In such case that the string has code-points above 255, there could be a suggestion that passing an SV* and using Perl's API for handling the PV would be the safest way short of pulling in a UTF-8 library for C.

The other possible issue is, of course, returning a string. The naive approach from a Perl-user's standpoint is to just return a char*. And if the memory has been allocated for it dynamically, that would probably work, except that it would leak unless some explicit clean-up method is provided. Here, again, a better solution (imho) is to return an SV that has a proper ref count associated with it, and that has been generated using Perl API calls.

Should the Inline-C-Cookbook at least mention that char* strings are not Unicode friendly, and that returning a string should be done with caution?

[mohawk2]

It does sound to me like it should mention that.

[mohawk2]

Done with commit c9d53bae7d954bf8b808fdda6432fed725d42c32.