Re: [AD] msvc7 vs new_api_branch

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2005-08-20, Chris <chris.kcat@xxxxxxxxxx> wrote:
> On Saturday 20 August 2005 09:46 pm, Peter Wang wrote:
> > > MSVC7 has a __FUNCTION__  macro, so somewhere we could
> > > #define __func__ __FUNCTION__
> > > but where?
> >
> > gcc accepts __FUNCTION__ as well, so we'll go with that.
> > __func__ is C99.
> 
> I'd say we should use __func__ where possible. It's standard, after all (C99, 
> which new_api_branch/4.3+ is going to use/uses already). IMO, best not to use 
> extensions/custom constructs when there's standard equivilants. For MSVC, 
> yeah.. defining __func__ to __FUNCTION__ would be the solution here, but I 
> think we should make use of __func__ directly where possible to encourage its 
> use.

I'd rather not define any more macros than necessary, especially where
there is only one use of it so far.  If __FUNCTION__ works we should
just use it.

> Unless C99 explicitly specifies otherwise, I think it'd be safe to assume that 
> a C/C++ compiler set will make them the same size for this very reason. And 
> if not, then we just don't use bools in the exposed parts of the API (public 
> or not). Either way, we shouldn't have to worry about the size of bool.

I'd removed the redefining bit before you posted.  It's just that in
older distros we'd have stdbool.h doing something like "typedef int
bool;", and it caused trouble (I think it was when I was using C++ for
implementation at the time).  We have a configure check now so
HAVE_STDBOOL_H won't be defined unless the sizeof(bool)==1.. I think.

> Redefining bool to a char may be a bad idea regardless. Even though C99 
> specifies that bool must be a macro (so I hear), GCC defines bool to a 
> built-in compiler type _Bool, which apparently can only accept true and 
> false. 

This is specified by the standard.

> Even if the latter is accepted, it'd be logical to assume it would change the 
> 0xFF to true, meaning the two may be stored differently and cause problems 
> (like, if it's returned or passed to a function in a file that doesn't have 
> Allegro included, and is checked against true explicitly). And also, size 
> problems again, if one file uses Allegro it'll have bool at 1 byte, but 
> another file doesn't use Allegro, could have bool at something else.. if that 
> bool is passed to/from a function...

So you should continue not to compare boolean variables directly against
`true'.

Peter