biggest... check-in... ever...

Christopher Faylor cgf@redhat.com
Tue Sep 23 14:41:00 GMT 2003


On Tue, Sep 23, 2003 at 04:32:34PM +0200, Corinna Vinschen wrote:
>On Tue, Sep 23, 2003 at 10:01:14AM -0400, Christopher Faylor wrote:
>> On Tue, Sep 23, 2003 at 11:47:30AM +0200, Corinna Vinschen wrote:
>> >There's still the naming of the harddisk devices which is different
>> >from what they are named before.  They should be named /dev/sd.., 
>> >not /dev/hd..
>> 
>> I haven't forgotten about this.  It's on my todo.  It falls under the
>> "some things will be broken".
>
>Fair enough.
>
>> >  Wouldn't a binary array search be better
>> >for this?  It would drop the need to use gperf, btw.
>> 
>> If you can find some kind of binary tree compiler similar to gperf,
>> I'll certainly consider it.
>
>Actually I meant a binary search in an array, not a binary tree.
>How big is the speed advantage of a fairly elaborate solution as
>a hash over a simple sorted array with respect to devices?  The
>array would be created from the same dataset you're already defining
>in devices.gperf, it would just have to be always sorted.

The hash isn't that elaborate.  It is just a few instructions, to find
the hash and then a strcmp to verify it.

If I understand you correctly, the kind of tree walk that you're talking
about requires multiple strcmps.  The parser is trying to be quick in
the normal case, which is in rejecting something like /dev/console.

>Talking about binary trees, isn't gperf also able to create binary
>trees?  [dig, dig, dig] The man page talks about using the -S option
>with a very big number so that it creates a binary search using
>switch statements.  Sort of a binary tree statementwise...  Hmm...

It's still a hash, AFAIK.

cgf



More information about the Cygwin-developers mailing list