Edit: In fact, you must need the declaration to access the internals.
It's on github. Post a pull request or keep it to yourself. Especially as your comments are stylistic.
I'm surprised about the possibility of misunderstanding.
BTW, the code is 'open source' and copyrighted: I have found no license to use it freely.
(As one other reply has put it, "constructive criticism".
In this case, the great-grandparent is free to reflect upon the g.p response, or not, depending upon their inclination and time. Perhaps it sparks further refinement; perhaps not. But I don't see it as being personally critical; to reiterate, it offers a perspective of possible refinement.
In the past some months, I've noticed the tone of comments on HN becoming more "emotional". That, I believe, is a slippery slope for the community. HN seems to function best when we all exercise emotional restraint, along with our technical and professional enthusiasm.
With regard, and hopefully not "calling out" the parent too much (or at all) in what I have taken primarily as an opportunity to make a more general comment.
- _MxStringBuffer need not be defined in the header, a forward declaration would be sufficient (a.k.a. encapsulation).
- the two #defines can be removed form the header, too.
- I wouldn't try to typedef away a pointer (as in typedef struct _MxStringBuffer * MxStringBufferRef) but either use the pointer (MxStringBuffer* ) or create a handle: struct MxHandleStringBuffer { _MxStringBuffer * impl; };