[cairo] [RFC] Color space API (partial proposal)

[Bill Spitzak]

If PDF is unable to accept a nul byte as part of a spot color name, I 
think a const char* is exactly the right api.

Yes "char*" == "byte array" according to the C spec. But as Zack says, 
this is not true in practice. In practice "char* + length parameter" == 
"byte array", while "char*" == "null terminated string".

Jon Cruz wrote:
> On Feb 22, 2010, at 10:21 PM, Zack Weinberg wrote:
> 
>> Jon Cruz <jon at joncruz.org> wrote:
>>> However I'm not sure if "const char*" is really what is best. Such a
>>> declaration in C is really ambiguous and can represent "random byte
>>> data of a separately specified length" in addition to "a string".
>> As long as there is no separate length parameter, everyone will
>> understand a const char* to be a NUL-terminated string.  It should,
>> however, be documented to be UTF-8.
> 
> Not necessarily. Remember that the C paradigm is char* == "byte array". The *name* of the parameter and the in-line documentation can really help.
> 
> 
>> Please do not introduce unnecessary typedefs.
> 
> That's not really what I was thinking. More that in looking over the existing API there are a few places that take something more than a raw pointer. IIRC, a paint might be an appropriate place/type.
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo