Re: [Devel] PureC

[Antoine Leca]

Hi folks,

Looks like Wolfang is the first guy that attempts at using Freetype 2 on a
16-bit platform ;-) and furthermore with a not-completely ANSI compiler, so
I believe he will encounter quite a number of problems...

Wolfgang, if there are some point you believe should work but are not, and
if you believe the things may run without any problem on a box where int and
long are of the same size, that is 32 bit, do not search too much and report
it here asap: this library have almost not being tested against 16-bit, so
this would certainly not be a surprise there are a number of small bugs
lurking in this area. However, a lot of people here, including Werner and
David, understand pretty very well what 16-bit portability means, and can
easily fix the things (because they know the source very very well, unlike me).

Unfortunately, I have no spare time, so I cannot engage myself in the
extensive test of a port to 16-bit compiler(s).


David Turner wrote:
> 
> > The first problem is to compile a construct like this one (example from 
> > ftimage.h):
> >
> >   typedef enum  FT_Glyph_Format_
> >   {
> >     ft_glyph_format_none      = 0,
> >     ft_glyph_format_composite = FT_IMAGE_TAG( 'c', 'o', 'm', 'p' ),
> >     ft_glyph_format_bitmap    = FT_IMAGE_TAG( 'b', 'i', 't', 's' ),
> >     ft_glyph_format_outline   = FT_IMAGE_TAG( 'o', 'u', 't', 'l' ),
> >     ft_glyph_format_plotter   = FT_IMAGE_TAG( 'p', 'l', 'o', 't' )
> >
> >   } FT_Glyph_Format;

Well, I did not notice this one...


> Just to clarify things, we're using an enumeration here is
> to allow third-party extensions. For example, imagine that
> we want to provide a "MetaFont" font driver for FT2.
> We'll need:
> 
>   - a "font driver" module to parse/load the font files
>     in memory, and generate metrics and glyph images
>     from them.
> 
>   - a specific "renderer" module, since the glyph images
>     produced by MetaFont cannot easily be converted into
>     the bezier-based FT_Outline type.

Good idea. However, 32-bit enumeration types are not completely
ANSI compliant (for ANSI compliance, a enum should "fit" into
an int, because in fact every enum constant is converted into
an int at compiler time, and there are no further relation
between the type and the constants. This is whole different
from Pascal or even C++, and misleading, but was contrained
by backward compatibility.)

 
> If we use 32-bit integers for the glyph format type, we
> can easily create a new one without risking conflicts
> when two third-parties try to produce their own image
> format. Of course, that's extremely unlikely but it's
> relatively easy to be safe with enums..

I believe we are as much as safe with 16-bit, aren't we?
I guess we are not going into bbreaking compatibility at this
time, but how restricting any new "tag" that may eventualy
be defined, to be distinct within the two first character
(that is, while 'meta' might be allowed, 'plus' won't since
it will collide with 'plot')?

Another solution is, for Atari PureC (and perhaps in the main
tree as well), to drop the use of enum here and to revert to
"plain" manifest constants, which are not restricted to int.

 
> I always thought that enum types were widened to "long"
> in ANSI C if one of the constants listed couldn't fit
> in an "int" type.

No. Several 16-bit compilers did so (like Microsoft's), and
others like Borland did not (at least in 4.0; I do not if they
improved lately).
Of course all of this is a non-issue on 32-bit compilers.


Antoine