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

[Ralph Corderoy]

Hi Bernd,

> > > 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.

Ah, I see where you're getting it from.  But at the start of B11 it says

    "The values below are the acceptable minimum magnitudes;  larger
    values may be used."

Which means that INT_MAX >= +32767 and INT_MIN <= -32767, i.e. 16 bits
in the minimum.  Similarly, 16 bits in the *minimum* for short, and 32
the minimum for long.

> > > 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.

Doesn't it have to be done once in configure.in as a test of the local C
compiler.  The result of the test would cause an appropriate definition
for groff32sint.

> > > 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.

I've no objection to examining how glib achieves somethings that groff
would find helpful.  I'm just not sure immunity to an int smaller than
32 bits is one of them.

Cheers,


Ralph.