RE: [GD-General] Feedback wanted on POSH

[Brian H. <ho...@py...>]

> After looking at posh.h I'm a bit confused.  You have defined a
> whole list of basic types (posh_..._t), signed and unsigned
> integers of 8, 16, and 32 bits respectively.  I notice, however,
> the only platform you support that requires these typedefs is
> PalmOS, and then only for the 32-bit integers.

Well, that and the different 64-bit definitions.  But you're right, on 
today's machines, ILP32 is basically the de facto standard.

But this is partly misleading, since I simply haven't added support 
for any 16-bit processors, something I'd like to see done at some 
point if possible.

There are also a huge range of embedded systems that I'd like to see 
supported, such as the Renesas/Hitachi H8 series; real-mode DOS 
support; etc.  I just haven't got around to it.  I know, I'm a freak, 
but hey, I figure I'll be thorough.

Now, I do draw the line at FAR/NEAR stuff, but if something is a true 
16-bit platform (not the 20-bit segmented stuff of DOS), then adding 
support for it SHOULD be pretty straightforward.

> This seems like overkill, especially considering the duplication of
> integer/signed types.

Fair enough, but it's localized and doesn't need to be used.  And, 
more importantly, almost every portable open source code base I've 
seen does almost the exact same thing.  Take a look at libpng. zlib, 
etc. and they'll often have similar types of defines but with 
different names.

My expectation is that an application or a library that uses posh will 
actually just shadow the posh types, e.g.

typedef posh_byte_t mylib_byte_t;

> This leaves me wondering whether some
> platforms define char as unsigned char while others define char as
> signed char.  

This is implementation dependent, and also the source of lots of fun 
portability bugs:

char ch =3D 0xFF;

if ( ch =3D=3D 0xFF )
   return;
exit( 1 ); //WHY IS THIS REACHED SOMETIMES?

> Also, I find it misleading to call an unsigned char a "byte", since

While I agree a "byte" means "size", in most implementations I've seen 
bytes are generally considered to be 8-bit unsigned quantities.  
Because of this, I just tried to stick to this convention.

> variable of type i16 to s16, which serves no purpose.

Agreed, I mostly put both sXX and iXX because different people have 
different preferences on this.  I didn't want to dictate, but this may 
be a case where conciseness should overrule generality.

Basically I couldn't choose which I liked better, so I did both =3D)  
Maybe I should just put in a comment that explicitly states that they 
are aliases of each other?

> Grandmaster B, I seek enlightenment on these matters, would you
> mind explaining your reasoning?

So you wanna go there? =3D)

Brian