Re: [PATCH 4/7] parse_color: refactor color storage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> The result is also slightly less efficient to store, but
> that's OK; we only store this intermediate state during the
> parse, after which we write out the actual ANSI bytes.

You need up to 24 bits for the value and then 2 bits for what type
of color specification you have (what you called "state"), for which
32-bit should be sufficient.  That would mean it is more efficient
than a single int on 64-bit archs, and you can arrange the struct
to be packed if we ever need to keep dozens of these things.  Until
then, the updated simple struct is just fine, and either way it is
much easier to read ;-)

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]