Re: [gpsd-dev] ✘GPSD_API

[Hal Murray]

address@hidden said:
> It is not clear to me what constitutes a compatible channge and what is an
> incompatible change. 

Compatible change means that any program that worked with the old library 
will continue to work with the new library.  That assumes the program follows 
the API.  Your call on what happens if the program cheats.  If a cheat is 
widely used it should probably be promoted to part of the API, at least in 
this context.

Obvious examples are adding subroutines.


> I'm guessing that if I added a field to satellite_t skyview, which is in
> gps_data_t, that would be an incompatible change?o 

There are two issues.  Does a client care about the size?  Did you move any 
of the current slots?

You can safely add something to the end of a struct if the client only deals 
with pointers to the struct.  There is no guarantee that the client won't 
copy the contents which means knowing the size to allocate space for the 
copy.  But they will only copy as much as they know about so that won't break 
anything.  It might break if they copy stuff back which won't update the new 
fields.  The documentation for the API probably doesn't explicitly say 
don't-do-that, but unless there is some reason hinted at in the API I 
wouldn't worry about that case.  It would help to make the API return 
pointers to const xxx.

Don't forget to check for the case where a struct you want to enlarge is used 
in another struct.

If size does matter, you can allocate extra/spare space and use it as needed. 
 I think the SHM stuff does this.


-- 
These are my opinions.  I hate spam.