To be consistent between allocation and reallocation (like malloc() and realloc()).

And you still want to access the old value if reallocation failed.

> To be consistent between allocation and reallocation (like malloc() and realloc()).

Consistency is a tool that is often useful to promote program correctness. You're suggesting using it to accomplish the reverse.

If it's important aesthetically that all sds operations be consistent in this regard, you can structure the allocation interface in the same way:

  sdserror sdsnew(sds*);

  sds mystring = NULL;
  sdsnew(&mystring, "Hello World!");

This is a common practice in relatively new interfaces like pthread_create.

> And you still want to access the old value if reallocation failed.

If you want to provide commit-or-rollback semantics, you could signal error via return value rather than by replacing s with NULL:

  if (sdscat(&s,"Some more data") != SDS_SUCCESS) {
    /* failure path; s is unchanged */
  } else {
    /* s now has "Some more data in it" */
  }

but this may be completely useless, depending on the environment(s) in which the library or program is intended to be used. On 64-bit Linux systems with memory overcommit enabled (the default), this failure path essentially shouldn't ever happen. Instead, some process (maybe yours, maybe not) will be picked by the kernel OOM killer. Many programs just use an allocate-or-die interface, as the sds README mentions.

You're right, I wasn't saying that it's the only way to write allocation/assignment. I was saying that in that case sdscat() matches with sdsnew() style.

To be fair, the library already assigns returns from realloc in such a way that you cannot retrieve the old data if realloc failed.

Not nice I know.