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

[Bernd Warken]

On Thu, Nov 28, 2002 at 11:08:48AM +0000, Ralph Corderoy wrote:
> 
> > For example, the file groff-current/src/libs/libdriver/input.cc 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++ 
mode.

Bernd Warken