Date: Thu, 15 Jan 2004 19:48:07 -0500
From: Joe Korty <joe.korty@ccur.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, paulus@samba.org, linux-kernel@vger.kernel.org
Subject: Re: seperator error in __mask_snprintf_len
Message-ID: <20040116004807.GA32289@tsunami.ccur.com>
Reply-To: joe.korty@ccur.com
References: <20040108051111.4ae36b58.pj@sgi.com> <16381.57040.576175.977969@cargo.ozlabs.ibm.com> <20040108225929.GA24089@tsunami.ccur.com> <16381.61618.275775.487768@cargo.ozlabs.ibm.com> <20040114150331.02220d4d.pj@sgi.com> <20040115002703.GA20971@tsunami.ccur.com> <20040114204009.3dc4c225.pj@sgi.com> <20040115081533.63c61d7f.akpm@osdl.org> <20040115181525.GA31086@tsunami.ccur.com> <20040115161732.458159f5.pj@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040115161732.458159f5.pj@sgi.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2370
Lines: 62

On Thu, Jan 15, 2004 at 04:17:32PM -0800, Paul Jackson wrote:
> > This patch captures what I am looking for in bitmap display and input.
> 
> Interesting.  I appear to have provoked Joe into a burst of coding.
> Now, if I had any smarts, I would stand aside and let Joe own this,
> just as Bill Irwin did when I posted my initial lib/mask.c patch a
> couple months ago.

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


>     If you find Joe's coding more to your liking than my "Gad" style,
>     I will bless this, and after tossing in a few parting shots, will
>     stand aside.  It meets my essential needs, which were:

I like the output parser but am not too happy with the input parser.
I would prefer that the commas on input be optional, and when present
silently skipped over.  That would greatly simplify the code and has
the added benefit that masks generated by programs (which by default
have no commas) be feedable to the parser, while still supporting
the human readable form for input.


>>  o bitmap size resolution changed from byte to bit
> 
>   Why?  This adds a fair bit of complexity to the code, I suspect.
>   I am not aware of a need for this, but if there is one, ok.

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.

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.  The fact that bitmasks are
encoded in unsigned longs is entirely an internal bitmask.h affair.


>   So a space embedded in a hex number is skipped?  That is, your code
>   parses "dead,beef" and "de a d, bee  f" the same?  This seems strange.
>   Perhaps you would prefer to suppress only leading spaces in each chunk:
> 
> 			if (!n && isspace(c))
> 				continue;

Yes, this would be better.

>> +			for (j = 0; j < 32; j++) {
>   What's this "32", an unrepentant CHUNKSZ?

Oops.  Thanks, good catch.

-- 
"Money can buy bandwidth, but latency is forever" -- John Mashey
Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/