Re: seperator error in __mask_snprintf_len

[Paul Jackson <pj@sgi.com>]

Joe wrote:
> I would prefer that we provoke each other until Andrew finds something
> that he likes:)

Drat ;).  Perhaps Andrew will elaborate on his "gad", and I will have
some clue of whether it is worth responding with another variant.
Clearly something in my last patch looked ugly to him.


> I would prefer that the commas on input be optional, and when present
> silently skipped over.

This wasn't an option before, in my variations that didn't zero-fill each
chunk.  But with your zero-fill, which I agree is better, this is possible.

Not a bad idea.  Another instance of Postel's Prescription:

   Be liberal in what you accept, and conservative in what you send.
     http://www.postel.org/postel.html
   Referenced in: Basics of the Unix Philosophy
     http://www.faqs.org/docs/artu/ch01s06.html

Though possibly a violation of the Rule of Composition:

   Design programs to be connected to other programs.

If commas are optional on input, then a user level program that
generates such masks could not always feed them to another user level
program that reads them.  The reader might require exact comma placement
that the producer didn't provide.

Since the primary "documentation" for this format will be what is
displayed when someone does "cat /proc/irq/prof_cpu_mask", I rather
think that the design format should be exactly what displays here,
including exact comma separation, both displaying and parsing.


> I think it important that we display exactly what the bitmask represents,
> no more and no less.  This is a philosophical point, to be sure.

Purely philosophical, as best as I can tell.  All the other bitmask
stuff works on objects that are some number of words in size.  I see no
use whatsoever for this additional complexity.

Unless you can show me a need for this, I think it is overdesign.


> In any case I think we should not have the display change from one
> machine to the next, simply because the size of the underlying
> 'unsigned long' changed underneath us.

Huh?  I am unware that my code displays differently depending on whether
the underling "unsigned long" is 4 or 8 bytes.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373