From owner-freebsd-hackers  Tue Nov  7  8:43:16 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from ringworld.oblivion.bg (pool153-tch-1.Sofia.0rbitel.net [212.95.170.153])
	by hub.freebsd.org (Postfix) with SMTP id F3C6137B479
	for <hackers@FreeBSD.ORG>; Tue,  7 Nov 2000 08:43:09 -0800 (PST)
Received: (qmail 14283 invoked by uid 1000); 7 Nov 2000 16:42:53 -0000
Date: Tue, 7 Nov 2000 18:42:53 +0200
From: Peter Pentchev <roam@orbitel.bg>
To: Chris BeHanna <behanna@zbzoom.net>
Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, hackers@FreeBSD.ORG
Subject: Re: umask(2) and -Wconversion
Message-ID: <20001107184253.D4407@ringworld.oblivion.bg>
Mail-Followup-To: Chris BeHanna <behanna@zbzoom.net>,
	Giorgos Keramidas <keramida@ceid.upatras.gr>, hackers@FreeBSD.ORG
References: <20001107121734.D314@ringworld.oblivion.bg> <Pine.BSF.4.21.0011071129430.7959-100000@topperwein.dyndns.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0011071129430.7959-100000@topperwein.dyndns.org>; from behanna@zbzoom.net on Tue, Nov 07, 2000 at 11:32:11AM -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message