On 07/02/2012 12:53 PM, Isaac Jurado wrote: > On Mon, Jul 2, 2012 at 4:22 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> On 07/02/2012 08:11 AM, Paul Gilmartin wrote: >>> On Jul 2, 2012, at 07:51, Eric Blake wrote: >>>> >>>> ... non-required bloat ... >>>> >>> The key phrase. And one value of a shell lacking such >>> extensions is that it provides an excellent test bed for >>> code intended to be portable within the POSIX spec. >> >> That argues that we should drop our strcasecmp() for the much simpler >> strcmp(), in order to remove the bloat we already have. > > I guess my patch has no chance to be accepted. I'm not the maintainer, so my decision is not indicative of what the dash maintainer will choose. But my personal preference would be that we change this area of code, either to: 1. be lighter-weight (drop strcasecmp, which is locale-dependent, and replace it with strcmp) 2. be more user-friendly (accept optional case-insensitive SIG prefix) Both approaches are permitted by POSIX, so it boils down to a judgment call of whether providing useful extensions or providing a minimally compliant shell is more important. > But I'm still curious > about what kind of "bloat" you are referring to. I'm assuming it's not > code bloat in terms of lines of code. Even one byte larger in the final executable size has been deemed bloat on this list in the past. Dash prides itself on being minimalistic, but you happened to point out an area of code that is not currently minimal. > > If the signal name to number conversion seems too expensive (linear > search multiplied by the string lengths, wether it is case sensitive or > not), there is a much more elegant solution: perfect hashing. Indeed, that would provide faster lookup, but it would also cost more executable size (the storage requirements for a perfect hash table are larger than the size of a loop comparison); I don't know whether the preference is for speed, for minimal size, or for a hybrid of the two (where larger size is okay only if it proves to have more speed). So hopefully the dash maintainer will chime in on the topic. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
