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
