RE: [MiNT] Re: GCC

["Julian Reschke" <reschke@medicaldataservice.de>]

> > > > Hmm, they claim to be full ANSI. Never stumbled on a deviation.
> ...
> > In that case, because I do not port sources
> > very often, can anybody tell me the deviations.
> 
> I once had to modify a program because PureC (I don't think it was back
> in the TurboC days) complained about something to do with namespaces.
> It might have been along the lines of the example below (a variable with
> the same name as a struct) but, unfortunately, it's been so long that I
> don't really recall more than that there _was_ a problem of some kind...
> 
>    typedef struct test1 {
>       int a;
>    } test2;
> 
>    struct test1 x;
>    test2 y;
> 
>    int test1;          /* Should be OK (gcc with -ansi -pedantic) */
>    /* int test2; */    /* This should give an error if uncommented */

Interesting. So far I haven't come across a PureC problem which made the
compiler itself non-ANSI...

> Personally, I try to avoid PureC because it causes me more problems
> (mainly because of its 16 bit ints) than the compilation speed is worth
> (both gcc and Lattice are reasonably quick on an '040).
> I also don't like to use C as a 'macro assembler', which is more or less
> necessary if you want to get decent speed out of PureC compiled code.
> Take a look at dejanews for my Usenet articles comparing the three
> compilers mentioned here if you want to see what I mean.

I am very surprised to hear this. My experience is that PureC code usually
is smaller and faster because of the parameter passing model.