Re: [Tinycc-devel] Predefined macro identifying TinyC?

[Martin Guy]

On 16/03/2015, Ramsay Jones <address@hidden> wrote:
> On 16/03/15 14:07, Ben Bacarisse wrote:
>> Martin Guy <address@hidden> writes:
>> <snip>
>>> The reason is to work round what looks like a bug in the 64-bit
>>> pointer handling, which is
>>> fairly easy to workaround:
>>>
>>> /* Tickle a bug in TinyC on 64-bit systems:
>>>  * the LSB of the top word or ARGP gets set
>>>  * for no obvious reason.
>>>  *
>>>  * Source: a legacy language interpreter which
>>>  * has a little stack / stack pointer for arguments.
>>>  *
>>>  * Output is: 0x8049620 0x10804961c
>>>  * Should be: 0x8049620 0x804961c
>>>  */
>>>
>>> #define NARGS 20000
>>> int ARG[NARGS];
>>> int *ARGSPACE = ARG;
>>> int *ARGP = ARG - 1;
>>
>> As it happens, this is undefined behaviour by the C language standard --
>> you can't even construct (let alone use) a pointer that points "before"
>> the start of an array.  I don't know whether TinyC is using the
>> permission this gives the implementation, but it is technically free to
>> do whatever it likes in this situation.
>
> Yep, I was about to say exactly the same[1], and suggest the following:
>
> #define NARGS 20000
> int ARGV[NARGS+1];
> int *ARG = ARGV + 1;
> int *ARGSPACE = ARG;
> int *ARGP = ARG - 1;

Yes, in theory I agree with both of you.
Myself I would have make ARGP a pointer to the next free cell, not to
the last used one,
that way it would start at ARGV.

However, it still seems to me that TinyC's behaviour in this case is
bizarre, getting the answer right in the least significant word but
crapping on the most significant word! I would guess the compiler's
constant pointer calculation is done in a 32-bit register instead of a
64-bit one, but that's without having looked at the source.

Cheers & thanks for the info and suggestions

    M