Why do getaddrinfo and friends not work with c99?

[Nathan]

http://groups.google.com/group/comp.lang.c/browse_thread/thread/a51b90d9ed8580d6

I have a basic socket program written with calls to getaddrinfo. When
I compile using the --std=c99 option, it complains:
[ ~/src/_sandbox] gcc --std=c99 -Wall ipv6_test.c -o it
ipv6_test.c: In function `main':
ipv6_test.c:25: error: storage size of 'hints' isn't known
ipv6_test.c:34: warning: implicit declaration of function
`getaddrinfo'
ipv6_test.c:38: error: dereferencing pointer to incomplete type
...

But then when I remove --std=c99, it works.

Is there a way I can use these functions and still get c99
functionality without having to define any awkward symbols?

[ ~] gcc --version
gcc (GCC) 4.2.1 (SUSE Linux)

Thanks,
Nathan

[Thomas Maeder]

Nathan <nathan.i...@gmail.com> writes:

> I have a basic socket program written with calls to getaddrinfo. When
> I compile using the --std=c99 option, it complains:
> [ ~/src/_sandbox] gcc --std=c99 -Wall ipv6_test.c -o it
> ipv6_test.c: In function `main':
> ipv6_test.c:25: error: storage size of 'hints' isn't known
> ipv6_test.c:34: warning: implicit declaration of function
> `getaddrinfo'
> ipv6_test.c:38: error: dereferencing pointer to incomplete type
> ...
>
> But then when I remove --std=c99, it works.
>
> Is there a way I can use these functions and still get c99
> functionality without having to define any awkward symbols?

That would depend on how you attempt to using them.

ipv6_test.c seems not to #include the header that declares
getaddrinfo(), but apart from that, we don't know anything about that
file.

Please post just enough of it to allow your audience to
copy&paste&compile&see what you are seeing.

[Nathan]

On Jun 19, 11:50 am, Thomas Maeder <mae...@glue.ch> wrote:

Sorry, I should have added that when I remove --std=c99 then it
compiles fine. I have definitely #included the necessary headers.

=======================
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <stdio.h>
#include <assert.h>

#include <netinet/in.h>
#include <net/if.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <unistd.h>
#include <errno.h>

int
main(int argc, char** argv)
{
int sock = -1;
int n;
struct addrinfo* ai;
struct addrinfo* ai_stored;
struct addrinfo hints;
char buffer[256];

assert(argc > 2);

memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
n = getaddrinfo(argv[1], argv[2], &hints, &ai);

return 0;
}
=================

That snippet should reproduce the problem adequately. Try compiling
with and without the std=c99 switch.

Nathan

[shyuser]

<snipped>

> Sorry, I should have added that when I remove --std=c99 then it
> compiles fine. I have definitely #included the necessary headers.
>

<snipped>

> That snippet should reproduce the problem adequately. Try compiling
> with and without the std=c99 switch.
>
> Nathan

Nathan,

I am not an expert into these topics (not at all), but as far as I can see
in features.h, if you activate std=c99 you are activating also STRICT_ANSI,
in which case you need to indicate explictly that you want POSIX compliance
in order for getaddrinfo and struct addrinfo to work. Please try something
like

gcc -D_POSIX_SOURCE -std=c99

Hope it helps and best regards

[Nathan]

On Jun 21, 1:37 pm, shyuser <shyu...@anonymous.notvalid.org> wrote:
> <snipped>
>
> > Sorry, I should have added that when I remove --std=c99 then it
> > compiles fine. I have definitely #included the necessary headers.
>
> <snipped>
>
> > That snippet should reproduce the problem adequately. Try compiling
> > with and without the std=c99 switch.

Looks like that works as well. Thanks for the help!

For those keeping score at home, I filed a bug with gcc and they said
that I should talk with the libc folks. I haven't had the time to go
spelunking through that code to determine if the problem exists with a
vanilla libc or if it's due to changes in this particular distro, so I
haven't gotten in touch with them yet.

Nathan