First, I find the name of the parameter a bit confusing, because it does not control the "parser" mode , but logging, so can eventually be something like sip_parser_log_oneline, log_msg_error_online or something that reflect it is about logging in case of error.

Then, somehow I feel it's opening the door for troubles, as it replaces content inside the incoming buffer. Probably now the logging is like last action done with the buffer content, but the current paradigm is that incoming buffer is not changed.

I would propose to create a more generic solution that can be used even when an error occurs, but it is not last use of the buffer (e.g., processing error, but it is still ok to send a reply or do something else).

My idea right now would be to create a function like:

char *ksr_buf_oneline(char *inbuf, int inlen)
{
   static outbuf[BUF_SIZE];
   int outlen;
   int i = 0;

  if (cfg_get(core, core_cfg, sip_parser_oneline) == 0) {
     return inbuf;
 }

  if(inbuf==NULL) {
    outbuf[0] = '\0';
    return outbuf;
  }

  outlen = (inlen<BUF_SIZE)?inlen:BUF_SIZE-1;
  memcpy(outbuf, inbuf, outlen);
  outbuf[outlen] = '\0';

  for (i = 0; i < outlen;  i++) {
        if(buf[i] == '\r') ...
  }
  return outbuf;
}

Then can be used like:

	LOG(cfg_get(core, core_cfg, sip_parser_log), "ERROR: parse_msg: message=<%.*s>\n",
			(int)msg->len, ZSW(ksr_buf_oneline(msg->buf, (int)msg->len)));

There is a memcpy, but this is expected to be used on error or troubleshooting.

Also, as a side note, you don't need to do strlen(msg->buf), its length is in msg->len field.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.