Pointer row addresses have unexpected numbers

Discussion in 'C Programming' started by Malcolm Nooning, Dec 11, 2010.

  1. I can see that in the pasted results of the code snippet (also pasted
    below), there are 48 decimal bytes between rows of an array. The
    coded subtraction of row addresses is showing 12 instead of 48. I
    cannot figure out why. I see the same result on my Windows cygwin and
    my Linux CentOS boxes. Any idea what is going on?

    //----------- Paste code snippet
    #include <stdio.h>
    #include <stdlib.h>
    int main(void)
    {
    int nrows = 5; /* Both nrows and ncols could be evaluated */
    int ncols = 10; /* or read in at run time */
    int row;
    int **rowptr;

    rowptr = malloc(nrows * sizeof(int *));

    if (rowptr == NULL)
    {
    puts("\nFailure to allocate room for row pointers.\n");
    exit(0);
    }

    printf("\nIndex &rowptr[row] &rowptr[row][0] Ptr(hex) Ptr(dec)
    Diff(dec)");

    for (row = 0; row < nrows; row++)
    {
    rowptr[row] = malloc(ncols * sizeof(int));
    if (rowptr[row] == NULL)
    {
    printf("\nFailure to allocate for row[%d]\n",row);
    exit(0);
    }
    printf("\n %d %u %u %p %d",
    row, &rowptr[row], &rowptr[row][0], rowptr[row],
    rowptr[row] );
    if (row > 0)
    printf(" %d",(int)(rowptr[row] - rowptr[row-1]));
    }

    return 0;
    }
    //-----------------------------------------
    // Results
    //
    // Index &rowptr[row] &rowptr[row][0] Ptr(hex) Ptr(dec) Diff(dec)
    // 0 6685048 6750616 0x670198 6750616
    // 1 6685052 6750664 0x6701c8 6750664 12
    // 2 6685056 6750712 0x6701f8 6750712 12
    // 3 6685060 6750760 0x670228 6750760 12
    // 4 6685064 6750808 0x670258 6750808 12
    Malcolm Nooning, Dec 11, 2010
    #1
    1. Advertising

  2. Malcolm Nooning

    Nobody Guest

    On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:

    > I can see that in the pasted results of the code snippet (also pasted
    > below), there are 48 decimal bytes between rows of an array. The
    > coded subtraction of row addresses is showing 12 instead of 48. I
    > cannot figure out why. I see the same result on my Windows cygwin and
    > my Linux CentOS boxes. Any idea what is going on?


    The result of subtracting two pointers is the number of *elements* between
    the pointers, not the number of bytes. 12 integers is 48 bytes.
    Nobody, Dec 11, 2010
    #2
    1. Advertising

  3. On Sat, 11 Dec 2010 11:24:37 -0500, Malcolm Nooning
    <> wrote:

    > I can see that in the pasted results of the code snippet (also pasted
    > below), there are 48 decimal bytes between rows of an array. The
    > coded subtraction of row addresses is showing 12 instead of 48.


    And without looking at any of your code, I can tell you that you're
    subtracting pointers, and that
    sizeof(whatever type the pointers point to) == 4.
    --
    Morris Keesan --
    Morris Keesan, Dec 11, 2010
    #3
  4. On Dec 11, 11:35 am, Nobody <> wrote:
    > On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    > > I can see that in the pasted results of the code snippet (also pasted
    > > below), there are 48 decimal bytes between rows of an array.  The
    > > coded subtraction of row addresses is showing 12 instead of 48.  I
    > > cannot figure out why.  I see the same result on my Windows cygwin and
    > > my Linux CentOS boxes.  Any idea what is going on?

    >
    > The result of subtracting two pointers is the number of *elements* between
    > the pointers, not the number of bytes. 12 integers is 48 bytes.


    But, there are 10 integers (int ncols = 10) per row, not 12.
    Where do the extra two come from?
    Malcolm Nooning, Dec 11, 2010
    #4
  5. Malcolm Nooning

    Ian Collins Guest

    On 12/12/10 06:28 AM, Malcolm Nooning wrote:
    > On Dec 11, 11:35 am, Nobody<> wrote:
    >> On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    >>> I can see that in the pasted results of the code snippet (also pasted
    >>> below), there are 48 decimal bytes between rows of an array. The
    >>> coded subtraction of row addresses is showing 12 instead of 48. I
    >>> cannot figure out why. I see the same result on my Windows cygwin and
    >>> my Linux CentOS boxes. Any idea what is going on?

    >>
    >> The result of subtracting two pointers is the number of *elements* between
    >> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >
    > But, there are 10 integers (int ncols = 10) per row, not 12.
    > Where do the extra two come from?


    Probably housekeeping space used by the allocator.

    --
    Ian Collins
    Ian Collins, Dec 11, 2010
    #5
  6. On Dec 11, 2:52 pm, Ian Collins <> wrote:
    > On 12/12/10 06:28 AM, Malcolm Nooning wrote:
    >
    > > On Dec 11, 11:35 am, Nobody<>  wrote:
    > >> On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    > >>> I can see that in the pasted results of the code snippet (also pasted
    > >>> below), there are 48 decimal bytes between rows of an array.  The
    > >>> coded subtraction of row addresses is showing 12 instead of 48.  I
    > >>> cannot figure out why.  I see the same result on my Windows cygwin and
    > >>> my Linux CentOS boxes.  Any idea what is going on?

    >
    > >> The result of subtracting two pointers is the number of *elements* between
    > >> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >
    > > But, there are 10 integers (int ncols = 10) per row, not 12.
    > > Where do the extra two come from?

    >
    > Probably housekeeping space used by the allocator.
    >
    > --
    > Ian Collins


    No, that cannot be.
    The C books tell us that whenever two pointers are subtracted we get
    the number of the elements between what they point to. This is the
    gist of what "Nobody", and Morris Keesan, were stating above.
    However, just going by that, the answers should all be 10, not 12. A
    programmer would need to rely on the results of pointer subtraction
    being well defined. There is something else going on, and I would
    really like to get a solid understanding of what it is.
    Malcolm Nooning, Dec 11, 2010
    #6
  7. Malcolm Nooning

    Ian Collins Guest

    On 12/12/10 09:37 AM, Malcolm Nooning wrote:
    > On Dec 11, 2:52 pm, Ian Collins<> wrote:
    >> On 12/12/10 06:28 AM, Malcolm Nooning wrote:
    >>
    >>> On Dec 11, 11:35 am, Nobody<> wrote:
    >>>> On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    >>>>> I can see that in the pasted results of the code snippet (also pasted
    >>>>> below), there are 48 decimal bytes between rows of an array. The
    >>>>> coded subtraction of row addresses is showing 12 instead of 48. I
    >>>>> cannot figure out why. I see the same result on my Windows cygwin and
    >>>>> my Linux CentOS boxes. Any idea what is going on?

    >>
    >>>> The result of subtracting two pointers is the number of *elements* between
    >>>> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >>
    >>> But, there are 10 integers (int ncols = 10) per row, not 12.
    >>> Where do the extra two come from?

    >>
    >> Probably housekeeping space used by the allocator.

    >
    > No, that cannot be.


    Oh yes it can!

    > The C books tell us that whenever two pointers are subtracted we get
    > the number of the elements between what they point to.


    To pointers within the same object. Your rowptr[row] and rowptr[row-1]
    are the results of different allocations.

    > A
    > programmer would need to rely on the results of pointer subtraction
    > being well defined.


    It is....

    > There is something else going on, and I would
    > really like to get a solid understanding of what it is.


    ....but not between pointers in different blocks.


    --
    Ian Collins
    Ian Collins, Dec 11, 2010
    #7
  8. Malcolm Nooning

    Willem Guest

    Malcolm Nooning wrote:
    ) On Dec 11, 2:52?pm, Ian Collins <> wrote:
    )> Probably housekeeping space used by the allocator.
    )
    ) No, that cannot be.
    ) The C books tell us that whenever two pointers are subtracted we get
    ) the number of the elements between what they point to. This is the
    ) gist of what "Nobody", and Morris Keesan, were stating above.
    ) However, just going by that, the answers should all be 10, not 12. A
    ) programmer would need to rely on the results of pointer subtraction
    ) being well defined. There is something else going on, and I would
    ) really like to get a solid understanding of what it is.

    It's really very easy.
    You're comparing the results of *different calls* to malloc().
    The books are talking about *one* array or block.
    You're comparing apples and oranges.

    The standard sais that comparing pointers that point into two different
    objects (i.e. two different calls to malloc(), or two static arrays,
    or whatever), gives undefined results.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
    Willem, Dec 11, 2010
    #8
  9. On Dec 11, 3:41 pm, Ian Collins <> wrote:
    > On 12/12/10 09:37 AM, Malcolm Nooning wrote:
    >
    >
    >
    > > On Dec 11, 2:52 pm, Ian Collins<>  wrote:
    > >> On 12/12/10 06:28 AM, Malcolm Nooning wrote:

    >
    > >>> On Dec 11, 11:35 am, Nobody<>    wrote:
    > >>>> On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    > >>>>> I can see that in the pasted results of the code snippet (also pasted
    > >>>>> below), there are 48 decimal bytes between rows of an array.  The
    > >>>>> coded subtraction of row addresses is showing 12 instead of 48.  I
    > >>>>> cannot figure out why.  I see the same result on my Windows cygwin and
    > >>>>> my Linux CentOS boxes.  Any idea what is going on?

    >
    > >>>> The result of subtracting two pointers is the number of *elements* between
    > >>>> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >
    > >>> But, there are 10 integers (int ncols = 10) per row, not 12.
    > >>> Where do the extra two come from?

    >
    > >> Probably housekeeping space used by the allocator.

    >
    > > No, that cannot be.

    >
    > Oh yes it can!
    >
    > > The C books tell us that whenever two pointers are subtracted we get
    > > the number of the elements between what they point to.

    >
    > To pointers within the same object.  Your rowptr[row] and rowptr[row-1]
    > are the results of different allocations.
    >
    > > A
    > > programmer would need to rely on the results of pointer subtraction
    > > being well defined.

    >
    > It is....
    >
    > > There is something else going on, and I would
    > > really like to get a solid understanding of what it is.

    >
    > ...but not between pointers in different blocks.
    >
    > --
    > Ian Collins


    Aha! That is the answer. To be explicit for those as dull as myself,
    in the snippet below
    rowptr[0] = malloc(ncols * sizeof(int));
    The contents of rowptr[0] is a pointer to 10 integers.
    The contents of rowptr[1] is also pointer to 10 integers, but that
    pointer could be pointing anywhere the compiler found free memory for
    it, which is not necessarily contiguous with that of rowptr[0]. Thus,
    there is no "right" answer for the subtraction (int)(rowptr[row] -
    rowptr[row-1]). It does not even have to be consistent. It just
    happened to be 12 consistently because the compiler found contiguously
    free memory each malloc. The other 2 elements might be housekeeping,
    but it might be for absolutely nothing. My gcc has been around for 20
    years, so I suppose it is pretty efficient by now. It is undoubtedly
    for housekeeping.

    Thanks, Ian
    Malcolm Nooning, Dec 11, 2010
    #9
  10. Nobody <> writes:
    > On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    >> I can see that in the pasted results of the code snippet (also pasted
    >> below), there are 48 decimal bytes between rows of an array. The
    >> coded subtraction of row addresses is showing 12 instead of 48. I
    >> cannot figure out why. I see the same result on my Windows cygwin and
    >> my Linux CentOS boxes. Any idea what is going on?

    >
    > The result of subtracting two pointers is the number of *elements* between
    > the pointers, not the number of bytes. 12 integers is 48 bytes.


    Furthermore, the behavior of subtracting two pointers to separately
    allocated objects (which is what the program in the original post
    does) is undefined.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 11, 2010
    #10
  11. On Sat, 11 Dec 2010 09:28:24 -0800 (PST), Malcolm Nooning
    <> wrote:

    >On Dec 11, 11:35 am, Nobody <> wrote:
    >> On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    >> > I can see that in the pasted results of the code snippet (also pasted
    >> > below), there are 48 decimal bytes between rows of an array.  The
    >> > coded subtraction of row addresses is showing 12 instead of 48.  I
    >> > cannot figure out why.  I see the same result on my Windows cygwin and
    >> > my Linux CentOS boxes.  Any idea what is going on?

    >>
    >> The result of subtracting two pointers is the number of *elements* between
    >> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >
    >But, there are 10 integers (int ncols = 10) per row, not 12.
    >Where do the extra two come from?


    Firstly, there is no requirement for the results of separate calls to
    malloc to be in any order. The fact that they are 48 bytes apart is
    just an artifact of your particular implementation.

    Secondly, the first call to printf in the for loop invokes undefined
    behavior so none of the results can be trusted.

    Thirdly, if malloc succeeds it must allocate at least as much space as
    you asked for but it can allocate more and use the excess to contain
    control information (such as the amount of space to free). I expect
    on your system the eight bytes in front of the returned value are
    used for this or a similar purpose.

    What I do find a little surprising is that rowptr[0] contains a value
    over 0x10000 away from &rowptr[4]. Given that all five elements of
    rowptr contain addresses close to each other, I would have expected
    these five areas to follow closely after rowptr in memory. It's
    almost as if the first call to printf allocated (and freed) some
    temporary space and it is not being reused.

    Of course, &rowptr[row][0] and rowptr[row] must always be the same
    value, even if you choose to print it in two different bases.

    --
    Remove del for email
    Barry Schwarz, Dec 11, 2010
    #11
  12. Malcolm Nooning

    Nobody Guest

    On Sat, 11 Dec 2010 09:28:24 -0800, Malcolm Nooning wrote:

    >> The result of subtracting two pointers is the number of *elements* between
    >> the pointers, not the number of bytes. 12 integers is 48 bytes.

    >
    > But, there are 10 integers (int ncols = 10) per row, not 12.
    > Where do the extra two come from?


    That's a different issue.

    Subtraction of pointers is only defined when both pointers point within
    the same array (or to the element immediately past the end of the array),
    so your code provokes undefined behaviour.

    The reason why it happens in this specific case is that glibc's malloc()
    always returns a pointer aligned to a 16-byte boundary, so it's not
    possible for two pointers returned from malloc() to differ by 40 bytes.

    If your array elements had been structures whose size wasn't either a
    multiple or fraction of 16, the difference (in bytes) between the
    two pointers wouldn't necessarily have been a multiple of the
    structure's size, so the result of the subtraction would be meaningless.

    The C standard only requires that pointers returned from malloc() meet the
    largest alignment requirements for any standard type. glibc just happens
    to be a bit more conservative (16 bytes is likely to satisfy the
    standard's requirement on any platform which is likely to exist within the
    foreseeable future).

    If you have larger alignment requirements (e.g. for SIMD calculations or
    page-aligned blocks), you have to either use an alternative (and
    non-portable) allocation mechanism or over-allocate and extract a suitably
    aligned region yourself.
    Nobody, Dec 12, 2010
    #12
  13. My god,

    Are you saying you have been programming in C for over 20 years and only now
    do you understand a pointer array ?

    Wow... just wow lol.

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #13
  14. "Nobody" <> wrote in message
    news:p...
    > On Sat, 11 Dec 2010 08:24:37 -0800, Malcolm Nooning wrote:
    >
    >> I can see that in the pasted results of the code snippet (also pasted
    >> below), there are 48 decimal bytes between rows of an array. The
    >> coded subtraction of row addresses is showing 12 instead of 48. I
    >> cannot figure out why. I see the same result on my Windows cygwin and
    >> my Linux CentOS boxes. Any idea what is going on?

    >
    > The result of subtracting two pointers is the number of *elements* between
    > the pointers, not the number of bytes. 12 integers is 48 bytes.


    What a bullshit.

    But then again the C language is bullshit.

    So what you are saying is you are either wrong, or you are incomplete.

    It turns out you are not wrong, it turns out you are incomplete.

    The correct answer is it depends on the pointer TYPE. So C is no different
    than typed pointers in pascal. Except only difference is pascal pointers do
    not allow pointer arithmetic by default. Also subtracting pointers in
    pascal/delphi not possible.Unless perhaps a compiler directive is used the
    new pointer math directive... which probably means pointers are treated as
    memory addresses which are simply integers pointing towards the smallest
    addressable element in virtual memory which in PC's is a byte.

    Long story short your bullshit was interesting in another way.

    // int *vA;
    // int *vB;

    void *vA;
    void *vB;

    vA = &vArray[3];
    vB = &vArray[4];

    printf("%d \n", vB - vA);


    It turns out C can't even do pointer arithemtic like Delphi can.

    For such a powerfull language "as they used to claim C was" back in the old
    ms-dos days it has fallen in grace... if it ever had such a thing.

    All this time I was actually under the impression that C could do pointer
    arithmetic but apperently it cannot.

    The only thing it can apperently do is treat a typed pointer as an array...
    big fokking whoopie.

    Not being able to use untyped pointers for simply virtual memory byte
    arithmetic is absolutely beyond me ! hahahaha... yes yes insert your nagging
    "most be cross-platform compatible" BS.

    Let me know when you try to compile code that was written for a byte based
    memory system which is then used for something else like a 7 bit system.

    Though I can imagine it might work... never seen it though. So perhaps this
    little part of the rant don't hold, but yet it might.

    I just like to point out to everybody that Delphi is now actually more
    powerfull than C at the pointer area !

    An area where C is famous for...

    Now go eat your hart out ! ;)

    I will stop now before your heart explodes of anger ! ;) =D

    Haha,
    Bye,
    Skybuck ;) :)
    Skybuck Flying, Dec 13, 2010
    #14
  15. Hmmm... not having used the new directive much yet... I still don't know
    what it can quite do...

    It appears I was wrong and the people at embarc keep head in ass:

    program Project1;

    {$APPTYPE CONSOLE}

    {$POINTERMATH ON}

    uses
    SysUtils;

    procedure Main;
    var
    vArray : array[0..9] of integer;
    vA : pointer;
    vB : pointer;
    vC : pointer;
    begin
    vA := @vArray[4];
    vB := @vArray[5];
    vC := vB - vA; // does not compile.

    writeln( integer(vC) );
    end;

    begin
    try
    Main;
    except
    on E: Exception do
    Writeln(E.ClassName, ': ', E.Message);
    end;
    ReadLn;
    end.

    Pretty annoying.

    Oh well... me crawl back into my Delphi cave.

    Pretend like nothing happened, because that's exactly what happened.

    Ok not quite true...

    At least now Delphi can work with typed pointers unlike these untyped
    pointers above...

    I am so sure of it... I am not even going to test it ?!

    Noooo ofcourse I am going to test it lol:

    Fucking unbelievable... even this **** doesn't compile:

    procedure Main;
    var
    vArray : array[0..9] of integer;
    vA : pointer;
    vB : pointer;
    vC : pointer;

    vFuckYouBitchesA : Pbyte;
    vFuckYouBitchesB : Pbyte;
    vFuckYouBitchesC : Pbyte;
    begin
    vA := @vArray[4];
    vB := @vArray[5];
    // vC := vB - vA;

    writeln( integer(vC) );


    vFuckYouBitchesA := @vArray[4];
    vFuckYouBitchesB := @vArray[5];
    vFuckYouBitchesC := vFuckYouBitchesB - vFuckYouBitchesA;

    writeln( integer(vC) );

    end;

    **** the bitches at embarcadero... for making my live more difficult than
    absolutely need to be.

    Well at least we still have strong type checking.

    I take back everything I said about C.

    C can still go **** people like you guys in the ASS... haha.

    Someday Delphi will be what it should be...

    Someday...

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #15
  16. I hate fags that say an untyped pointer points to nothing.

    It's even in the Delphi help:

    "
    This directive affects only typed pointers. Variables of type Pointer do not
    allow the pointer math features, since type Pointer is effectively pointing
    to a void element, which is 0 bytes in size. Untyped var or const parameters
    are not affected because they are not really pointers.
    "

    Like a pointer can point to nothing and something at the same time...

    It's absolutely rubbish.

    Keep C rubbish out of Delphi me says.

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #16
  17. I shall give a better definition of what an untyped pointer should be in
    Delphi:

    "An untyped pointer is a pointer that points to the basic allocation unit of
    the memory system."

    That might sound a bit too technically related to memory manager, though
    that too plays a roll in the background.

    Though it's probably suited.

    It could be augmented by a different view of a pointer because it can be
    looked upon from different perspectives:

    "An untyped pointer contains an address which range corresponds to the range
    of the memory system."

    Also not completely through, virtual memory has 2 GB usually available.
    Yet the pointer is 32 bit... but that last bit can be ignored and is not
    important.

    Pointers could be said to be 31 bit, which is important to understand it's
    range in this specific memory system case: 2^31

    Try three:

    "An untyped pointer is the basic pointer type which allows to address each
    individual element of the memory system."

    I think that last one nails it on the head.

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #17
  18. "Malcolm Nooning" <> wrote in message
    news:...
    >I can see that in the pasted results of the code snippet (also pasted
    > below), there are 48 decimal bytes between rows of an array. The
    > coded subtraction of row addresses is showing 12 instead of 48. I
    > cannot figure out why. I see the same result on my Windows cygwin and
    > my Linux CentOS boxes. Any idea what is going on?
    >
    > //----------- Paste code snippet
    > #include <stdio.h>
    > #include <stdlib.h>
    > int main(void)
    > {
    > int nrows = 5; /* Both nrows and ncols could be evaluated */
    > int ncols = 10; /* or read in at run time */
    > int row;
    > int **rowptr;



    Your naming convention also sucks pretty bad.

    This should have been
    rowptrptr

    which might have alerted you to your stupidity.

    Or better Delphi/Skybuck style:

    PointerArrayPointerArray[6] - PointerArrayPointerArray[5]

    If this doesn't trigger any bells when you wrote that BS code then I don't
    know what will in your shit-code-case ! ;) :)

    OH WAITTT I guess that's why Delphi has multi dimensional array support
    which C doesn't have OOOOPPPSSIIEE I guess C is old-fart-news after all.

    vPointer : array of array of pointer;

    SetLength( vPointer, 10, 10 );

    Now trying to make stupid mistake that you do:

    vPointer[6] - vPointer[5];

    Hey mister where is that second dimension ?!

    Well ofcourse here it is:

    vPointer[6,0] fuckyou vPointer[5,0]

    Even better:

    @vPointer[6,0] fuckyou @vPointer[5,0]

    Always nice.

    Of course you code style is bullshit anyway because any normal sane delphi
    programmer would write:

    vInteger : array of array of integer;

    vInteger[6,0] - vInteger[5,0]

    See how nice Delphi is ?!?

    And how stupid your C is with all that RIDICILOUS DUMB PTR crap ! ;) :)

    LOLOLOLOLOL

    I LOL IN YOUR FACE ;) :) =D

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #18
  19. Sorry forgot to own you in Delphi newsgroup as well.

    And when I say "you" I mean all C programmers and C language designers
    HAHAHAHA LOL. With a little thanks to embarc.. (and others pasc.)

    Repost:

    "Malcolm Nooning" <> wrote in message
    news:...
    >I can see that in the pasted results of the code snippet (also pasted
    > below), there are 48 decimal bytes between rows of an array. The
    > coded subtraction of row addresses is showing 12 instead of 48. I
    > cannot figure out why. I see the same result on my Windows cygwin and
    > my Linux CentOS boxes. Any idea what is going on?
    >
    > //----------- Paste code snippet
    > #include <stdio.h>
    > #include <stdlib.h>
    > int main(void)
    > {
    > int nrows = 5; /* Both nrows and ncols could be evaluated */
    > int ncols = 10; /* or read in at run time */
    > int row;
    > int **rowptr;



    Your naming convention also sucks pretty bad.

    This should have been
    rowptrptr

    which might have alerted you to your stupidity.

    Or better Delphi/Skybuck style:

    PointerArrayPointerArray[6] - PointerArrayPointerArray[5]

    If this doesn't trigger any bells when you wrote that BS code then I don't
    know what will in your shit-code-case ! ;) :)

    OH WAITTT I guess that's why Delphi has multi dimensional array support
    which C doesn't have OOOOPPPSSIIEE I guess C is old-fart-news after all.

    vPointer : array of array of pointer;

    SetLength( vPointer, 10, 10 );

    Now trying to make stupid mistake that you do:

    vPointer[6] - vPointer[5];

    Hey mister where is that second dimension ?!

    Well ofcourse here it is:

    vPointer[6,0] fuckyou vPointer[5,0]

    Even better:

    @vPointer[6,0] fuckyou @vPointer[5,0]

    Always nice.

    Of course you code style is bullshit anyway because any normal sane delphi
    programmer would write:

    vInteger : array of array of integer;

    vInteger[6,0] - vInteger[5,0]

    See how nice Delphi is ?!?

    And how stupid your C is with all that RIDICILOUS DUMB PTR crap ! ;) :)

    LOLOLOLOLOL

    I LOL IN YOUR FACE ;) :) =D

    Bye,
    Skybuck.
    Skybuck Flying, Dec 13, 2010
    #19
  20. On Dec 12, 8:00 pm, "Skybuck Flying" <>
    wrote:
    > My god,
    >
    > Are you saying you have been programming in C for over 20 years and only now
    > do you understand a pointer array ?
    >
    > Wow... just wow lol.
    >
    > Bye,
    >   Skybuck.


    You misinterpreted. I am saying that gcc has been around for 20 years.
    Malcolm Nooning, Dec 13, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. moondaddy
    Replies:
    3
    Views:
    633
    Steven Cheng[MSFT]
    Apr 5, 2004
  2. nik
    Replies:
    1
    Views:
    249
    Gernot Frisch
    Aug 1, 2006
  3. namespace1
    Replies:
    3
    Views:
    890
  4. Casey Hawthorne
    Replies:
    3
    Views:
    1,079
    Flash Gordon
    Nov 1, 2009
  5. D
    Replies:
    0
    Views:
    203
Loading...

Share This Page