> Is Data guaranteed to be non-empty here? If not, you should check that > first.
It is as the first real line of the method checks for Data.length() < 1 and otherwise exits, so Data is at least one char long. You can still do a silly Pin: origin " which should maybe be catched as not allowed to match an empty string, but even if detected it can't be expressed with a error message as the parser seems to be too dumb for it… 2010/8/30 Julian Andres Klode <[email protected]>: > On Mo, 2010-08-30 at 11:34 +0200, David Kalnischkies wrote: >> > I personally do not want quoting here, as it just complicates parsing >> > and breaks backwards compatibility. The documentation could state >> > explicitly that quotes are not supported; but this is purely a >> > documentation issue, and thus minor (it may also break translations of >> > the manpage). >> >> I don't get the complicated parser argument, how could a single char >> increase the complexity of a parser - especially as the empty string >> needs to be represented somehow anyway… >> And compatibility? Its long ago that i saw a hostname starting with "… >> Or do we need to maintain compatibilty with this bugs as users have non >> working rules in their preferences file because of this bug? > Well, for origin Pins alone this does not apply. I was talking about > allowing quoted strings everywhere in preferences files. And yes, a > hostname can not contain quotes at all, at least if you want to follow > RFC 3986. > > Of course, if you only add quotes to origins, you break nothing. But as > a hostname can not contain spaces, having quotes there is useless; and > it still gives you the assumption that you can use quotes every. but a hostname can be empty in which case the preferences manpage says Pin: origin "" will match. Pin: release a= on the other hand will not work and is also not advertised this way in the manpage nor in the apt-cache policy output. I think it is just tempting to write "hostname" if you have an example in that way, even if the hostname in this example is empty. The rule "<hostname or empty>" feels more natural than <hostname or "">. Especially if no error is given for wrong syntax… The space argument is in so far complicated as Label and Co could include spaces and Pin: release l="some label" is not supported in any way… >> Attached is the overly complicated patch to fix it by implementing option 2 - >> option 1 would only differ a bit in the first if-else block and would need >> a bit too much handwork on the po files for my taste… > Any reason why you break/remove pattern matching in your patch? I think > Pin: origin *debian.org > Pin: origin /.*debian.org/ > can be really useful (that's why I wrote it). In which way is it broken? I just removed the first invocation as matching doesn't need to be checked twice if the entry matches, thats all, the pattern magic still happens in the return line… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
