Re: Niggling little changes

[prev] [thread] [next] [lurker] [Date index for 2006/07/07]

From: peter (Peter da Silva)
Subject: Re: Niggling little changes
Date: 16:23 on 07 Jul 2006
> > >  gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth@xxxxxxx.xxx

> > I'm confused, why would you expect the order of tagged elements in a list
> > to remain constant?

> Which list?

gidNumber=0+uidNumber=0

> The two items separated by + aren't usually referred to as
> a list, are they?

I don't know what they're normally referred to as, but they look like a
list to me. If I was more SQL-addicted I'd call it a row, I guess.

The thing is that since each element in the list has a unique tag, that implies
that the tag is what specifies the meaning of the element, rather than the
position. If the order was hardcoded I'd expect it to look like other formats
where the order mattered, like "UIC=[0,0]" or "root:%^&(&*#YUIH:0:0:...".

> The rest of the DN is order-dependent.

And it has identical tags. If it turns out that X.400 makes something like
"ou=frobozz,cn=us" different from "cn=us,ou=frobozz" different, then I'll be
surprised... because formats usually use unique tags *or* order, but not
both.

> So assuming that you just mean the uidNumber and gidNumber:
> because every bit of documentation I've seen on using SASL EXTERNAL with
> Unix-domain sockets also makes the same assumption and after
> understanding what was going on, I went with the strictest definition
> which didn't let arbitrary other data appear and tightened it up.

INteresting. Sounds like there's a lot of potentially broken code out there.

I'm paranoid about formats myself, but I also ask myself "what could the
guy on the other side do that summon the fuckup fairy" and apply the golden
rule.

Sometimes that means I'll take the time to completely parse a stringised
format down to a structure or object before examining the components, and
occasionally have to remove tests for outlying cases that REALLY can't
happen because they're in a critical path. Like recently I found I was
checking every element returned from a query for NULL when the API defined
that NULL would always be returned as the empty string (which is a bit
hateful), and passing it on unchecked made things go faster.

It also means that when I do something stupid I blame myself UNLESS the tool
I'm using didn't provide a non-stupid way of doing the job.

In this case, if regexps are the only tool you have, that's where I'd apply
the hate. It's best to aim ones hate accurately and not waste it on things
that aren't hateful (even if it does make me look like a wuss for not hating
stuff like "you have to click on start to shut down").

There's stuff above here

Generated at 23:01 on 05 Dec 2006 by mariachi 0.52