From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60603140847v3b5b4ad2x8775f0e3348614cb@mail.gmail.com> Date: Tue, 14 Mar 2006 08:47:39 -0800 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] porting linux program for beginners In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16348_5081246.1142354859701" References: <1d5d51400603140804m72eddf8jd4474a9f7ef0b23c@mail.gmail.com> Cc: Topicbox-Message-UUID: 13f4b7c0-ead1-11e9-9d60-3106f5b1d025 ------=_Part_16348_5081246.1142354859701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/14/06, C H Forsyth 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 ------=_Part_16348_5081246.1142354859701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 3/14/06, C H Forsyth <forsyt= h@vitanuova.com> wrote:
the compiler shows the linear type representation it uses internally.
IN= D is `indirect', a pointer, or *
UCHAR is `unsigned char'
CONST is ob= viously `const'
so in

dumb_input.c:249[stdin:1718] argument proto= type mismatch "IND UCHAR" for "IND CONST CHAR": strlen

        you're passing an u= nsigned char* to strlen, which expects const char* (or char*)

the co= mpiler could possibly translate them back to normal C declarator form
fr= om 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 alwa= ys 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 cons= t *

and

int * const

are not the same :)

So whe= n I read:
"IND CONST CHAR"

my brain is already "w= ired up" to think of that as

char * const

not

char const *

or equivalentl= y

const char *

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

Dave
 

newer versions of gcc will object too,
so you might as well get the type= s right now.


gcc 4.0 is a particularly painful exp= erience when compiling open sourced codes I've seen that didn't pay attenti= on to pointer target signedness. =20

Dave
 


------=_Part_16348_5081246.1142354859701--