On 3/14/06, C H Forsyth <forsyth@vitanuova.com> wrote:
>
> the compiler shows the linear type representation it uses internally.
> IND is `indirect', a pointer, or *
> UCHAR is `unsigned char'
> CONST is obviously `const'
> so in
>
> dumb_input.c:249[stdin:1718] argument prototype mismatch "IND UCHAR" for
> "IND CONST CHAR": strlen
>
>         you're passing an unsigned char* to strlen, which expects const
> char* (or char*)
>
> the compiler could possibly translate them back to normal C declarator
> form
> from the internal one, but on the other hand, in more subtle cases,
> seeing them written in linear form can be helpful if you've got
> a * or () in the wrong place.



The output is backwards from what I'd expect about the types though.

In C and C++ const always refers to the item on the left of the const,
unless thre isn't one, then you go to the right.

const int
and
int const

are identical

int const *

and

int * const

are not the same :)

So when I read:
"IND CONST CHAR"

my brain is already "wired up" to think of that as

char * const

not

char const *

or equivalently

const char *

Anyone else have this problem?  If it's just me I'll shut up and learn to
cope.

Dave


newer versions of gcc will object too,
> so you might as well get the types right now.



gcc 4.0 is a particularly painful experience when compiling open sourced
codes I've seen that didn't pay attention to pointer target signedness.

Dave