Re: Extension to snprintb(3)

[christos%astron.com@localhost (Christos Zoulas)]

In article <Pine.NEB.4.64.0905041512450.11316%quicky.whooppee.com@localhost>,
Paul Goyette  <paul%whooppee.com@localhost> wrote:
>On Mon, 4 May 2009, Christos Zoulas wrote:
>
>>> I propose a modified version of snprintb(3) which fills its output
>>> buffer only with complete bit/field values.  In addition to the current
>>> return value, this modified version would take an additional u_quad_t
>>> argument which would be set to the bit(s) that were NOT decoded in the
>>> current output.  This would allow one to repeatedly call the new
>>> function, with a fixed-sized buffer, until all bits were decoded, and
>>> would result in output lines that were reasonably equal in length.
>>>
>>> Is this a reasonable idea?  Any suggestion on what this new function
>>> should be called?
>>>
>>> int snprintbx(char *buf, size_t buflen, const char *fmt, u_quad_t *val);
>>
>> Sounds ok to me.
>
>Well,this turns out to be fairly easy for the "old format" control 
>strings in snprintb(3), but it doesn't work well with "new format" 
>strings with field specifications.  In particular, it's just about 
>impossible to "remember" that you've already processed the first field 
>from
>
>     ctl = "\177\20b\0B0\0b\1B1\0F\2\1fld\0=\0ZERO\0=\1ONE\0b\4B4\0"
>
>since it is entirely acceptable for the 2-bit field to have a value of 
>zero.
>
>
>For my immediate needs (the features* strings in cpuctl), old format is 
>more than adequate.  Is this worthwhile doing only for the old format? 
>Or should I just accept the ugliness of snprintb(3)?

Well, it is easy to do for the new format too. Instead of doing it in
multiple calls, pass the maximum length in the call, and have snprintb
insert newlines, or make it return an array of allocated buffers.

christos