Re: [gpsd-users] gps_read () message buffer

[Gary E. Miller]

Yo Charles!

On Tue, 26 Feb 2019 17:35:50 -0700
Charles Curley <address@hidden> wrote:

> On Tue, 26 Feb 2019 15:49:27 -0800
> "Gary E. Miller" <address@hidden> wrote:
> 
> > Yo Charles!
> > 
> > On Tue, 26 Feb 2019 16:01:08 -0700
> > Charles Curley <address@hidden> wrote:
> >   
> > > Having done a bit of sleuthing in the gpsd source, I think I have
> > > some additional documentation for gps_read. See the attached diff.
> > > 
> > > Please check it for accuracy!    
> > 
> > The size of the buffer is not really important.  You just keep
> > reading until there is no more to read.  
> 
> Are we talking about the same buffer?

Yers, the buffer for gps_read().

> I know that applies to the
> contents of the gps_data_t structure.

Actually, that one is a fixed size.  But that is easy: sizeof(gps_data_t).

> Does it also apply to the raw
> data, e.g. JSON, that is delivered to message.

Yup.  JSON is just strings.  Read and concatenate.
>
> Also, if you read it multiple times to get the entire message, you
> have to know a lot about the internal structure of the data.

No, just look at the buffer(s) until you get on line.  Lines end with \n.

This is independent of size.  Larger buffers will often get several JSON
strings, so parsing is always required, no matter the buffer size.

> Which you probably would if you wanted to do more than just display it.

Yeah, but no one should be trying to parse the JSON, that would just
duplicate exiting code.  The buffer is just there for debugging.

> So methinks specifying an optimal is a good idea.

Yes, GPS_JSON_RESPONSE_MAX is fine.  That ensures you get at least one
complete sentence.

> I may play with that.

Please do.

> > So there is not need for "at least 4096 bytes".  Although that is
> > a suitable size.
> >   
> > > One request....
> > > 
> > > * I found the value for the size of the buffer by reading the
> > > source for cgps, and tracking down where GPS_JSON_RESPONSE_MAX
> > > was defined, in gps_json.h. That value is likely to grow in the
> > > future. Would you please provide a suitable #define in gps.h?    
> > 
> > What is wrong with GPS_JSON_RESPONSE_MAX?  You want to be several
> > times larger so you emtpy the buffer in one call.  
> 
> Nothing. I'd just like to bring it out where a) the client developer
> can find it easily, and b) so the gpsd developers can change it if
> they think it necessary.

a) easy to find: gps_json.h.  Which is perfect since it is a buffer for
the JSON.

b) No need to ever change it.  Any size works, even one byte long.

But I would say c) needs better documentation.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpl5vsdQJREI.pgp
Description: OpenPGP digital signature