By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,234 Members | 1,872 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,234 IT Pros & Developers. It's quick & easy.

`sock_create' undeclared (first use this function)

P: n/a
Hello,
when I try to compile the following code with g++ -o client client.c
#include<sys/socket.h>
#include<stdio.h>
#include<stdlib.h>

#define ADDRESS "mysocket";
#define MAXLEN 200;

int main(int argc, char *argv)
{
int sd;
struct sockaddr_un sa;
int length;
char netmsg[MAXLEN];

if((sd=sock_create(AF_UNIX, SOCK_STREAM, 0))<0){
perror("Cannot create Socket");
exit(1);
}
sa.sun_family=AF_UNIX;
sa.sun_path=ADDRESS;
length=sizeof(sa.sun_family)+strlen(sa.sun_path);

if(bind(sd, (sockaddr_un*)&sa, length)<0){
perror("Couldn´t bind socket");
exit(1);
}
if(connect(sd, (sockaddr_un*)&sa, length)<0){
perror("Cannot connect to server");
exit(1);
}
if(send(sd, (char*) netmsg, MAXLEN)<0, 0){
perror("Cannot send message over network");
exit(1);
}
if(recv(sd, (char*) netmsg, MAXLEN, 0)<0){
perror("Message Receive failed");
exit(1);
}
if(close(sd)<0){
perror("Cannot close socket");
exit(1);
}

}

I get this message from the compiler:

client.c: In function `int main(int, char*)':
client.c:11: error: aggregate `sockaddr_un sa' has incomplete type and
cannot be defined
client.c:13: error: expected primary-expression before "char"
client.c:13: error: expected `;' before "char"
client.c:13: error: expected primary-expression before ']' token
client.c:13: error: expected `;' before ']' token
client.c:15: error: `sock_create' undeclared (first use this function)
client.c:15: error: (Each undeclared identifier is reported only once
for each function it appears in.)
client.c:21: error: `strlen' undeclared (first use this function)
client.c:31: error: `netmsg' undeclared (first use this function)
client.c:31: error: expected `)' before ';' token
client.c:31: error: expected `)' before ';' token
client.c:31: error: expected primary-expression before ')' token
client.c:31: error: expected `;' before ')' token
client.c:35: error: expected `)' before ';' token
client.c:35: error: expected `)' before ';' token
client.c:35: error: expected primary-expression before ',' token
client.c:35: error: expected `;' before ')' token
client.c:39: error: `close' undeclared (first use this function)
Can anybody help me what I have done wrong? I have no idea what to do.
It would be nice if somebody could help me to solve this problem.

Thanks,
Peter
Dec 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a

"Peter Rothenbuecher" <pr******@hrz.uni-frankfurt.de> wrote in message
news:40*************@news.dfncis.de...
Hello,
when I try to compile the following code with g++ -o client client.c
#include<sys/socket.h>
#include<stdio.h>
#include<stdlib.h>

#define ADDRESS "mysocket";
#define MAXLEN 200;

int main(int argc, char *argv)
{
int sd;
struct sockaddr_un sa;

^^^^^^^

The first problem you should tackle is to remove that struct statement here.
It should read "sockaddr_un sa" only to create an object of type sockadd_un.
Then recompile and look if there are other problems. Furthermore, I'd
suggest to remove those old legacy headers and replace them with standard
C++ ones, namely <cstdio> and <cstdlib>

[SNIP]

HTH
Chris
Dec 16 '05 #2

P: n/a
Peter Rothenbuecher wrote:
Hello,
when I try to compile the following code with g++ -o client client.c
#include<sys/socket.h>
This is a non-standard header and is thus off-topic here. You should
post in a newsgroup for your platform. See the FAQ for what is on-topic
here and for some suggestions for better newsgroups to post in:

http://www.parashift.com/c++-faq-lit...t.html#faq-5.9
#include<stdio.h>
#include<stdlib.h>
If you're doing C++ rather than C (which we assume since you're posting
here but which the coding style doesn't reflect), prefer:

#include <cstdio>
#include <cstdlib>

Better, prefer <iostream> and other C++ standard library headers.

#define ADDRESS "mysocket";
#define MAXLEN 200;
You probably don't want semicolons after these lines.

int main(int argc, char *argv)
You don't use argc and argv. Drop them.
{
int sd;
struct sockaddr_un sa;
int length;
char netmsg[MAXLEN];

[snip]

First, in C++, you should not declare variables until you can
initialize and use them. IOW, don't put all the declarations at the
top.

Second, it looks like sockaddr_un is undefined. Look in your
non-standard header <sys/socket.h> for the function prototype for
bind(), and you'll see what it should be called (probably just
sockaddr).

Cheers! --M

Dec 16 '05 #3

P: n/a

mlimber wrote:
Peter Rothenbuecher wrote:
#include<stdio.h>
#include<stdlib.h>


If you're doing C++ rather than C (which we assume since you're posting
here but which the coding style doesn't reflect), prefer:

#include <cstdio>
#include <cstdlib>


If you're suggesting that because <cxxx> headers are supposed to put C
library names in the std namespace rather than the global namespace, do
you know of any implementations that actually do that? Every time I've
tried it, I've been able to #include <cstdio> and use ::printf, which
is incorrect (I've tried this recently with VC++8, Comeau online and
whatever compiler is under the latest release of Dev-C++).

While violating the actual standard, this behaviour does seem to be the
de facto standard. Because <cxxx> headers let me compile technically
incorrect code becuase names are in the global namespace and the std
namespace, I prefer <xxx.h>. It might be deprecated, but I know my code
is correct.

Gavin Deane

Dec 16 '05 #4

P: n/a
Peter Rothenbuecher wrote:
#include<sys/socket.h>
#include<stdio.h>
#include<stdlib.h>
Also, add sys/un.h for sockaddr_un and
unistd.h for close().
#define ADDRESS "mysocket";
#define MAXLEN 200;
Remove the semi-colons.
if((sd=sock_create(AF_UNIX, SOCK_STREAM, 0))<0){
This should probably be socket(), not sock_create().
sa.sun_path=ADDRESS;
You will have to strcpy() this.
if(bind(sd, (sockaddr_un*)&sa, length)<0){
Cast to sockaddr.
if(connect(sd, (sockaddr_un*)&sa, length)<0){
Same goes here.
if(send(sd, (char*) netmsg, MAXLEN)<0, 0){


Do you see the typo?
--
Jan Vidar Krey
Unix Software Developer

Dec 16 '05 #5

P: n/a
de*********@hotmail.com wrote:
mlimber wrote:
Peter Rothenbuecher wrote:
#include<stdio.h>
#include<stdlib.h>


If you're doing C++ rather than C (which we assume since you're posting
here but which the coding style doesn't reflect), prefer:

#include <cstdio>
#include <cstdlib>


If you're suggesting that because <cxxx> headers are supposed to put C
library names in the std namespace rather than the global namespace, do
you know of any implementations that actually do that? Every time I've
tried it, I've been able to #include <cstdio> and use ::printf, which
is incorrect (I've tried this recently with VC++8, Comeau online and
whatever compiler is under the latest release of Dev-C++).

While violating the actual standard, this behaviour does seem to be the
de facto standard. Because <cxxx> headers let me compile technically
incorrect code becuase names are in the global namespace and the std
namespace, I prefer <xxx.h>. It might be deprecated, but I know my code
is correct.

Gavin Deane


Yes, my Texas Instruments C++ compiler puts all standard library
symbols in the std namespace only. The <cxxx> headers simply include
the <xxx.h> header which have something like this at the top:

#ifdef __cplusplus
//----------------------------------------------------------------------------
// <cstdlib> IS RECOMMENDED OVER <stdlib.h>. <stdlib.h> IS PROVIDED
FOR
// COMPATIBILITY WITH C AND THIS USAGE IS DEPRECATED IN C++
//----------------------------------------------------------------------------
extern "C" namespace std {
#endif /* !__cplusplus */

On this compiler, this code fails to compile without the "std::":

#include <cstdlib>

int main()
{
return std::rand();
}

Several (incorrect) implementations I have seen elsewhere just put
using declarations in the std namespace, thus providing C++
compatibility but leaving the global namespace polluted.

Cheers! --M

Dec 16 '05 #6

P: n/a
mlimber wrote:
de*********@hotmail.com wrote:
mlimber wrote:
<snip advice to prefer <cxxx> over <xxx.h> >
If you're suggesting that because <cxxx> headers are supposed to put C
library names in the std namespace rather than the global namespace, do
you know of any implementations that actually do that? Every time I've
tried it, I've been able to #include <cstdio> and use ::printf, which
is incorrect (I've tried this recently with VC++8, Comeau online and
whatever compiler is under the latest release of Dev-C++).

While violating the actual standard, this behaviour does seem to be the
de facto standard. Because <cxxx> headers let me compile technically
incorrect code becuase names are in the global namespace and the std
namespace, I prefer <xxx.h>. It might be deprecated, but I know my code
is correct.

Gavin Deane
Yes, my Texas Instruments C++ compiler puts all standard library
symbols in the std namespace only. The <cxxx> headers simply include
the <xxx.h> header which have something like this at the top:

#ifdef __cplusplus
//----------------------------------------------------------------------------
// <cstdlib> IS RECOMMENDED OVER <stdlib.h>. <stdlib.h> IS PROVIDED
FOR
// COMPATIBILITY WITH C AND THIS USAGE IS DEPRECATED IN C++
//----------------------------------------------------------------------------
extern "C" namespace std {
#endif /* !__cplusplus */


Interesting. My preference for <xxx.h>, for the reasons I've given, was
affirmed recently in an exchange with P J Plauger in this thread:

http://groups.google.co.uk/group/com...4db1c45cfe8733

He stated[*] that an admittedly simplified version of your ctsdlib

namespace std {
#include <stdlib.h>
}

is wrong, though I never asked him exactly what is wrong with it.

<snip>
Several (incorrect) implementations I have seen elsewhere just put
using declarations in the std namespace, thus providing C++
compatibility but leaving the global namespace polluted.


Indeed that is exactly my point. I wonder if it really is as simple as
Texas Instruments has made it, why some of those other implementations
(includeing Microsoft and Comeau, online at least) haven't managed to
do it.
[*] I don't think I am taking his words out of context, but any
misrepresentation here is my fault. Check the original source for
definitive quotes.

Gavin Deane

Dec 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.