Date: Wed, 28 Mar 2001 11:07:12 -0800 From: Eric Melville <eric@meow.osd.bsdi.com> To: Chris Faulhaber <jedgar@fxp.org> Cc: freebsd-audit@freebsd.org Subject: Re: [murray@osd.bsdi.com: Re: quick patch to window(1)] Message-ID: <20010328110712.A99250@meow.osd.bsdi.com> In-Reply-To: <20010328082738.A3405@sushi.44bsd.net>; from jedgar@fxp.org on Wed, Mar 28, 2001 at 08:27:38AM -0500 References: <20010327092052.A56508@meow.osd.bsdi.com> <20010328082738.A3405@sushi.44bsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > % < && (cx.x_val.v_str = str_cpy(buf)) == 0) {
> > % ---
> > % > && (cx.x_val.v_str = (void *)str_cpy(buf)) == 0) {
>
> Why the cast? v_str (aka v_un.V_str) is char*, the same that str_cpy()
> returns...
Yes, you are right. It's just that the compiler gets upset on this line,
claiming the assignment makes a pointer from an integer value without
cast. A bit sloppy of me, I didn't actually look at str_cpy() itself,
but simply forced the thing to be a pointer. Now, the question is, why
the complaint from the compiler in the first place? If I go and cast
it to (char *), the compiler remains happy. A bit odd considering that
str_cpy() is declared as this type to begin with.
> Of course, it would probably be better if the hand-rolled str_cpy()
> and str_ncpy() went away and replaced with strdup()/strlcpy() and some
> error checking (of which window(1) seems to do very little).
Yeah, but I was just trying to make it compile clean ;)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010328110712.A99250>