as it is used in various places in GRASS, I have added
G_is_little_endian() function to test little/big endianess
in
src/libes/gis/endian.c
(GISLIB)
*****************************************************************
* endian test
*
* G_is_little_endian ()
*
* Test if machine is little or big endian (required for file coding)
*
* Returns: 1 little endian
* 0 big endian
I have updated to src/libes/ogsf/ accordingly (NVIZ is affected).
Seems to work well.
Maybe this test is useful for the new vect-lib?
Cheers
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
as it is used in various places in GRASS, I have added
G_is_little_endian() function to test little/big endianess
in
src/libes/gis/endian.c
(GISLIB)
*****************************************************************
* endian test
*
* G_is_little_endian ()
*
* Test if machine is little or big endian (required for file coding)
*
* Returns: 1 little endian
* 0 big endian
I have updated to src/libes/ogsf/ accordingly (NVIZ is affected).
Seems to work well.
Maybe this test is useful for the new vect-lib?
At least in theory third 'PDP'(3412) byte order exists.
I have defined in new include/vect/dig_vect.h #define ENDIAN_LITTLE 0 #define ENDIAN_BIG 1 #define ENDIAN_OTHER 2
(LITTLE_ENDIAN, ... is already used in /usr/include/endian.h)
If you have written that function we could move that definition
into gis.h. Maybe G_get_byte_order() would be better.
In new vect lib test_port program exists which is compiled and run
during compilation and writes out new header file where byte order
is defined (for each type). That is useful because you can use #if BYTE_ORDER == ENDIAN_LITTLE
and speed is increased.
We should probably add before (new) constants defined in grass
some prefix (GR_, GRASS_) to be sure that conflicts cannot appear?
(As used in other libes: G_, TK_, SQL_)
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Jan 15, 2001 at 07:15:36PM +0100, Radim Blazek wrote:
Markus Neteler wrote:
> Hi all,
>
> as it is used in various places in GRASS, I have added
> G_is_little_endian() function to test little/big endianess
> in
> src/libes/gis/endian.c
> (GISLIB)
>
> *****************************************************************
> * endian test
> *
> * G_is_little_endian ()
> *
> * Test if machine is little or big endian (required for file coding)
> *
> * Returns: 1 little endian
> * 0 big endian
>
> I have updated to src/libes/ogsf/ accordingly (NVIZ is affected).
> Seems to work well.
>
> Maybe this test is useful for the new vect-lib?
At least in theory third 'PDP'(3412) byte order exists.
I have defined in new include/vect/dig_vect.h #define ENDIAN_LITTLE 0 #define ENDIAN_BIG 1 #define ENDIAN_OTHER 2
(LITTLE_ENDIAN, ... is already used in /usr/include/endian.h)
If you have written that function we could move that definition
into gis.h. Maybe G_get_byte_order() would be better.
Sounds good to me. If you would like to change that in
src/libes/gis/endian.c
then I will update the related modules. I wasn't aware of
/usr/include/endian.h, sorry.
In new vect lib test_port program exists which is compiled and run
during compilation and writes out new header file where byte order
is defined (for each type). That is useful because you can use #if BYTE_ORDER == ENDIAN_LITTLE
and speed is increased.
fine.
We should probably add before (new) constants defined in grass
some prefix (GR_, GRASS_) to be sure that conflicts cannot appear?
(As used in other libes: G_, TK_, SQL_)
Yes, that's important. We need an agreement here (hi software engineers)
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
> We should probably add before (new) constants defined in grass
> some prefix (GR_, GRASS_) to be sure that conflicts cannot appear?
> (As used in other libes: G_, TK_, SQL_)
Yes, that's important. We need an agreement here (hi software
engineers)
I agree we need something, but I think it should be extended to the
environment variables as well. Whether it is GR_ or GRASS_ is just a
matter of taste, but we should be consistant.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
> > as it is used in various places in GRASS, I have added
> > G_is_little_endian() function to test little/big endianess
> > in
> > src/libes/gis/endian.c
> > (GISLIB)
> > * G_is_little_endian ()
>
> At least in theory third 'PDP'(3412) byte order exists.
> I have defined in new include/vect/dig_vect.h
> #define ENDIAN_LITTLE 0
> #define ENDIAN_BIG 1
> #define ENDIAN_OTHER 2
> If you have written that function we could move that definition
> into gis.h. Maybe G_get_byte_order() would be better.
Sounds good to me. If you would like to change that in
src/libes/gis/endian.c
then I will update the related modules. I wasn't aware of
/usr/include/endian.h, sorry.
I will add into gis.h: #define GRASS_LITTLE_ENDIAN 0 #define GRASS_BIG_ENDIAN 1 #define GRASS_OTHER_ENDIAN 2
and into src/libes/gis/endian.c new function
G_get_byte_order() which returns GRASS_LITTLE/BIG_ENDIAN
(use code from G_is_little_endian()).
After new vect lib tests we could move byte order test into
gislib in grass51.
If you agree please add note about GRASSS_ prefix for environment
variables and constant names to SUBMITTING.
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'