Re: More dev86 changes (0.16.5)

[mjn3@codepoet.org (Manuel Novoa III)]

Robert and Riley,

First, thanks Robert for all the work you've done in integrating
and improving these changes.  It will certainly make my work easier.

On Wed, Jul 24, 2002 at 11:02:44PM +0100, Riley Williams wrote:
> >> 1) #elif support.
> 
> > In 0.16.5
> > Do we want #elifdef too?
> 
> If we support it as a variant of #if then we also want it as a variant
> of #elif as well, in my opinion. Therefore, we will want...
> 
> 	#elif
> 	#elifdef
> 	#elifndef
> 
> ...together with any other variants that may exist.


> Also (inspired by the way it's used in your example below, but taken
> from a C compiler I once used on a Burroughs B6700 mainframe), could
> support be added for the following...
> 
>  a. #debug msg
>  b. #debugn msg
>  c. #info msg
>  d. #onerr msg

#elif is C89.  While the others could be convenient at times, I know
that I wouldn't use them for portability reasons.

> I would like to see the code produe a warning for the fact that the
> macro defenition for strong_alias() includes the terminating semicolon
> that should never be present on macro definitions - and yes, I know the
> Linux kernel uses several macros that break this rule. Linus himself
> states that they're wrong, but they're so well embedded that it's more
> hassle than it's worth to fix the problem...

The trailing semicolon was strictly a convenience thing.  The uClibc
code contains several instances of strong_alias().  Generally where
it is used, there is no trailing semicolon.  This caused a problem
when building with bcc since, although the patch allowed asm() to be
used at file scope, it was still a statement and needed trailing
semicolon for bcc to be happy.  Rather than change all the offending
instances in uClibc at the time, I just put the ';' in the bcc macro
definition.  I've got no problem changing this before the port is
committed.

> One other thing I would like to see, which is an optimising measure more
> than anything: When bcc lays out the variables at any level, if it sorts
> them in descending order of size before laying them out, it will really
> minimise the number of padding bytes needed to ensure correct alignment.
> It is for this reason that when I am writing C code, I always list all
> of the variables in descending size order,

Same here.  ;-)

>                                            but the compiler could make
> this irrelevant, as many other optimising measures have become totally
> irrelevant over the years.

Manuel