Re: umask(2) and -Wconversion
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 stdio.h
2
3#define VALUE 0
4
5int func (short x);
6
7int main (void)
8{
9int var = 10;
10
11func(VALUE);
12return 0;
13}
14
15int func (short var)
16{
17printf("var: %d\n", var);
18return 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
Giorgos Keramidas writes: 3#define VALUE 0 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? The size of VALUE is not the issue; the type is `int' in the line quoted above. If you want VALUE to be a `short', you need to say: #define VALUE ((short) 0) -- Greg Black [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
umask(2) and -Wconversion
While trying to compile libskey with various warnings enabled, I
discovered the following funny thing about -Wconversion and umask(2),
which caused libskey to fail to compile, because it compiles by default
with -Werror which makes every warning fatal.
I found that the warning is caused when a program that calls umask(2) is
compiled with -Wconversion. The info page of gcc says about -Wconversion:
`-Wconversion'
Warn if a prototype causes a type conversion that is different
from what would happen to the same argument in the absence of a
prototype. This includes conversions of fixed point to floating
and vice versa, and conversions changing the width or signedness
of a fixed point argument except when the same as the default
promotion.
Also, warn if a negative integer constant expression is implicitly
converted to an unsigned type. For example, warn about the
assignment `x = -1' if `x' is unsigned. But do not warn about
explicit casts like `(unsigned) -1'.
The following test program when compiled with -Wconversion shown below
will always give a warning, even if I explicitly try to cast the
argument of umask() to mode_t.
1 #include stdio.h
2 #include sys/stat.h
3
4 int main (void)
5 {
6 mode_t oldmask;
7
8 oldmask = umask(0);
9 printf("The umask has changed\n");
10 umask(oldmask);
11 return 0;
12 }
The output given when I compile this with -Wconversion is:
gray-charon:/home/charon/test% gcc -Wconversion test.c -o test
test.c: In function `main':
test.c:8: warning: passing arg 1 of `umask' with different width due to prototype
test.c:10: warning: passing arg 1 of `umask' with different width due to prototype
The problem is that even if I change line 8 to read:
8 oldmask = umask((mode_t) 0);
the warning is still there. Am I being a bit too strict with all these
warnings here? If not, does anyone else have any idea why umask(2) will
always cause such a warning, and how I can go about correcting it?
Casting obviously fails, so something else needs to be done.
--
Giorgos Keramidas, [EMAIL PROTECTED]
For my public pgp2 key: finger -l [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants - even if I explicitly cast them to a long or unsigned
long or plain unsigned int or whatever the particular function needs,
GCC seems to ignore the cast and whines about the conversion nonetheless :(
Can anybody else confirm this? I can't dig out a code snippet right now,
but ISTR a recurring case of this when compiling with BDECFLAGS a program
which includes ncurses.h, then passes integer constants to init_pair()
or something similar.
G'luck,
Peter
--
If there were no counterfactuals, this sentence would not have been paradoxical.
On Tue, Nov 07, 2000 at 12:05:11PM +0200, Giorgos Keramidas wrote:
While trying to compile libskey with various warnings enabled, I
discovered the following funny thing about -Wconversion and umask(2),
which caused libskey to fail to compile, because it compiles by default
with -Werror which makes every warning fatal.
I found that the warning is caused when a program that calls umask(2) is
compiled with -Wconversion. The info page of gcc says about -Wconversion:
`-Wconversion'
Warn if a prototype causes a type conversion that is different
from what would happen to the same argument in the absence of a
prototype. This includes conversions of fixed point to floating
and vice versa, and conversions changing the width or signedness
of a fixed point argument except when the same as the default
promotion.
Also, warn if a negative integer constant expression is implicitly
converted to an unsigned type. For example, warn about the
assignment `x = -1' if `x' is unsigned. But do not warn about
explicit casts like `(unsigned) -1'.
The following test program when compiled with -Wconversion shown below
will always give a warning, even if I explicitly try to cast the
argument of umask() to mode_t.
1#include stdio.h
2#include sys/stat.h
3
4int main (void)
5{
6mode_t oldmask;
7
8oldmask = umask(0);
9printf("The umask has changed\n");
10umask(oldmask);
11return 0;
12}
The output given when I compile this with -Wconversion is:
gray-charon:/home/charon/test% gcc -Wconversion test.c -o test
test.c: In function `main':
test.c:8: warning: passing arg 1 of `umask' with different width due to prototype
test.c:10: warning: passing arg 1 of `umask' with different width due to
prototype
The problem is that even if I change line 8 to read:
8oldmask = umask((mode_t) 0);
the warning is still there. Am I being a bit too strict with all these
warnings here? If not, does anyone else have any idea why umask(2) will
always cause such a warning, and how I can go about correcting it?
Casting obviously fails, so something else needs to be done.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, Nov 07, 2000 at 12:17:34PM +0200, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants - even if I explicitly cast them to a long or unsigned
long or plain unsigned int or whatever the particular function needs,
GCC seems to ignore the cast and whines about the conversion nonetheless :(
Can anybody else confirm this? I can't dig out a code snippet right now,
but ISTR a recurring case of this when compiling with BDECFLAGS a program
which includes ncurses.h, then passes integer constants to init_pair()
or something similar.
Yes, that is what I was trying to do. I wanted to buildworld with
BDECFLAGS in a 4.2-BETA installation and libskey among other things just
bombed when compiling. I tracked the problem to -Wconversion being too
strict about the arguments passed to umask, but this seems to be a GCC
problem not a problem with umask() :///
I tried compiling the following little program with -Wconversion and it
causes the same warning:
1 #include stdio.h
2
3 int func (short x);
4
5 int main (void)
6 {
7 int var = 10;
8
9 func((short) var);
10 return 0;
11 }
12
13 int func (short var)
14 {
15 printf("var: %d\n", var);
16 return 0;
17 }
The cast to (short) in line 9 does not inhibit the warning when the
-Wconversion option of gcc is used as shown below:
gray% gcc -Wconversion test2.c
test2.c: In function `main':
test2.c:9: warning: passing arg 1 of `func' with different width due to prototype
I think that I will remove -Wconversion from my BDECFLAGS and move on
with compiling my world. On a side-note, the -ansi and -pedantic flags
also caused a few problems, and I deleted them from my BDECFLAGS last
night.
Moving on with my quest to remove as many warnings from /usr/src as
possible...
- giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, 7 Nov 2000, Giorgos Keramidas wrote: discovered the following funny thing about -Wconversion and umask(2), I spent quite a while trying to silence that warning in one of my programs the otherday but I decided it was probably harmless and left it. and vice versa, and conversions changing the width or signedness of a fixed point argument except when the same as the default promotion. I think this is what we are hitting. From memory mode_t is a u_int16_t. When you pass 0 (a 32 bit number) it gets cast to a 16 bit number (change of width) and so produces the warning. I think the reason that the cast doesn't help (or passing a u_int16_t) is that when the 16 bit number gets passed it has to be placed on the 32 bit stack which promotes it so you will always end up with a demotion when the number is taken from the stack and given to umaks as a 16 bit int. OTH I could be wrong :-) I haven't looked at the gcc source. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, Nov 07, 2000 at 11:30:05PM +1000, [EMAIL PROTECTED] wrote: On Tue, 7 Nov 2000, Giorgos Keramidas wrote: discovered the following funny thing about -Wconversion and umask(2), I spent quite a while trying to silence that warning in one of my programs the otherday but I decided it was probably harmless and left it. The warning in itself is rather harmless, since it does not cause much trouble. However some parts of a FreeBSD world are compiled with -Werror, and every warning is considered an error that causes compilation to abort : Anyway, this is getting more and more off-topic, since it's obviously something caused by GCC's strictness when -Wconversion is used. I think the reason that the cast doesn't help (or passing a u_int16_t) is that when the 16 bit number gets passed it has to be placed on the 32 bit stack which promotes it so you will always end up with a demotion when the number is taken from the stack and given to umaks as a 16 bit int. I thought that the cast would help because the size of (mode_t) is known in compile time, and I expected the compiler to place the result of an expression like `(mode_t) 0' in a properly sized integer type. I mean, one would expect that ((short) 0) would be different than ((int) 0); isn't the compiler supposed to know the diference, if both types have sizes that are known at compile time? Whatever... I will also remove -Wconversion from my make.conf CFLAGS and move on. This is probably discussed with the GCC fellows. I will sum up what this thread was all about, and post a mail to their lists tomorrow. I'm too tired to write to them right now. - giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, 7 Nov 2000, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants - even if I explicitly cast them to a long or unsigned
long or plain unsigned int or whatever the particular function needs,
GCC seems to ignore the cast and whines about the conversion nonetheless :(
Can anybody else confirm this? I can't dig out a code snippet right now,
but ISTR a recurring case of this when compiling with BDECFLAGS a program
which includes ncurses.h, then passes integer constants to init_pair()
or something similar.
What happens if you pass an explicit long or unsigned long
literal instead of casting an integer literal? Like this:
void myfunc( unsigned long);
int
main( int argc, char* argv[])
{
myfunc( 12UL);
return 0;
}
I realize, of course, that going through and changing every array
subscript, for example, is a PITA. I'm just curious about whether or
not this makes gcc behave nicely.
--
Chris BeHanna
Software Engineer (at yourfit.com)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, Nov 07, 2000 at 11:32:11AM -0500, Chris BeHanna wrote:
On Tue, 7 Nov 2000, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants - even if I explicitly cast them to a long or unsigned
long or plain unsigned int or whatever the particular function needs,
GCC seems to ignore the cast and whines about the conversion nonetheless :(
Can anybody else confirm this? I can't dig out a code snippet right now,
but ISTR a recurring case of this when compiling with BDECFLAGS a program
which includes ncurses.h, then passes integer constants to init_pair()
or something similar.
What happens if you pass an explicit long or unsigned long
literal instead of casting an integer literal? Like this:
void myfunc( unsigned long);
int
main( int argc, char* argv[])
{
myfunc( 12UL);
return 0;
}
I realize, of course, that going through and changing every array
subscript, for example, is a PITA. I'm just curious about whether or
not this makes gcc behave nicely.
Actually, I just got hold of a code snippet - the problem is not only
with passing constants. A prime example is the init_pair() that I
already mentioned. In ncurses.h:
extern int init_pair(short,short,short);
I have:
typedef enum {
RS_CLR_NULL,
RS_CLR_MENU, RS_CLR_DLG,
RS_CLR_LAST
} rs_clr_t;
typedef struct {
short f, b;
} rs_clrpair_t;
static rs_clrpair_t rs_pairs[RS_CLR_LAST] = {
{COLOR_BLACK, COLOR_BLACK},
{COLOR_WHITE, COLOR_BLACK},
{COLOR_YELLOW, COLOR_BLUE}
};
rs_err_t
rs_color_init(void) {
short i;
start_color();
for(i = 0; i RS_CLR_LAST; i++)
init_pair(i, rs_pairs[i].f, rs_pairs[i].b);
return RS_ERR_NONE;
}
As you can see, I'm passing a short i as a first arg, a short f as second,
and a short b as third; and yet, gcc with BDECFLAGS complains about ALL
the arguments!
G'luck,
Peter
--
This sentence every third, but it still comprehensible.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
Peter Pentchev writes: As you can see, I'm passing a short i as a first arg, a short f as second, and a short b as third; and yet, gcc with BDECFLAGS complains about ALL the arguments! Yes, no kidding. That's what you asked gcc to do. `-Wconversion' Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. This includes conversions of fixed point to floating and vice versa, and conversions changing the width or signedness of a fixed point argument except when the same as the default promotion. The C language is crufty. In the absense of a prototype, "short" is promoted to "int". You wanted to be warned about that; you got it! To avoid the warning, avoid passing anything but "int" and "double". Maybe "long" is OK too, I forget. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
"Albert D. Cahalan" writes: The C language is crufty. In the absense of a prototype, "short" is promoted to "int". You wanted to be warned about that; you got it! To avoid the warning, avoid passing anything but "int" and "double". Maybe "long" is OK too, I forget. I'm not sure which C language you're talking about here, but I'll assume it's C89. In that language, in the absence of a prototype, (and in KR C), `int', `long', `double' and pointer types are not promoted; but signed or unsigned `char', `short', and `int' bit-fields are promoted; `float' is promoted. -- Greg Black [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Tue, 7 Nov 2000, Albert D. Cahalan wrote:
of a fixed point argument except when the same as the default
promotion.
snip
The C language is crufty. In the absense of a prototype, "short" is
promoted to "int". You wanted to be warned about that; you got it!
short going to int would be a default promotion and so shouldn't produce a
warning.
To avoid the warning, avoid passing anything but "int" and "double".
Maybe "long" is OK too, I forget.
No the secret is not to have any function arguments that aren't ints,
doubles etc. Its the cast from the default type on the stack to the non
default type to get in the function that produces the warning I think.
Take this example code:
void foo(int i);
void bar(short i);
int main() {
short s;
foo(s);
bar(s);
return(0);
}
void foo(int i) {
}
void bar(short i) {
}
When compiled with -Wconversion you get:
test10.c: In function `main':
test10.c:10: warning: passing arg 1 of `bar' with different width due to
prototype
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
On Wed, Nov 08, 2000 at 02:47:40PM +1000, [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2000, Albert D. Cahalan wrote:
The C language is crufty. In the absense of a prototype, "short" is
promoted to "int". You wanted to be warned about that; you got it!
short going to int would be a default promotion and so shouldn't produce a
warning.
Agreed. But, obviously, this is not what happens when I compile my test
program posted earlier in this thread:
1 #include stdio.h
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
such a warning, the warning remains. This is what happens when one
tries to compile programs that use umask(2) with -Wconversion. Macros
defined in sys/stat.h header, much like VALUE above are passed to a
function that expects a `short', and the warning is issued.
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?
- giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
