Re: More dev86 changes (0.16.5)

[Robert de Bath <robert$@mayday.cix.co.uk>]

On Wed, 24 Jul 2002, Riley Williams wrote:

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

Actually, thinking about this, where do these 'def' varients come from
IIRC 'elif' is Ansi-C but I don't think the others are, plus of course
you can use "#elif defined(VARNAME)"

> >> 2) #warning support (at least for non-continued lines).
>
> > In 0.16.5
>
> With or without the continued lines?
Without so far, I'll probably fix it later; and add #error (as a specific)
oh and skipping '#pragma'.

> 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

Possibly useful but I've _never_ come across them before and never though
of them as (WIBNI). IMO the '#debug' ones are useless, they'd (maybe)
be used once per program and as you mentioned '#warning' does the job.

_IF_ I implemented them I don't think it'd be directly as this, possibly
as '#pragma' varients would be ok. ("#pragma toplevel" perhaps)

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

NO. Null statments are frequently required in C and it's _very_ difficult
to guess it one is wrong; I have come across a compiler that could be
configured to warn about them and tried it, PITA.

Even the specific case of a semicolon at the end of a macro is dubious
though more easily detected. If I were going to start adding style
warnings I'd start with the potentially damaging ones (eg = rather
than ==).

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>