memcpy segfaults, but not in windows

Hi

Having a lil trouble with a rather simple application I'm writing. It so happens that I have to copy some data using memcpy() and so far I've been doing just fine compiling it with VC.Net and running it on Windows XP. Now I'm trying to port the thing to Solaris (which shouldn't really be too big a deal) and for some reason it is causing problems.

int SendPacket(unsigned short packNo, const char* data, unsigned short sSize){
	int addrlen = sizeof(struct sockaddr);
	int iRet = 0;
	PutShortAt(buffer, OP_DATA);	// Insert DATA op code
	PutShortAt(buffer + 2, packNo);	// Insert packet number
	memcpy(buffer + 4, data, sSize); // Insert the actual data
	iRet = sendto(iSock, buffer, sSize + 4, 0, (struct sockaddr *)&sraddr,addrlen);	// Send packet

	printf("Sent %d bytes\n", iRet);
	return IOK;
}

The line which causes the segfault is the memcpy() line. Basically, what I'm trying to do is this;

const char* data contains 512 bytes of arbitrary data that is to be added to a 516 byte packet which will then be transmitted to a computer somewhere on the internet. Byte 4-516 will contain the data. The first 4 bytes in the packet are reserved for packet information in the form of two shorts. sSize is of course the data size.

Any ideas as to what may be causing this? Like I said earlier, it runs just fine on Windows (of course with the appropriate modifications to net code, winsock and such). Any help would be greatly appreciated.

Where is buffer defined? What value is in sSize? It's one of those two things. Mostly likely buffer is too small.

And to check the obvious, you are including <string.h>, yes? On some systems/configurations, omitting a header can cause things like memcpy to segfault from calling memcpy with the wrong function definition etc.

Yes I think your problem is the buffer variable, where dir you define it and how did you define it,

if you just defined it in a global variable like this,

char * buffer, then definetely you have a problem or they are right the buffer would be too small..

It run in windows because I experience some window based C/C++ compiler allow you to access memory that was not allocated or that is not belongs to you.