C: A safer way to check buffer in function and append to it?

Question

I have a function of which I need to return the time for another logging function, and it looks like this:

//put time in to buf, format 00:00:00\0
void gettimestr(char buf[9]) {
  if(strlen(buf) != 9) { //experimental error checking
    fprintf(stderr, "Buf appears to be %d bytes and not 9!\n", strlen( buf ));
  }
  time_t cur_time;
  time(&cur_time);
  struct tm *ts = localtime(&cur_time);
  sprintf(buf, "%02d:%02d:%02d",
        ts->tm_hour,
        ts->tm_min,
        ts->tm_sec );
  strncat(buf, "\0", 1);
}

Now I guess the main problem is checking if the buffer is long enough, sizeof() returns a pointer size and strlen seems to randomly return 0 or something such as 12 on two different calls.

My first question is, how would I be able to detect the size of the buffer safely, is it possible?

My other question is, is accepting buf[9] a favourable method or should I accept a pointer to a buffer, and use strcat() instead of sprintf() to append the time to it? sprintf makes it easier for padding zeros to the time values, although it seems to only accept a character array and not a pointer.

Answer 1

Your function assumes that the buffer being passed in already contains a null-terminated string with 9 characters. That doesn't make sense.

The proper way would be to request the size as an argument:

void gettimestr(char *buf, int bufferSize) {

and use snprintf:

snprintf(buf, bufferSize, "%02dx....", ....);<sub>*</sub>

And terminate the string since snprintf won't do that if you exceed the limit:

buf[bufferSize-1] = 0;

You can call your function like this:

char buffer[16];
gettimestr(buffer, sizeof(buffer));

There is no other way to determine the size. This isn't Java where an array knows its size. Passing a char * will simply send a pointer down to the function with no further information, so your only way to get the size of the buffer is by requiring the caller to specify it.

(EDIT: snprintf should always terminate the string properly, as pointed out in the comments.)