[cairo] [RFC] Color space API (partial proposal)
spitzak at gmail.com
Tue Feb 23 11:37:13 PST 2010
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
More information about the cairo