[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 11:08:48 +0000

Hi Bernd,

> The actual source of groff uses a simplified C++ which could be
> critical on some non-Linux systems or some future C++ changings.  For
> example, it is planned to replace `static' by `namespace' concepts;
> groff does not use namespaces because of difficulties with some
> compilers.

That's one possible future problem.

> An alternative for groff version 2 will be to use the `glib' library;
> glib completely works in C, but provides several C++-like
> quasi-objective elements.  The glib library exists on almost all
> operating systems, including all Unix-like systems, Microsoft, and
> Mac.  So it would make sense to use it for implementing the unicode
> structures for groff.

When you say `exists' I take it you mean `can be installed on'?

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

And you're suggesting another future possible problem.  At least, that's
what I think it was settled as the previous time it was raised.

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

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



reply via email to

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