[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Using C with glib instead of C++ for groff

From: Bernd Warken
Subject: Re: [Groff] Using C with glib instead of C++ for groff
Date: Thu, 28 Nov 2002 14:59:53 +0100
User-agent: Mutt/1.2.5i

On Thu, Nov 28, 2002 at 11:08:48AM +0000, Ralph Corderoy wrote:
> > For example, the file groff-current/src/libs/libdriver/ has
> > some problems with the integer length of some variables.  Although 32
> > bits are necessary for some constructs, the file only uses `int' as
> > type.  `int' is on GNU PC's wide enough with 32 bits, and `long' is
> > too large with 64 bits.  But in ANSI C, `int' has 16 bits and `long'
> > has 32 bits.
> This is incorrect.  ANSI C does not mandate `int' has 16 bits.
In my version of the ANSI C book of Kernighan/Ritchie, chapter B.11
on <limits.h> says

INT_MAX     +32767
INT_MIN     -32767
UINT_MAX     65535

This makes int and uint 16 bits types in ANSI C.
> > This inconsistency could be fixed with the type `gint32' correctly
> > defined for all systems in `glib'.  Without `glib', the `#ifdef'
> > routines of my original version of the file must be readded.
> No, without glib, if the problem actually affects someone instead of
> being theorectical, groff would need a solution which could easily be
> its own autoconf test and definition of a 32 bit integer type.  You
> #ifdef routines are not the only solution.
But it has to be done for all cases where the C compiler is not GNU gcc
with 32 bits int type, for example on IE64.

> > Are there any troubles to request the availabilty of `glib' for a
> > proper compilation of the `groff' package (so far just for groffer)?
> If groffer didn't build if glib wasn't available but it caused no other
> problems then fine.  But I'd hate to see a glib dependency spread any
> further until glib was on all likely groff targets as standard.
But then we should learn about glib and write the necessary stuff
ourselves.  In the current groffer, I can do with groff's short C++ 

Bernd Warken

reply via email to

[Prev in Thread] Current Thread [Next in Thread]