Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #26320

Re: Problem with printf-like logging framework and inline hexdumps.

Show all headers | View raw

On 13-09-12 22:24, Ben Bacarisse wrote:
> Jef Driesen <jefdriesen@hotmail.com.invalid> writes:
> <snip>
>> However, I would like to log some binary data too. Let's say I want to
>> log a message with an inline hexdump, something like this:
>>
>>       "DEBUG: data=<DATA>, size=<SIZE>"
>>
>> Since there is no printf format string available for hexdumps, I could
>> write a little dc_context_hexdump() helper function to convert the
>> binary data into a hex string, and then produce the log message in 3
>> steps:
>>
>>       dc_context_log (context, "%s: data=", "DEBUG");
>>       dc_context_hexdump (context, hexdata, size);
>>       dc_context_log (context, "", size);
>>
>> This would work fine, except that I need the output in only one piece.
>> There are several reasons for that. I simplified the code a bit for this
>> post, but in reality the dc_context_log() function also receives extra
>> info, like the __FILE__ and __LINE__ macros. When printing the output, I
>> only want to see the file and line info appear only once, and not three
>> times. Also in a multithreaded environment, another thread may call the
>> logging function between each of the three calls, and thus interleaving
>> the output.
>>
>> How would you workaround this?
>>
>> A possible approach might be to convert the binary data to string
>> first, and then pass that to the dc_context_log call. Something like
>> this:
>>
>> void
>> somefunction (dc_context_t *context, unsigned char *data, unsigned int
>> size)
>> {
>>       /* Do something useful here. */
>>
>>       /* Log the binary data. */
>>       hexstr = hexdump (data, size);
>>       dc_context_log (context, "%s: data=%s, size=%u",
>>           "DEBUG", hexstr, size);
>> }
>>
>> But this hexdump function isn't thread-safe (because it would have to
>> return a pointer to a static buffer). And even if I would make a
>> re-entrant hexdump_r() version, it's not ideal because then I would have
>> to allocate a buffer inside the somefunction(). I don't want to do that
>> because the dc_context_log is actually called through a macro, which can
>> be configured at compile time to omit the actual call (e.g. in
>> production builds). But then the memory allocation would still be there,
>> and I don't want to pollute application code with #ifdef's. An temporary
>> buffer on the stack won't work either, because the size isn't fixed.
>>
>> Suggestions are welcome!
>
> GCC's printf (well, glibs's printf in fact) allows you to define new
> format specifiers.  Maybe that would suit?

No, because I also need to support non glibc systems (Windows).

> Rolling your own format processing is not that hard.  I'd process the
> format in chunks that bracket your own format codes.  Here's an
> example:
>
>    void logit(const char *fmt, ...)
>    {
>         va_list al;
>         va_start(al, fmt);
>         const char *fp;
>         while ((fp = strstr(fmt, "%H")) != NULL) {
>              char tmp[fp - fmt + 1];
>              memcpy(tmp, fmt, sizeof tmp - 1);
>              tmp[sizeof tmp - 1] = 0;
>              vprintf(tmp, al);
>
>              printf("<%d>", va_arg(al, int));
>
>              fmt = fp + 2;
>         }
>         vprintf(fmt, al);
>         va_end(al);
>    }
>
> Here, a format of %H is treated as if it meant "<%d>" but you can do
> whatever you like at that point (in fact, my use-case called a function
> keyed from the the format letter).
>
> Obviously you'll need a cleverer function to match a custom format.  %H
> should not match after a %, for example, and your formats are likely to
> have counts in them.
>
> I don't think it even breaks any of the rules about handling va_lists.

I also thought of something like this, but the manpages for the vprintf
functions says this on my linux system:

These functions do not call the va_end macro.  Because they invoke the va_arg
macro, the value of ap is undefined after the call. See stdarg(3).

Jef

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-13 18:11 +0200
  Re: Problem with printf-like logging framework and inline hexdumps. "Heinrich Wolf" <invalid@invalid.invalid> - 2012-09-13 18:55 +0200
    Re: Problem with printf-like logging framework and inline hexdumps. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-09-20 17:19 +0000
  Re: Problem with printf-like logging framework and inline hexdumps. Barry Schwarz <schwarzb@dqel.com> - 2012-09-13 11:26 -0700
    Re: Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-14 00:06 +0200
  Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 21:24 +0100
    Re: Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-13 23:47 +0200
      Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 23:54 +0100
        Re: Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-14 18:31 +0200
          Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 22:02 +0100
            Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 22:49 +0100
              Re: Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-17 07:09 +0200
              Re: Problem with printf-like logging framework and inline hexdumps. Kaz Kylheku <kaz@kylheku.com> - 2012-09-17 06:39 +0000
                Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-17 13:30 +0100
      Re: Problem with printf-like logging framework and inline hexdumps. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-14 03:29 -0700
        Re: Problem with printf-like logging framework and inline hexdumps. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 12:01 +0100
  Re: Problem with printf-like logging framework and inline hexdumps. Jef Driesen <jefdriesen@hotmail.com.invalid> - 2012-09-14 22:50 +0200

csiph-web