On Mon, Jul 06, 2026 at 01:59:47PM +1000, Seth McDonald wrote:
On Sun, 05 Jul 2026 at 12:46:14 +0200, Oswald Buddenhagen wrote:
> The patch had two goals:
> 1) Un-intertwine the current two implementations.
> it doesn't achieve that to any appreciable degree. the cyrus implementation
still hard-codes the login special case,

Yes, both implementations (Cyrus & simple) share the LOGIN logic.  But I
fail to see how having some logic in common means the goal overall is
not met.

how can you admit that cyrus and login are still tangled but claim that the objective of untangling was achieved? the one implementation is now simply a strict superset of the other. that's a few localized ifdefs being replaced by one big build system level "ifdef" around some massive duplication.

> 2) Add the infrastructure to allow a third implementation.
> as i said previously, just add the gsasl impl. with ifdefs.

Okay, I can do that.  But I _really_ do not think it would be a good
idea to continuously keep the implementations weakly separated with
#ifdefs scattered across a file.  It requires WAY more mental work to
parse and is hence harder to maintain for no discernible gain.  And it
strongly encourages spaghetti code due to the lack of clear structure
and logical boundaries.

indirections, duplication, and boilerplate also add mental load.
abstractions pay off only beyond a certain threshold. i find it obvious that it isn't reached here.

Though would you be open to changing the fixed-size buffer to a dynamic
one?

no.

It's much better to be dynamic when the buffer size is unknown
beforehand, rather than choosing an arbitrary fixed size and hoping it
will be enough.

dynamic buffers have a complexity (and runtime) cost. therefore, a fixed-size buffer that can hold any sane content without causing an unreasonably large stack size spike is preferable. the oob()-"assertion" is mildly ugly, but not uglier than the memory management that would be otherwise required by C.



_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to