e...@thyrsus.com said:
>> Your "empty cookie string as a sentinel" doesn't work unless you allocate
>> space for the extra slot.
> Eh? We know what the maximum number of cookies is. I think all we have to do
> is notice which cookies are empty (have initial NUL). But I might be wrong
> about
Hal Murray :
>
> Eric said:
> >> They are mostly binary blobs: cookies, keys, nonces, ...
> >> It might be worth packaging blob and length into a struct.
> > OK. That's inside-NTS work - do as you like there. I need to concentrate
> > elsewhere for a bit.
>
> How about packaging the blob of
Eric said:
>> They are mostly binary blobs: cookies, keys, nonces, ...
>> It might be worth packaging blob and length into a struct.
> OK. That's inside-NTS work - do as you like there. I need to concentrate
> elsewhere for a bit.
How about packaging the blob of bits with a 4 byte header: 2
Hal Murray :
>
> e...@thyrsus.com said:
> >> Do we want to store cookies and passwords and such in a fixed max-size
> array
> >> or as heap allocated blobs? In any case, we need to remember the lengths.
>
> > Depends - if they're textual we can assume a '\0' sentinel. I'd prefer to
> > do
>
e...@thyrsus.com said:
>> Do we want to store cookies and passwords and such in a fixed max-size
array
>> or as heap allocated blobs? In any case, we need to remember the lengths.
> Depends - if they're textual we can assume a '\0' sentinel. I'd prefer to do
> that if possible, it would
Hal Murray :
> We should start collecting max/min/required lengths and references to where
> that number comes from.
Agreed. That was on my list.
> Do we want to store cookies and passwords and such in a fixed max-size array
> or as heap allocated blobs? In any case, we need to remember the
You have a couple of trailing spaces.
We should start collecting max/min/required lengths and references to where
that number comes from.
Do we want to store cookies and passwords and such in a fixed max-size array
or as heap allocated blobs? In any case, we need to remember the lengths.
On 1/27/19, Eric S. Raymond via devel wrote:
> I expect this module to be used by ntpd and a small ntske server
> daemon. Because I don't believe incremental code is coing to be an
> issue in any of our deployments, I've chosen an organization that
> minimizes the exposed API and keeps both
I have broken ground on the NTS code. It's a set of stubs in the new
file ntpd/nts.c and external declarations in include/nts.h.
None of this is hooked into the rest of the code yet. My intent is to
develop a clean interface that seals the guts of NTS away from the
rest of the code. Those of
