Re: seperator error in __mask_snprintf_len

From: Joe Korty (joe.korty_at_ccur.com)
Date: 01/12/04

  • Next message: john stultz: "Re: Laptops & CPU frequency"
    Date:	Mon, 12 Jan 2004 17:00:24 -0500
    To: Paul Jackson <pj@sgi.com>
    
    

    On Mon, Jan 12, 2004 at 01:41:12PM -0800, Paul Jackson wrote:
    > A couple of questions on your proposed patch for __mask_snprintf_len()
    > in lib/mask.c:
    >
    > 1) Why make the MASK_CHUNKSZ a possible (compile time) variable?
    > I can think of a couple good reasons why not to:
    > a] So long as we have the current format, in which each word
    > is _not_ zero filled, then the chunk size needs to be a
    > well known constant, or else the output is ambiguous.
    > For example, an output of "1,0" is ambiguous unless we know
    > a priori that the "0" stands for exactly 32, say, bits.
    > b] Even if we change to a zero filled format, better to just
    > always use the same chunk size, as that is one less detail
    > to confuse user level code.
    > I don't see any reason offhand for needing code that works with
    > more than one chunk size.

    MASK_CHUNKSZ is a named constant not a variable. Once we pick a value
    it can never change. The specified legal values are for 1) varying to
    test for algorithmic correctness, and 2) giving the list of values from
    which we must pick the permanent value before too much more time goes by.

    > 2) Why the trailing "buf[len++] = 0"? Won't the last snprintf do
    > as much?

    No. snprintf will fill to the end of the buffer and not place the
    trailing \0 if it has to. (I read the vsnprintf code this morning
    just to make sure of that).

    > 3) This code has quite a bit more detail of bit shifts, masks and
    > arithmetic than before. Perhaps some is necessary to fix the
    > word order bug I had, perhaps some is only needed to allow for
    > the chunk size to vary. I'll take a shot at seeing if I can
    > find a less detail-rich expression of this that still gets the
    > word order correct.

    I am pretty sure the code is within a hairsbreadth of being minimal.
    It will be interesting to find out.

    Regards

    -- 
    "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/
    

  • Next message: john stultz: "Re: Laptops & CPU frequency"

    Relevant Pages

    • Re: kernel.bkbits.net off the air
      ... they could be used to recreate the whole repository in whatever format ... I guess it's just a matter of importing them like patches into arch. ... I did use the CVS gateway before to have a base tree to verify that the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Creating new textbox at run time
      ... But for reasons ... justifiable only to Microsoft, Access doesn't support tif, so that option is ... Please don't advise using some "proprietary" format or a mass market ... > If you'd start with what it is you are trying to accomplish, ...
      (microsoft.public.access.modulesdaovba)
    • Re: Standard definition or HD
      ... HDV is that well-proven and easy to use ... HD format - and it additionally offers the advantage of easy archiving ... but it is not yet easy to edit 24 Mbps AVCHD on modest (and ... its parts) is generally unwise for many reasons, ...
      (rec.video.desktop)
    • Re: logips2pp driver update (MX510/310 support), cleanup
      ... > * also good reasons to use it, ... > * Logitech magic init. ... > * and its exact model and try turning on extended protocol for ones ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Shouldnt kconfig defaults match recommendations in help text?
      ... This particular mismatch occurs because the Kconfig entry ... independent high-level services on top of the low-level ... > be interrested in the reasons why not. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)