[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: Ralph Corderoy
Subject: Re: [Groff] Using C with glib instead of C++ for groff
Date: Thu, 28 Nov 2002 22:48:29 +0000

Hi Bernd,

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

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



reply via email to

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