Re: [gpsd-dev] ✘GPSD_API

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > > For example, was the recent addition of oscillator_t osc to
> > > gps_data_t a compatible change that should have incremented the
> > > minor rev?  
> > 
> > I'm pretty sure that breaks the abi as you are chaging the size of
> > structs.
> 
> I don't think it does change the size of gpsdata_t since oscillator_t
> was slipped into a union already bigger than it is.  I think it should
> been a minor version bump since it should not affect existing programs.

That is correct.

> > you also might want to read
> > http://www.catb.org/esr/structure-packing/
> 
> Even embedded systems now have gobs of memory.  As soon as we use
> python, or any other garbage collection, the gross handling of RAM makes
> saving a byte here or there in C ludicrous.  Page frames allocated by
> the kernel are now 4k or even 4M, so months of work packings bytes would
> be needed to save enough RAM to eventually save one page frame.
> 
> I just took a look at my desktop host, gpsd is about the smallest thing
> running.
> 
> I'm not saying to be wasteful, but there are way more important things to
> spend time on now than packing structures.

Yes, there are.

I wrote that after wrestling with one of the very few cases where the technique
is still useful - data sets so large that if you don't pack them carefully you
might hit a physical memory limit.  The context was cvs-fast-export on *huge*
CVS repositories.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature