0

I am totally stumped. I have been debugging this for hours. I am allocating a table of 100 UInt32s by 100. I am loading a table of values and writing them to the 2D array. For some bizarre reason when I get to row 67, column 0 the writes appear to wrap back around to row 0 element 0.

I have rewritten it to allocate a list of arrays rather than a single malloc. Same exact behavior. I have tried doing math for the index: _map[row * 100 + column] instead of _map[i,j] and that leads to other strange behavior. I was thinking maybe something is overflowing, but I can't see how since the data is so small. Obviously I am doing something stupid but I just... can't.. see it.

Code snippet:

_map = malloc(100 * 100 * sizeof(UInt32));

int i = 0;
for (i=0; i <_columns; i++)
{
    columnList = [[lineList objectAtIndex:i] componentsSeparatedByString:@","];
    int j = 0;
    for (j=0; j < _rows; j++)
    {
        UInt32 dataInt = atoi([[columnList objectAtIndex:j] UTF8String]);

        // Convert the data
        NSDictionary* tDict = [fileMap objectForKey:[NSString stringWithFormat:@"%i", dataInt]];
        int newVal = [[tDict objectForKey:@"convert"] integerValue];

        _map[i,j] = (UInt32)newVal;

        UInt32 y =  _map[i,j];

        // This trips at row 67 element 0
        if (_map[0,0] != 1)
            printf("Here\n");



    }
}

Any help would be absolutely most awesomely appreciated.

As I mention below, this code gives the same problem in that it corrupts the first line. As if every row is the same row:

    int** testMap = malloc(100 * 100 * sizeof(int));
    int data = 0;
    for (int i = 0; i<100; i++)
    {
        for (int j = 0; j < 100; j++)
        {
            testMap[i, j] = data;
            data++;
            printf("(%i, %i)", i,j);
        }
        printf ("\n");
    }
user3692811
  • 1
  • 2
  • _map is defined as UInt32** – user3692811 Jun 01 '14 at 02:55
  • 1
    umm.. This is ObjC, not quite the same as C. – Yeraze Jun 01 '14 at 02:56
  • Side note - why bother with `dataInt`? You take an `NSString` (`columnList[j]`) and convert it to a C string which is converted to a `UIInt32`. You then convert the `UIInt32` back to an `NSString`. That's a lot of pointless conversions. – rmaddy Jun 01 '14 at 03:05
  • How does `_map[0,0]` "trip" at row 67? Do you mean `_map[i,j]`? – rmaddy Jun 01 '14 at 03:07
  • The trip statement is detecting when _map[0,0] is changing from its original value of 1 to something else. The loop appears to be wrapping around at row 67, column 0. @maddy.. I'll clean it up once I get the data populating correctly. Fair point though, thanks. I am just tripping over what is up with the population. I suppose I could write a loop to populate it with basic data to see if that's the cause. – user3692811 Jun 01 '14 at 03:25
  • Not related to your problem but you should check if malloc returns NULL. – ForguesR Jun 01 '14 at 03:36
  • `integerValue` gives you an NSInteger, which might be a long, and you assign it to an int... Is that a warning? Regardless, I don't see how it causes the problem you have. You could try `intValue` to be safe. – stevesliva Jun 01 '14 at 04:44
  • This code gives the same problem. It corrupts the first position of the array as it goes. Its almost as if its treating every row as the same row when it writes. Which is bizarre: int** testMap = malloc(100 * 100 * sizeof(UInt32)); int data = 0; for (int i = 0; i<100; i++) { for (int j = 0; j < 100; j++) { testMap[i, j] = data; data++; printf("(%i, %i)", i,j); } printf ("\n"); } – user3692811 Jun 01 '14 at 05:18
  • My c is rusty, but finally `[i,j]` begins to look incorrect. Shouldn't it be `[i][j]`?? `[i,j]` would seemingly to evaluate to `[j]` for the purposes of getting the offset from the beginning of the array. I'd also think that you need a unidimensional array of UInt32* pointers to unidimensional arrays of UInt32s rather than a single chunk of UInt32s, since UInt32* (an address) could be 64bits. – stevesliva Jun 01 '14 at 05:58
  • Thanks Steve. That was the correct answer. I guess I thought my casts were negating the bit size differences. Thank you very, very much. Now I can go to sleep :-) – user3692811 Jun 01 '14 at 06:31

0 Answers0