[GRASS-dev] endian & generic library

[Hamish]

Brad:
> > Does it make sense to have these functions, string/debug, and memory
> > related functions in a separate library?  More trouble than it's
> > worth?
Glynn:
> I'm not sure that a library makes sense; it's probably better for
> import/export modules to do it themselves. Apart from anything else,
> it allows the compiler to inline the code; such modules will typically
> be [de]serialising arrays rather than individual integers.

They are sufficiently abstruse to encourage subtle mistakes, so having
them predefined somewhere would be nice. ... What if the endian
transforms were written as macros (or inline functions) that could be
#included from a header file when needed? Does that solve both problems?
The alternative is cut&paste into each module and hope that down the
road no one changes one version but not the others.


Glynn:
> SUBMITTING isn't supposed to be a tutorial on C programming
> (even if many contributors badly need one).

Many of us are researchers who know a little C programming, not the
other way around. We are lucky to have a few experts around to help
point out the errs of our ways, but still we need all the help and
on-the-job training we can get. It may be redundant and beyond the scope
of the SUBMITTING document to recreate K&R in full, but it wouldn't hurt
to throw in a small reference section at the end of the document
pointing to some background info on safe strings, pointers, memory
allocation, etc., usage; links to other project's SUMITTING files..

me:
> > FWIW, this is what the Linux Kernel's version looks like:
> >   http://lxr.linux.no/source/Documentation/CodingStyle
Brad:
> I believe GRASS should have a similar document that is a bit more
> expansive and covering design decisions that affect coding style.  I
> think it would cut down on repeat questions.

Can you provide some examples of "design decisions"? Just curious.



Hamish