Re: C compiler, assembler and linker

[Riley Williams <rhw@InfraDead.Org>]

Hi Manuel.

> Didn't have time yesterday to generate the patch, but here it is.
> Some of the build changes only make sense if you aren't installing
> in the default locations as root.
>
> As a refresher, it adds #elif support, #warning support (for
> non-continued lines), asm() at file scope, limited support for
> recursive #define (#define stdin stdin), and more complete exclusion
> of the floating point related code when floats are disabled. This
> lets you build bcc for elks. As I mentioned earlier, it looks like
> the preprocessor works but it dies when trying to do code generation.

I'll have a look at it anyway...

>> Unfortunately, that's not actually true. It's very easy to prove
>> that bcc uses SIGNED chars if the unsigned keyword isn't
>> specifically given. Robert also states that bcc does not correctly
>> handle signed chars, so this default rather worries me.

> Can you send me a simple test app to illustrate this? Thanks.

Not needed in this case - just read through the declspec() function
definition and you see that bcc internally uses SIGNED types for
everything unless the unsigned keyword is specifically given. There is
absolutely nothing in there to make char different from int.

I mentioned this to Robert when I sent in the patch referred to above,
and he confirms that the language analyser does indeed select on that
basis. However, he implied that the code generator will use unsigned for
char even when the language analyser says they should be signed, so
there is presumably some hack for this that really wants to be removed.

The patch I enclosed last time simply adds the ability to select either
signed or unsigned in the language analyzer and end up with the correct
result. It doesn't touch any hack such as the above.

>> As it happens, I emailed a patch to Robert back on 6th June 2002
>> that added and correctly implemented the signed keyword in the
>> declspec function, thus dealing with most of the problem. There may
>> be a few corner cases left where signed will cause problems, but I
>> haven't seen any of them yet. I've attached a gzip'd copy of that
>> patch to this email for reference...

> I'm looking forward to trying out your patch in a few days when
> things slow down for me.

Many thanks.

Best wishes from Riley.