strange c behavior (aliasing rule, solved)

[short]

Hey guys, I was coding up a networking project when I ran into the most peculiar behavior I couldn't explain, anyone care to take a stab?

Code: Select all

// Send and receive the DNSRequest message
void Send_Receive_DNSRequest(struct DNS_BEGIN* bmsg, unsigned char* buffer, char* argvone)
{
    int res, size, sockfd, sizeof_serv_addr;
    struct sockaddr_in serv_addr;
    struct hostent* server;
    unsigned char* url;

    // allocate memory for the buffer
    buffer = (unsigned char*) malloc( sizeof(unsigned char) * BUFFER_SIZE);

    // clear buffer
    bzero(buffer, BUFFER_SIZE);

    // set bmsg to point to the beginning of the buffer
    bmsg = (struct DNS_BEGIN*)buffer;

    // add to size
    // The size of the struct DNS_BEGIN is 24
    size =  sizeof(struct DNS_BEGIN); 

    // set the url to point to the correct spot in the buffer
    // This sets the url to point 12 bytes into buffer
    url = (unsigned char*)(buffer + size/2);

    // The size of the struct DNS_BEGIN is 24
    ...
}

The weird behavior I get is later on I call a function

Code: Select all

    // Convert the address the user provided to the format expected by DNS protocol.
    ConvertHostName_DNSFormat(argvone, (char*)url);

which takes the string pointed to by argvone and converts it and stores it to the memory location pointed to by url (byte 12 of buffer). If I comment out the line that sets the bmsg pointer, this works perfectly. If I don't comment out the line that sets the bmsg pointer then it will not write the url to the 12th byte of buffer. If I set url to point to the 24th byte of buffer it writes the string just fine.

It seems that having bmsg pointing to the beginning of buffer prevents any other write operations (to the first 24 bytes of buffer) from executing using any other pointer then bmsg.

Anyone see anything I'm missing?

edit: I did figure out a workaround, but this was particularily strange to me

[short]

Ok let me try another example that should make the point more clear..

Code: Select all

    // allocate memory for the buffer
    unsigned char* buffer = (unsigned char*) malloc( sizeof(unsigned char) * BUFFER_SIZE);
    unsigned char* url;

    bzero(buffer, BUFFER_SIZE);

    struct myType
    {
       short a;
	    short b;
	    short c;
	    short d;
    };
    // assuming short is 2 bytes on your architecture, sizeof(struct myType) = 8

    struct myType* ptr;

    // set ptr to beginning of buffer pointer
    ptr = (struct myType*) buffer;
    
    // set url to 4 bytes in
    url = &buffer[4];
    
    // attempt to copy "lala" to buffer[4] (buffer[4] is obviously within the first 8 bytes of buffer
    // this will fail to write anything
    strcpy((char*)url, "lala");

To contrast with

Code: Select all

    // allocate memory for the buffer
    unsigned char* buffer = (unsigned char*) malloc( sizeof(unsigned char) * BUFFER_SIZE);
    unsigned char* url;

    bzero(buffer, BUFFER_SIZE);

    struct myType
    {
       short a;
	    short b;
	    short c;
	    short d;
    };
    // assuming short is 2 bytes on your architecture, sizeof(struct myType) = 8

    struct myType* ptr;

    // set ptr to beginning of buffer pointer
    // the only change here is to comment out setting the ptr pointer
    //ptr = (struct myType*) buffer;
    
    // set url to 4 bytes in
    url = &buffer[4];
    
    // attempt to copy "lala" to buffer[4] (buffer[4] is obviously within the first 8 bytes of buffer
    // this will NOT fail since i commented out setting the ptr pointer
    strcpy((char*)url, "lala");

Anyone see why setting the ptr pointer in the first example would prevent the strcpy() function from writing to that memory location (buffer[4])?

[bnpph]

What's your compiler? Command line?

It's probably due to some strict aliasing rule. You can either disable it, or get around it with unions or gcc/intel attribute "__may__alias__"

[short]

What's your compiler? Command line?

It's probably due to some strict aliasing rule. You can either disable it, or get around it with unions or gcc/intel attribute "__may__alias__"

aliasing rule? I'm unfamiliar.

I'm using gcc to compile this project on linux

I looked it up, undefined rules huh, interesting.

I think this answers it:

http://stackoverflow.com/questions/2771 ... s-in-c-gcc

[avansc]

you dont ever allocate memory for URL and also

this.


url = buffer[4];

you might wanna look at what that means.. cause i dont think its what you think.

[short]

you dont ever allocate memory for URL and also

this.


url = buffer[4];

you might wanna look at what that means.. cause i dont think its what you think.

yay for writing code in a hurry, fixed

url = &buffer[4]

I didn't think I needed to allocate room for "url" because since it's pointing to midway through buffer, it should store there, no?

[avansc]

yes, if you use the url pointer to point to some allocated memory you dont have to, just make sure that you dont over write the bounds. cause it will most likely corrupt the stack.

you can also write it as

url = buffer+4;

[short]

fair enough, this seems to be becoming an adventurer of exploring the dark corners of C at this point. Thank you

[bnpph]

yes, if you use the url pointer to point to some allocated memory you dont have to, just make sure that you dont over write the bounds. cause it will most likely corrupt the stack.

I think you mean heap

[Ginto8]

yes, if you use the url pointer to point to some allocated memory you dont have to, just make sure that you dont over write the bounds. cause it will most likely corrupt the stack.

I think you mean heap

It can be either depending on the situation, although as I haven't looked at the code personally, in this case it very well may be the heap.

[short]

It can be either depending on the situation, although as I haven't looked at the code personally, in this case it very well may be the heap.

Wow, thanks for your insight ......

[dandymcgee]

It can be either depending on the situation, although as I haven't looked at the code personally, in this case it very well may be the heap.

Wow, thanks for your insight ......

Lmao.

[Ginto8]

It can be either depending on the situation, although as I haven't looked at the code personally, in this case it very well may be the heap.

Wow, thanks for your insight ......

being unhelpful while seeming otherwise is a skill of mine