From: NickC on
On Sat, 12 Dec 2009 03:24:14 +0000, Beej Jorgensen wrote:
>
>>gcc now complains that:
>>passing argument 1 of 'read' makes integer from pointer without a cast.
>
> Are you sure this warning is on the popen() line? On my gcc install,
> putting the (void*) in the popen() call causes it to build warning-free.
>

Thanks for the reply. You are right, it's from read(), see my other reply
previously. I'm now using fread() with no problems. I'd confused an fd
with a FILE, mistakenly assuming they were the same thing.


--
NickC
From: Jens Thoms Toerring on
NickC <reply-to(a)works.fine.invalid> wrote:
> Ok, will do, thanks for this detail. I had in the back of my mind some
> advice somewhere in "Joy of C" that talked about casting parameters to
> ensure the correct type and avoid these warning msgs, but perhaps that
> advice was written before C compilers got as advanced as they are now, esp
> gcc.

There actually are a few situation where you have no choice but
to cast, one prominent one is the connect(2) function, which
expects as it's second argument a 'const struct sockaddr *' but
where this can be a different beast, depending on if this for a
AF_UNIX socket or "real" network socket (the third argument with
the size of what you actually passed allows the function to figure
out what it got - if I got that wrong Beej Jorgensen, who also ans-
wered you question will be able to explain it much better than me
since he's a well-known expert on socket programming). Another
place where a cast is prudent to use a cast is with the is*() func-
tions from <ctype.h> (isdigit(), isascii() etc.) where there is an
ambiguity due to some systems having signed and others unsigned
chars when you have a unqualified "char", and you get around that
by casting the argument to unsigned char. And, finally, there are
some issues with variadic functions, i.e. functions that have an
unspecified number of arguments (the ones with '...' at the end of
the argument list) and instead rely on a "format string" that tells
the function about the types of the arguments covered by '...'. Here
it's also sometimes necessary to cast the types of the arguments to
make sure they fit exactly what's stated in the format string.

So there are some cases where casts of function arguments actually
make sense or even are required. But out of the three examples I
came up with above only the first one would result in the compiler
emitting a warning. So all situations that seem to require a cast to
keep the compiler from warning you should make you wary and inves-
tigate what's going on - admittedly that might be a bit tedious but
it's normally worth the effort.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Beej Jorgensen on
On 12/12/2009 03:56 PM, Jens Thoms Toerring wrote:
> There actually are a few situation where you have no choice but to
> cast, one prominent one is the connect(2) function [snip] if I got
> that wrong Beej Jorgensen, who also answered you question will be able
> to explain it much better than me since he's a well-known expert on
> socket programming).

You got it right--except the word "expert" is probably a little bit
strong. Actually the whole sockets API uses this liberally in a variety
of calls as a form of C inheritance.

-Beej

From: Jens Thoms Toerring on
Beej Jorgensen <beej(a)beej.us> wrote:
> On 12/12/2009 03:56 PM, Jens Thoms Toerring wrote:
> > There actually are a few situation where you have no choice but to
> > cast, one prominent one is the connect(2) function [snip] if I got
> > that wrong Beej Jorgensen, who also answered you question will be able
> > to explain it much better than me since he's a well-known expert on
> > socket programming).

> You got it right--except the word "expert" is probably a little bit
> strong.

Well, as the author of the very often cited guide on network
programming - for those who haven't bookmarked it yet it's at

http://beej.us/guide/bgnet/

- calling you an expert doesn't seem to me to be too far off the
mark, at least it indicates that a lot of people think you know
very well what you're talking about;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Barry Margolin on
In article <03335604$0$1328$c3e8da3(a)news.astraweb.com>,
NickC <reply-to(a)works.fine.invalid> wrote:

> On Fri, 11 Dec 2009 23:56:55 +0000, Jens Thoms Toerring wrote:
>
>
> > programming in C I haven't got this warning once without good reasons
> > but because I made a stupid mistake.
>
> Yep, spot on. I *know* it needed a string yet I was fixated on char,
> probably a hangover from the old BASIC days (I very rarely do FILE stuff

I think you mean "holdover". A hangover is what you get from drinking
too much, although that could also cause you to make programming
mistakes.

> in C, probably the last time was 10 years ago).

I was guessing it was a holdover from Perl, which doesn't have a char
type, and uses both "" and '' to delimit strings. It's been more than
25 years since I've programmed in BASIC, but I don't recall it using ''
for strings (IIRC, ' was used to introduce comments).

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***