From mint-bounce@lists.fishpool.fi Sun Sep 5 17:13:50 2010 To: Peter Slegg Subject: Re: [MiNT] [Highwire] gcc4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Sun, 05 Sep 2010 23:10:36 +0200 From: m0n0 Cc: Reply-To: ole@monochrom.net In-Reply-To: <006732cb.01c29262200a@smtp.freeola.net> References: <006732cb.01c29262200a@smtp.freeola.net> Message-ID: <1795eb7469ca8b2f02bc24bbfb84b7c2-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBTXF5bVkYPXkF3CVI6XF1XQkIAXlpaRg==-webmailer2@server06.webmailer.hosteurope.de> X-Sender: ole@monochrom.net User-Agent: Host Europe Webmailer/2.0 X-HE-Access: Yes X-bounce-key: webpack.hosteurope.de;ole@monochrom.net;1283721036;63ee2a86; X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: ole@monochrom.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Am Sonntag, den 05.09.2010, 20:28 +0200 schrieb Peter Slegg : > I have just "fixed" them by making more use of CHAR* in the function > interface. Oh, now I see "buffer" is an CHAR... so converting it to an CHAR* is not good! And my example wasn't, too. It should be like this: decGif_read (IMGINFO info, CHAR buffer) { GifPixelType *pixelType = (GifPixelType*)&buffer; ... ! You can't just change an function argument from CHAR to CHAR* - that's completely different stuff! An CHAR occupies 1 BYTE, but an CHAR* is 4 Bytes long... > I have just hit these which I am not familiar with: > > error: cast discards qualifiers from pointer target type > something to do with volatiles. Most time you get this "error" is because you pass an "const char * " to an function that needs an char*... So doing that cast manually should make gcc happy. Strings defined in structs are often const char * - without explicitly saying so. It's because you define the string somewhere in the sources.... > > I have just tried compiling without -Wall as an experiment and it fails > with a real error with the last, nasty line here: No, it's not just the last line... > *p_answ++ /*[0]*/ = GS_REPLY; > *p_answ++ /*[1]*/ = gl_apid; > *p_answ++ /*[2]*/ = 0; > *((long **)p_answ)++/*[3..4]*/ = gsi_; > > AEI.c: In function 'process_messages': > AEI.c:1555:5: error: lvalue required as increment operand > AEI.c:1559:5: error: lvalue required as increment operand > It's trying to asign a value to something that has been ++ incremented > so is itself a value. Not good. Should it be split into two > lines and values assigned to p_answ 3 and 4 or just 4 ? I think you should get informed about the data that is getting handled, comment the above line out, write your own line of code - and if it works, than it's fine . No, I think just assigning the half side of an long ptr will be the wrong way. Greets, m