[9front] ndb doc patch

[9front] ndb doc patch

[Romano]

Hello list,

At the end of last year I had a small patch
for ndb's man page. There was a bit of
discussion re: it in January ( https://inbox.vuxu.org/9front/39A39E500516DB6E2B4CE0BC27677DEF@eigenstate.org/ )
and I have tried to address Ori's suggestion
here: http://okturing.com/src/20100/body

Re: [9front] ndb doc patch

[Jacob Moody]

On 6/18/24 12:35, Romano wrote:
> Hello list,
> 
> At the end of last year I had a small patch
> for ndb's man page. There was a bit of
> discussion re: it in January ( https://inbox.vuxu.org/9front/39A39E500516DB6E2B4CE0BC27677DEF@eigenstate.org/ )
> and I have tried to address Ori's suggestion
> here: http://okturing.com/src/20100/body

I would probably much prefer to fix this than to document a bug.
If anything should change regarding this, it should be picking a
sensible maximum and then documenting it in ndb(6) as part of the
file specification. Not in ndb(8) as a bug of the implementation.

Thanks,
moody

Re: [9front] ndb doc patch

[Romano]

On Wed Jun 19 14:30:21 -0700 2024, moody@posixcafe.org wrote:
> On 6/18/24 12:35, Romano wrote:
> > Hello list,
> > 
> > At the end of last year I had a small patch
> > for ndb's man page. There was a bit of
> > discussion re: it in January ( https://inbox.vuxu.org/9front/39A39E500516DB6E2B4CE0BC27677DEF@eigenstate.org/ )
> > and I have tried to address Ori's suggestion
> > here: http://okturing.com/src/20100/body
> 
> I would probably much prefer to fix this than to document a bug.
> If anything should change regarding this, it should be picking a
> sensible maximum and then documenting it in ndb(6) as part of the
> file specification. Not in ndb(8) as a bug of the implementation.

Yeah, I that would be preferable but I thought at least documenting
the known behavior that could trip someone else would would be okay.

Instead of documenting tho', the attribute name should not be limited
to 32 bytes (and not silently truncated) but I'm not sure what a
sensible maximum is. The attribute values as far as I can tell will
happily consume as much memory as possible, and Ndbvlen (as Ori
pointed out) is just a starting default.

For the line parsing limitation of 8K, do you think that is
also something that should be fixed or something that is OK to
document as a limitation?