Gary E. Miller via devel writes: >> Dan's patch removed >> collapsed the internal list to a single element that is already >> stripped of its length byte, > > Yes. That was intentional.
As a hotpatch (and demonstration oof the issue) it's OK, as a longterm fix not. All IMHO of course. Btw, I'd expect a decent compiler to optimize the inner loop away as it's all based on static data. >> so it doesn't conform to the ALPN data >> structure description anymore. > > Already discussed here. Right or wrong, NTS was not compatible with > the other NTS implementations. Dan's patch makes NTS compatible. As does mine. > If all the other NTS are doing it wrong, then you need to take it up > with them. NTPsec was doing the wrong thing, and nobody but you insisted otherwise. >> Consequently it also omits any code >> to traverse the internal list, both of which will come back to bite >> you when you do need to support the second protocol. > > Are there any plans for that? I don't remember hearing any. No > need for code to implement some vauge future possible change. Yes. The currently supported protocol is "ntpsec/1", which is not yet frozen in fact. That will change as soon as that RFC is accepted and then any changes or extensions will need to define a new protocol version. >> The previous changes introduced by Hal also check for things that the >> API clearly state need not be checked (there is explicit guidance that >> the callback we implement can assume the syntactic structure of the >> input data is correct). > > Hal had weeks to look at it. Did he miss something? I'm not making any guesses about other folks' state of mind, just pointing out what I see in the code. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
