Re: 64 bit nonportability

[Rob Browning]

Hendrik Boom <[EMAIL PROTECTED]> writes:

> #define G_MININT  INT_MIN
> #define G_MAXINT  INT_MAX
> 
> in glibconfig.h, but nowhere do I see a G_MAXINT32.
> 
> Or is there something else I need to knw?

You'd have to define these too if glib didn't.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Hendrik Boom]

> On Sat, 03 Jun 2000 22:06:09 PDT, the world broke into rejoicing as
> Dylan Paul Thurston <[EMAIL PROTECTED]>  said:
> > On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> > > On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > > > I agree. Using gint32 rather than int only solves part of the problem.
> > > > foo_t is much more flexible.It reduces the architecture dependency to a 
> > > > single point in the code.
> > > How is this different from using already-created typedefs in glib?  glib
> > > seems to provide a lot of the types necessary, already done.
> > 
> > I think the point is that you might decide to change the size of one
> > of the types at some point.
> 
> Ah, yes.
> 
> Basic idea being that it might be good to have a single type, of
> platform-independent shape, that GnuCash uses.
> 
> Thus, perhaps, the
> gcint
> type.
> 
> Thus, everything in GnuCash would use the gcint type.
> 
> gcint is defined via:
>   typedef gint32 gcint;
> 
> which accordingly references whatever glib.h provides.
> 
> Note that this costs us _nothing_ at runtime, as the evaluation of types
> is done by the C preprocessor, and this gets expanded, by the compiler, 
> to whatever is the "real" type from its perspective.

I've always had trouble getting constants to have the right type.
I don't think the preprocessor will hanle this cleanly (or have things
changed since I last looked at C?).  Evin if (gint32)7 works (I seem to
remember thst this is not what is technically called a "constant expression"),
there is still trouble with things like getting the maximum integer of type
gint32.

I see

#define G_MININTINT_MIN
#define G_MAXINTINT_MAX

in glibconfig.h, but nowhere do I see a G_MAXINT32.

Or is there something else I need to knw?

-- hendrik.



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Christopher Browne]

On Sat, 03 Jun 2000 22:06:09 PDT, the world broke into rejoicing as
Dylan Paul Thurston <[EMAIL PROTECTED]>  said:
> On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> > On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > > I agree. Using gint32 rather than int only solves part of the problem.
> > > foo_t is much more flexible.It reduces the architecture dependency to a 
> > > single point in the code.
> > How is this different from using already-created typedefs in glib?  glib
> > seems to provide a lot of the types necessary, already done.
> 
> I think the point is that you might decide to change the size of one
> of the types at some point.

Ah, yes.

Basic idea being that it might be good to have a single type, of
platform-independent shape, that GnuCash uses.

Thus, perhaps, the
gcint
type.

Thus, everything in GnuCash would use the gcint type.

gcint is defined via:
  typedef gint32 gcint;

which accordingly references whatever glib.h provides.

Note that this costs us _nothing_ at runtime, as the evaluation of types
is done by the C preprocessor, and this gets expanded, by the compiler, 
to whatever is the "real" type from its perspective.

Mind you, I'm not sure there is _vast_ value in having GnuCash-specific
types over those defined by glib...
--
[EMAIL PROTECTED] - 
"Linux!  Guerrilla UNIX Development Venimus, Vidimus, Dolavimus."
-- <[EMAIL PROTECTED]> Mark A. Horton KA4YBR

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Dylan Paul Thurston]

On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > I agree. Using gint32 rather than int only solves part of the problem.
> > foo_t is much more flexible.It reduces the architecture dependency to a 
> > single point in the code.
> How is this different from using already-created typedefs in glib?  glib
> seems to provide a lot of the types necessary, already done.

I think the point is that you might decide to change the size of one
of the types at some point.

--Dylan

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Peter C. Norton]

On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> 
> I agree. Using gint32 rather than int only solves part of the problem.
> foo_t is much more flexible.It reduces the architecture dependency to a 
> single point in the code.

How is this different from using already-created typedefs in glib?  glib
seems to provide a lot of the types necessary, already done.

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Richard Wackerbarth]

On Sat, 03 Jun 2000, Robert Graham Merkel wrote:
> Christopher Browne writes:
>  > What GnuCash probably needs is to _pervasively_ use gint32 rather than
>  > int, gnit32 rather than long, and such.  Of course, someone has to
>  > volunteer to do the global-search-and-replace on this sort of thing...
>
> Before we do that *too* globally, it'd probably be nice to set up
> wrapping these types with g-wrap.
>
> Additionally, for many of the quantities we pass around, might it not
> be a good idea to define a typedef for them, analagous to
> the foo_t types in the C libraries?

I agree. Using gint32 rather than int only solves part of the problem.
foo_t is much more flexible.It reduces the architecture dependency to a 
single point in the code.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

64 bit nonportability

[Robert Graham Merkel]

Christopher Browne writes:
 > What GnuCash probably needs is to _pervasively_ use gint32 rather than
 > int, gint32 rather than long, and such.  Of course, someone has to
 > volunteer to do the global-search-and-replace on this sort of thing...
 > 
Before we do that *too* globally, it'd probably be nice to set up
wrapping these types with g-wrap.

Additionally, for many of the quantities we pass around, might it not
be a good idea to define a typedef for them, analagous to 
the foo_t types in the C libraries?

-- 

Robert Merkel  [EMAIL PROTECTED]



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

64 bit nonportability

[Christopher Browne]

On Thu, 01 Jun 2000 12:56:51 CDT, the world broke into rejoicing as
John Goerzen <[EMAIL PROTECTED]>  said:
> Hi,
> 
> I have a bit more details on the bug report I submitted wrt gnucash
> segfaulting while loading a file.
> 
> I tried running gnucash on an i386 machine, loading the same file, and this
> worked perfectly.
> 
> Therefore, I think we can conclude that there is some element of 64-bit
> uncleanliness in gnucash's file reading routines.  (The platform exhibiting
> the problem is an Alpha running Linux)
> 
> Don't ask me where, though :-(

I expect that it's pretty pervasive.

There are LOTS of places where GnuCash uses "int" values, which are
of rather different form on 64 bit architectures than on 32 bit ones.

Result:
  You read values into a struct, and find that since parts of it have
  changed size, the results no longer align well, which makes any
  zero-delimited strings, chewing up bits of what's off, chew up
  chunks of the next struct, leading to ill.

What GnuCash probably needs is to _pervasively_ use gint32 rather than
int, gint32 rather than long, and such.  Of course, someone has to
volunteer to do the global-search-and-replace on this sort of thing...

I suspect that this change, or something like it, _will_ ultimately
prove necessary.  Mind you, I rather think that it would be better
solved by having GnuCash _not_ use a binary data format.
--
[EMAIL PROTECTED] - 
Why are men like blenders?
You need one, but you're not quite sure why. 

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]