From owner-freebsd-hackers Wed Nov 8 1:35:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id C9B2A37B479 for ; Wed, 8 Nov 2000 01:35:48 -0800 (PST) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 7615EA82B; Wed, 8 Nov 2000 20:35:48 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 6F47E5465; Wed, 8 Nov 2000 19:35:48 +1000 (EST) Date: Wed, 8 Nov 2000 19:35:48 +1000 (EST) From: andrew@ugh.net.au To: Giorgos Keramidas Cc: "Albert D. Cahalan" , hackers@FreeBSD.ORG, roam@orbitel.bg Subject: Re: umask(2) and -Wconversion In-Reply-To: <20001108072630.A58596@gray.westgate.gr> Message-ID: X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The #defines dont matter as cc never sees them so line 11 is seen as func(0) 0 will be an int by default. When this call is made a 32 bit int with a value of 0 will be pushed onto the stack. When func is executed this 32 bit value is cast to a 16 bit short and this causes a warning to be emitted. Even if line 11 was func((short)0) then the 16 bit 0 would be promoted to a 32 bit 0 as its pushed on the stack and the same problem would occur. I think anyway...as I said earlier I haven't actually loooked at the gcc source. Andrew On Wed, 8 Nov 2000, Giorgos Keramidas wrote: > Agreed. But, obviously, this is not what happens when I compile my test > program posted earlier in this thread: > > 1 #include > 2 > 3 #define VALUE 0 > 4 > 5 int func (short x); > 6 > 7 int main (void) > 8 { > 9 int var = 10; > 10 > 11 func(VALUE); > 12 return 0; > 13 } > 14 > 15 int func (short var) > 16 { > 17 printf("var: %d\n", var); > 18 return 0; > 19 } > > Even though I have a cast at line 9 that one would expect to inhibit There is? > such a warning, the warning remains. This is what happens when one > tries to compile programs that use umask(2) with -Wconversion. Macros umask is taking a 16 bit number off a 32 bit stack... > My original question was if this is not behavior that should be > considered buggy, since the size of VALUE has not been determined to be > equal to sizeof(int) when the #define occurs, or has it? No it has. It is compiled in as a 32bit int unless you qualify it. None the less I dont think a warning should be emitted in these cases, that is when it leaves one function as 16bit and arrives at another as 16bit. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message