[Top][All Lists]

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

Re: [Gnu-arch-users] Increasing the filename space (Or: begging for trou

From: Christian Thäter
Subject: Re: [Gnu-arch-users] Increasing the filename space (Or: begging for trouble?)
Date: Wed, 4 Feb 2004 01:23:23 +0100

>     >   file/patch lists, this lists might be '--escaped' if one
> That should be the default.

so is it. the option will be '--unescaped'.

> Great.   Much more useful would be a document specifying the encoding.

My reference uses standard C encoding, a tab becomes '\t' (and so with other 
character escapes). '\040' and '\ ' are recognized as space, but always written 
as '\40', unicode can be escaped as \u.. and \U.. 

rationale for the C escaping was that shell will handle it without any 
additional translation and shell is probably the most used language to parse 
tla output.

I do not want to join any upcoming debate which encoding scheme might be the 
best. Either you define it or the community discusses about it. I simply don't 
want to care. The reference gets C escaping because it already exists and I 
will wait until we have a *final* decision and then add it.

>     > 6) the escaping engine is table driven, by default it currently
>     > uses a brute-force search which is somewhere at O(N*M). 
> Something seems to have gone fairly well wrong, then -- but at least
> captured behind one of you internal abstraction barriers.

this default is only meant for testing, but the table is small and it might 
still be fast enough. A brute-force search is just the one which can be safely 
implemented in 10 minutes, thats why it's there currently.

>     > The lookup strategy can be changed. For static defined tables like
>     > in tla, it would be nice to create a pefect hash at compiletime
>     > to make it much faster. 
> Alternatively, choose a better syntax that doesn't create the problem
> you're trying to solve.

i kept the syntax simple on cost of processing, the user can provide a quite 
simple, unordered table of escapes ans associated parsers and few flags. Idea 
behind that is that the table should be easy to maintain. 

> Actually -- I have a syntax that I'd prefer:  the one that's shaping
> up for Pika Scheme which would permit either...

can be done. see above

> An interesting exercise but I'm not sure why one would want such a
> thing for the problem at hand.

just for flexibility. 

> You can just add some `make test' tests that involve spaces.


> The changeset-tests should really exercise the mechanism using
> randomly generated filenames.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]