API should use void*, not char*, for binary data about open-vcdiff

[Steelskin]

Summary of old comments:

Thanks much for your interest in open-vcdiff, and for sharing your feedback.

I think the use of const char* versus const void* is debatable.

Passing a const char* for dictionary_contents specifies unambiguously the units in which dictionary_size is expressed: the dictionary contains dictionary_size char values (bytes.) One of my colleagues pointed out that this has the advantage that a pointer to the end of the dictionary can be found by calculating dictionary_contents + dictionary_size; such a calculation would not work with a void* and would require an explicit cast.

On the other hand, standard functions such as memcmp and memcpy take void* arguments to represent pointers to contiguous bytes. The existence of those interfaces supports your position.

As another reference point from the compression milieu, zlib uses Bytef* for its input and output, which is a typedef for unsigned char*.

Would anyone else care to offer an opinion on this issue?

Answer:

• The type 'size_t' already unambiguously denotes a byte count.
• Your point about offsetting from the dictionary pointer relates to the library implementation; but the design of an API should give the convenience of clients higher priority (unless it would severely penalize the implementation, of course.) So I don't think it's a good balance to require clients to cast the pointers, just to save a few casts in the implementation. [Also, FYI, gcc allows pointer arithmetic on void* for exactly this reason.]

My personal opinion is that the API should be changed to use void*

[bacek]

Just my $0.02: I prefer uint8_t* for byte buffers.