[Coco] Fwd: MW-C Cross compiler bug - Solved

[Jamie Cho]

Would it be OK to move the code to GitHub? It is easier to share patches on GitHub and will probably generate less clutter for people's inboxes.

The following code in comp_06.c around line 165 fixes the crashing problem:

                    /* L3696 */
                if ( (((int *)var4)[0] == 0)              &&
                     (valptr = shftcount (var4->varsize))   )
#else
                long _lval = ((long)(cref->cr_Right)->cmdval);

                if ((_lval <= 0xffff) && (valptr = shftcount (_lval)))
#endif
                {
                    var4 = cref->cr_Right;
                    /* for non-coco systems, cmdval is already a direct long */
#ifdef COCO
                    var4->cmdval = valptr;

On Mar 9, 2014, at 7:11 PM, Luis Antoniosi (CoCoDemus) <retrocanada76 at gmail.com> wrote:

> ok it will accept:
> 
> func(400L)
> 
> but not
> 
> func(5L*80L)
> 
> or
> 
> func((long)5*80)
> 
> 
> On Sun, Mar 9, 2014 at 6:38 PM, Luis Antoniosi (CoCoDemus)
> <retrocanada76 at gmail.com> wrote:
>> and this will cause core dumped:
>> 
>> func((long)10*80);
>> 
>> On Sun, Mar 9, 2014 at 6:34 PM, Luis Antoniosi (CoCoDemus)
>> <retrocanada76 at gmail.com> wrote:
>>> ok found other bug. when you have long as parameters and you call a
>>> function using a immediate:
>>> 
>>> void func(x)
>>> long x;
>>> {
>>> }
>>> 
>>> 
>>> main()
>>> {
>>> func(10*80);
>>> }
>>> 
>>> I think it's still pushing an int instead of a long. If you use a long var as:
>>> 
>>> long v;
>>> v= 10*80;
>>> func(v);
>>> 
>>> it seems to work.
>>> 
>>> 
>>> On Sun, Mar 9, 2014 at 5:27 PM, Jamie Cho <silurian at icloud.com> wrote:
>>>> Thanks for the link! I knew it worked for me before even though it was apparently always illegal.
>>>> 
>>>> On Mar 9, 2014, at 5:13 PM, Chris Osborn <fozztexx at fozztexx.com> wrote:
>>>> 
>>>>> 
>>>>> On Mar 9, 2014, at 2:01 PM, Gene Heskett wrote:
>>>>> 
>>>>>> Are you saying that both of my copies (original and the "ANSI C" versions
>>>>>> of the K&R books are wrong?
>>>>> 
>>>>> Page 250 of my ANSI K&R 2nd Edition book says:
>>>>> 
>>>>> void *memcpy(s,ct,n)          copy n characters from ct to s, and return s.
>>>>> void *memmove(s,ct,n) same as memcpy except that it works even if the objects overlap.
>>>>> 
>>>>> So yes, you're supposed to use memmove.
>>>>> 
>>>>> The memcpy vs. memmove saga:
>>>>> 
>>>>> http://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html
>>>>> 
>>>>> --
>>>>> Coco mailing list
>>>>> Coco at maltedmedia.com
>>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>> 
>>>> 
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>> 
>>> 
>>> 
>>> --
>>> Long live the CoCo
>> 
>> 
>> 
>> --
>> Long live the CoCo
> 
> 
> 
> -- 
> Long live the CoCo
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco