K&R2 Secition 5.9 - major blunders

Discussion in 'C Programming' started by TTroy, Mar 7, 2005.

  1. TTroy

    TTroy Guest

    I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    mentioned topics).

    K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    this...

    "Newcomers to C are somtimes confused about the difference between a
    two-dimensional array and an array of pointers..."

    then continues to explain int *b[10]; to be...

    "For b, however, the definition only allocates 10 pointers ... Assuming
    that each element of b does point to a twenty element array,then there
    will be 200 ints set aside, plus ten cells for pointers... "

    Is it just me, or is that explanation only valid for int (*b)[10];
    ????

    I'm pretty sure K&R2 is totally wrong in this section (had me confused
    for a while).

    Later on in section 5.9, it says "... by far the most frequent use of
    arrays of pointers is to store character strings of diverse lengths..."

    Once again, this seems totally wrong.
    char *strings[] = {"Bob","Dave","Jack");
    'strings' is only managing pointers to anonymous objects that are
    automatically created by the initialization (which there is no mention
    of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".

    All in all, K&R2 has been an amazing book, but this one section (which
    is often the hardest for beginners) makes it a less amazing book
    (rather average).

    Am I right here, or am I wrong (I'm pretty sure I'm right, but I still
    don't know how these mistakes could be in the book, considering the
    authors and the many decades it has been the bible).

    How come these errors weren't caught? How come none of the errata I
    have found mentions these? Am I totally wrong?
    TTroy, Mar 7, 2005
    #1
    1. Advertising

  2. TTroy wrote:
    > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    > mentioned topics).
    >
    > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > this...
    >
    > "Newcomers to C are somtimes confused about the difference between a
    > two-dimensional array and an array of pointers..."
    >
    > then continues to explain int *b[10]; to be...
    >
    > "For b, however, the definition only allocates 10 pointers ... Assuming
    > that each element of b does point to a twenty element array,then there
    > will be 200 ints set aside, plus ten cells for pointers... "
    >
    > Is it just me, or is that explanation only valid for int (*b)[10];
    > ????


    It's just you; and you are dead wrong.
    int *b[10];
    is the declaration for an array[10] of pointers to int.
    int (*b)[10];
    is the declaration for *one* pointer to an array[10] of int.

    >
    > I'm pretty sure K&R2 is totally wrong in this section (had me confused
    > for a while).


    You dead wrong. This is frequently the case for people who are "pretty
    sure" that a text that has been gone over carefully for some 30 years is
    wrong.

    >
    > Later on in section 5.9, it says "... by far the most frequent use of
    > arrays of pointers is to store character strings of diverse lengths..."
    >
    > Once again, this seems totally wrong.
    > char *strings[] = {"Bob","Dave","Jack");
    > 'strings' is only managing pointers to anonymous objects that are
    > automatically created by the initialization (which there is no mention
    > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".


    The use of the array of pointers is to store the strings. 'strings'
    doesn't do anything, so that it doesn't store is beside the point as
    much as that it doesn't do integrals. It's an array.
    Martin Ambuhl, Mar 7, 2005
    #2
    1. Advertising

  3. TTroy

    TTroy Guest

    TTroy wrote:
    > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    > mentioned topics).
    >
    > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > this...
    >
    > "Newcomers to C are somtimes confused about the difference between a
    > two-dimensional array and an array of pointers..."
    >
    > then continues to explain int *b[10]; to be...
    >
    > "For b, however, the definition only allocates 10 pointers ...

    Assuming
    > that each element of b does point to a twenty element array,then

    there
    > will be 200 ints set aside, plus ten cells for pointers... "
    >
    > Is it just me, or is that explanation only valid for int (*b)[10];
    >

    b above should be: int (*b[10])[20];
    TTroy, Mar 7, 2005
    #3
  4. TTroy

    TTroy Guest

    Martin Ambuhl wrote:
    > TTroy wrote:
    > > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the

    herein
    > > mentioned topics).
    > >
    > > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > > this...
    > >
    > > "Newcomers to C are somtimes confused about the difference between

    a
    > > two-dimensional array and an array of pointers..."
    > >
    > > then continues to explain int *b[10]; to be...
    > >
    > > "For b, however, the definition only allocates 10 pointers ...

    Assuming
    > > that each element of b does point to a twenty element array,then

    there
    > > will be 200 ints set aside, plus ten cells for pointers... "
    > >
    > > Is it just me, or is that explanation only valid for int (*b)[10];
    > > ????

    >
    > It's just you; and you are dead wrong.
    > int *b[10];
    >


    Each element of b doesn't point to a 20 element array of int. Each
    element of b points to an int. The authors should have said "Assuming
    that each element of b does point to an int which happens to be the
    first element of a 20 int array." This mistake is crucial because
    there really exists something totally different that fits their "not
    very accurate" description. This leads to confusion. If I point at a
    pencil and tell you that it's an instrument to write with and it has
    ink in it which is permanent, then that's a big mistake for two
    reasons: I'm 'slightly' off on my explanation of the pencil, and most
    importantly, my explanation is really the qualities of something else:
    a pen.

    >
    > is the declaration for an array[10] of pointers to int.
    > int (*b)[10];
    > is the declaration for *one* pointer to an array[10] of int.
    >


    Yeah, I meant int (*b[10])[20]; This exactly fits the description.

    > >
    > > I'm pretty sure K&R2 is totally wrong in this section (had me

    confused
    > > for a while).

    >
    > You dead wrong.
    >


    I gave an explanation as to why I thought K&R2 was wrong, but you gave
    no explanation to explain why I am 'dead wrong.' All you did was
    explain what thoise two definitions above were, without relating it to
    anything.

    >
    > This is frequently the case for people who are "pretty
    > sure" that a text that has been gone over carefully for some 30 years

    is
    > wrong.
    >


    I'm pretty sure it's wrong (the explanation is "close" to the truth,
    but since it's accurately describing something totally different,
    that's what makes it very wrong).

    >
    > >
    > > Later on in section 5.9, it says "... by far the most frequent use

    of
    > > arrays of pointers is to store character strings of diverse

    lengths..."
    > >
    > > Once again, this seems totally wrong.
    > > char *strings[] = {"Bob","Dave","Jack");
    > > 'strings' is only managing pointers to anonymous objects that are
    > > automatically created by the initialization (which there is no

    mention
    > > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".

    >
    > The use of the array of pointers is to store the strings.
    >


    No it's not, and thinking like this is dangerous. Say you have a
    structure that you want to have strings in it, if you chose to have a
    (char *) array in it, and you *think* it's holding the strings, you'll
    be in big trouble if you try to write the structure to a file. Arrays
    of pointers to char that point to anonymous string objects are just
    'managing' references to the strings (by pointing to their first
    characters).

    >
    > 'strings'
    > doesn't do anything, so that it doesn't store is beside the point as
    > much as that it doesn't do integrals. It's an array.


    Besides the point? If it isn't for the diagram that following their
    explanation, this would been a very dangerous mistake. Also there is
    no mention of how the strings are created or where they are actually
    stored, which compounds the mistake. And also again, the
    initialization with definition makes it look like the strings are
    actually being stored in the array too.

    ex:

    "... by far the most frequent use of
    arrays of pointers is to store character strings of diverse lengths..."

    followed by:

    char *strings[]= {"string1", "string2", "string3");

    This might confuse very many newbie readers (it didn't confuse me, but
    the mistake I mentioned above did). It *looks* like the strings are
    being stored in the array, and the literature above it implies storage.
    Plus the [] array notion also implies storage. Also the lack of
    explanation of how/where these strings are stored also implies they are
    stored in the strings array.



    All I'm requesting is all the people who maintain errata lists for this
    book take this into account.
    TTroy, Mar 7, 2005
    #4
  5. TTroy

    TTroy Guest

    Martin Ambuhl wrote:
    > TTroy wrote:
    > > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the

    herein
    > > mentioned topics).
    > >
    > > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > > this...
    > >
    > > "Newcomers to C are somtimes confused about the difference between

    a
    > > two-dimensional array and an array of pointers..."
    > >
    > > then continues to explain int *b[10]; to be...
    > >
    > > "For b, however, the definition only allocates 10 pointers ...

    Assuming
    > > that each element of b does point to a twenty element array,then

    there
    > > will be 200 ints set aside, plus ten cells for pointers... "
    > >
    > > Is it just me, or is that explanation only valid for int (*b)[10];
    > > ????

    >
    > It's just you; and you are dead wrong.
    > int *b[10];
    >


    Each element of b doesn't point to a 20 element array of int. Each
    element of b points to an int. The authors should have said "Assuming
    that each element of b does point to an int which happens to be the
    first element of a 20 int array." This mistake is crucial because
    there really exists something totally different that fits their "not
    very accurate" description. This leads to confusion. If I point at a
    pencil and tell you that it's an instrument to write with and it has
    ink in it which is permanent, then that's a big mistake for two
    reasons: I'm 'slightly' off on my explanation of the pencil, and most
    importantly, my explanation is really the qualities of something else:
    a pen.

    >
    > is the declaration for an array[10] of pointers to int.
    > int (*b)[10];
    > is the declaration for *one* pointer to an array[10] of int.
    >


    Yeah, I meant int (*b[10])[20]; This exactly fits the description.

    > >
    > > I'm pretty sure K&R2 is totally wrong in this section (had me

    confused
    > > for a while).

    >
    > You dead wrong.
    >


    I gave an explanation as to why I thought K&R2 was wrong, but you gave
    no explanation to explain why I am 'dead wrong.' All you did was
    explain what thoise two definitions above were, without relating it to
    anything.

    >
    > This is frequently the case for people who are "pretty
    > sure" that a text that has been gone over carefully for some 30 years

    is
    > wrong.
    >


    I'm pretty sure it's wrong (the explanation is "close" to the truth,
    but since it's accurately describing something totally different,
    that's what makes it very wrong).

    >
    > >
    > > Later on in section 5.9, it says "... by far the most frequent use

    of
    > > arrays of pointers is to store character strings of diverse

    lengths..."
    > >
    > > Once again, this seems totally wrong.
    > > char *strings[] = {"Bob","Dave","Jack");
    > > 'strings' is only managing pointers to anonymous objects that are
    > > automatically created by the initialization (which there is no

    mention
    > > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".

    >
    > The use of the array of pointers is to store the strings.
    >


    No it's not, and thinking like this is dangerous. Say you have a
    structure that you want to have strings in it, if you chose to have a
    (char *) array in it, and you *think* it's holding the strings, you'll
    be in big trouble if you try to write the structure to a file. Arrays
    of pointers to char that point to anonymous string objects are just
    'managing' references to the strings (by pointing to their first
    characters).

    >
    > 'strings'
    > doesn't do anything, so that it doesn't store is beside the point as
    > much as that it doesn't do integrals. It's an array.


    Besides the point? If it isn't for the diagram that following their
    explanation, this would been a very dangerous mistake. Also there is
    no mention of how the strings are created or where they are actually
    stored, which compounds the mistake. And also again, the
    initialization with definition makes it look like the strings are
    actually being stored in the array too.

    ex:

    "... by far the most frequent use of
    arrays of pointers is to store character strings of diverse lengths..."

    followed by:

    char *strings[]= {"string1", "string2", "string3");

    This might confuse very many newbie readers (it didn't confuse me, but
    the mistake I mentioned above did). It *looks* like the strings are
    being stored in the array, and the literature above it implies storage.
    Plus the [] array notion also implies storage. Also the lack of
    explanation of how/where these strings are stored also implies they are
    stored in the strings array.



    All I'm requesting is all the people who maintain errata lists for this
    book take this into account.
    TTroy, Mar 7, 2005
    #5
  6. "TTroy" <> writes:
    > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    > mentioned topics).
    >
    > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > this...
    >
    > "Newcomers to C are somtimes confused about the difference between a
    > two-dimensional array and an array of pointers..."
    >
    > then continues to explain int *b[10]; to be...
    >
    > "For b, however, the definition only allocates 10 pointers ... Assuming
    > that each element of b does point to a twenty element array,then there
    > will be 200 ints set aside, plus ten cells for pointers... "
    >
    > Is it just me, or is that explanation only valid for int (*b)[10];
    > ????
    >
    > I'm pretty sure K&R2 is totally wrong in this section (had me confused
    > for a while).


    I don't have my K&R2 handy, but the portion you quoted seems correct.

    int *b[10] declares an array of 10 pointers (each of which is a
    pointer-to-int). When K&R say the definition "only allocates 10
    pointers", they mean it allocates space for the pointer objects
    themselves, not for what they point to. Space for the 200 ints (10
    arrays of 20 elements each) has to be allocated separately.

    int (*b)[10] would declare a single pointer, pointing to an array of
    10 ints.

    > Later on in section 5.9, it says "... by far the most frequent use of
    > arrays of pointers is to store character strings of diverse lengths..."
    >
    > Once again, this seems totally wrong.
    > char *strings[] = {"Bob","Dave","Jack");
    > 'strings' is only managing pointers to anonymous objects that are
    > automatically created by the initialization (which there is no mention
    > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".


    Strictly speaking, the pointers don't store character strings; they
    point to character strings. It might have been a bit more precise to
    say that arrays of pointers are used to *manage* character strings if
    diverse lengths.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 7, 2005
    #6
  7. TTroy wrote:

    > Each element of b doesn't point to a 20 element array of int. Each
    > element of b points to an int.



    /*
    * You clearly have a conceptual problem. Let's try to address it. The
    * text says that we should *assume* that each element of b points to an
    * array of 20 ints, not that the declaration makes it so. How might
    * this happen?
    */
    #include <stdio.h>
    #include <stdlib.h>

    int main(void)
    {
    int *b[10];
    size_t i, j;

    for (i = 0; i < 10; i++)
    if (!(b = malloc(20 * sizeof *b))) {
    fprintf(stderr, "problem allocating b[%u]\n", (unsigned) i);
    for (j = 0; j < i; j++)
    free(b);
    }
    /* Each element of b now points to a region of memory whose contents
    is an array[20] of int. Indeed, each element of b points to an
    array[20] of int */

    for (i = 0; i < 10; i++)
    for (j = 0; j < 20; j++)
    b[j] = 100 * i + j;
    for (j = 0; j < 20; j++)
    for (i = 0; i < 10; i++)
    printf("%3d%c", b[j], (i == 9) ? '\n' : ' ');

    for (i = 0; i < 10; i++)
    free(b);
    return 0;
    }

    [output]
    0 100 200 300 400 500 600 700 800 900
    1 101 201 301 401 501 601 701 801 901
    2 102 202 302 402 502 602 702 802 902
    3 103 203 303 403 503 603 703 803 903
    4 104 204 304 404 504 604 704 804 904
    5 105 205 305 405 505 605 705 805 905
    6 106 206 306 406 506 606 706 806 906
    7 107 207 307 407 507 607 707 807 907
    8 108 208 308 408 508 608 708 808 908
    9 109 209 309 409 509 609 709 809 909
    10 110 210 310 410 510 610 710 810 910
    11 111 211 311 411 511 611 711 811 911
    12 112 212 312 412 512 612 712 812 912
    13 113 213 313 413 513 613 713 813 913
    14 114 214 314 414 514 614 714 814 914
    15 115 215 315 415 515 615 715 815 915
    16 116 216 316 416 516 616 716 816 916
    17 117 217 317 417 517 617 717 817 917
    18 118 218 318 418 518 618 718 818 918
    19 119 219 319 419 519 619 719 819 919



    > The authors should have said "Assuming
    > that each element of b does point to an int which happens to be the
    > first element of a 20 int array."


    You are addressing pedants; don't try to outdo us at our own game. You
    just look silly.

    > This mistake is crucial because
    > there really exists something totally different that fits their "not
    > very accurate" description.


    It is not a mistake.

    > This leads to confusion.


    Yes, I admit you are confused.

    > If I point at a
    > pencil and tell you that it's an instrument to write with and it has
    > ink in it which is permanent, then that's a big mistake for two
    > reasons: I'm 'slightly' off on my explanation of the pencil, and most
    > importantly, my explanation is really the qualities of something else:
    > a pen.


    You may now return to your class in Foucault where this silliness is
    rewarded.
    Martin Ambuhl, Mar 7, 2005
    #7
  8. TTroy

    infobahn Guest

    TTroy wrote:
    >
    > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    > mentioned topics).


    No, you didn't.

    >
    > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > this...
    >
    > "Newcomers to C are somtimes confused about the difference between a
    > two-dimensional array and an array of pointers..."


    Indeed.

    >
    > then continues to explain int *b[10]; to be...
    >
    > "For b, however, the definition only allocates 10 pointers ...


    Correct.

    > Assuming
    > that each element of b does point to a twenty element array,then there
    > will be 200 ints set aside, plus ten cells for pointers... "


    Yes. So if you do something like this:

    for(i = 0; i < 10; i++)
    {
    b = malloc(20 * sizeof *b);
    if(b == NULL) abort(); /* ! */
    }

    puts("At this point, 200 ints are set aside,"
    " plus the size of the b array - i.e. 10 pointers");

    > Is it just me, or is that explanation only valid for int (*b)[10];
    > ????


    It's just you.

    > I'm pretty sure K&R2 is totally wrong in this section (had me confused
    > for a while).


    Their explanation looks clear enough to me. And correct, too.

    > Later on in section 5.9, it says "... by far the most frequent use of
    > arrays of pointers is to store character strings of diverse lengths..."
    >
    > Once again, this seems totally wrong.


    Here, you have half a point; "to store pointers to" would have been
    more precise.

    <snip>

    > Am I totally wrong?


    Mostly wrong, yes.
    infobahn, Mar 7, 2005
    #8
  9. TTroy

    Kiru Sengal Guest

    TTroy wrote:
    > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the herein
    > mentioned topics).
    >
    > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
    > this...
    >
    > "Newcomers to C are somtimes confused about the difference between a
    > two-dimensional array and an array of pointers..."
    >


    Probably.

    >
    > then continues to explain int *b[10]; to be...
    >
    > "For b, however, the definition only allocates 10 pointers ...

    Assuming
    > that each element of b does point to a twenty element array,then

    there
    > will be 200 ints set aside, plus ten cells for pointers... "
    >


    Would changing 'point to a' to 'point into a' twenty element array be
    better for you? If so you are free to do so in your copy of the book.

    >
    > Is it just me, or is that explanation only valid for int

    (*b[10])[20];
    > ????
    >


    Well, it does and it doesn't. It fits the part of the explanation that
    says "Assuming each element of b does point to a twenty element array"
    as you have quoted, but it doesn't fit the part that comes after what
    you have quoted that explains how each array/row can be of different
    lengths. The whole section read in its entirety does lead one to
    realize that 'to' really means 'into.' The reader should be able to
    figure that out.

    >
    > I'm pretty sure K&R2 is totally wrong in this section (had me

    confused
    > for a while).
    >
    > Later on in section 5.9, it says "... by far the most frequent use of
    > arrays of pointers is to store character strings of diverse

    lengths..."
    >


    Take a pen, and change 'store' to 'manage.' K&R didn't get too
    detailed here probably because the reader would already know what's
    going from reading the well explained in previous sections on the issue
    (5.5, 5.6). The diagram at the end of 5.9 also serves as an good
    comparison between what was really happening (arrays of pointers to
    strings stored elsewhere) and what it might be confused with (arrays of
    strings held internally - 2 dimensional char array).

    Incidentally, section 5.10 also explains *argv[] as "a pointer to an
    array of character strings" and says "argv[0] is the name by which the
    program was invoked." So go ahead and change those to "a pointer to a
    pointer to a string(this probably would confuse beginners)" and
    "argv[0] points to the program name."

    The changes aren't really needed, since the diagram clearly shows what
    is meant, and a beginner might not be able to get passed the section if
    it was 110% accurate. Learning is cumulative, and it's sometimes better
    to refrain from being too pedantic early on in someone's education of a
    subject, because being so might mentally "hold them back" from learning
    further. In your early years of learning chemistry, you were probably
    taught basic notions of K, L, M, N shells, but in your later years you
    probably thought "they were totally wrong a few years ago!!." No they
    weren't, they refrained from being 100% detailed/accurate to help you
    move on and learn other aspects of the earlier course (which were also
    probably 'less than 100% accurate/detailed').


    >
    > Once again, this seems totally wrong.
    > char *strings[] = {"Bob","Dave","Jack");
    > 'strings' is only managing pointers to anonymous objects that are
    > automatically created by the initialization (which there is no

    mention
    > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".
    >


    See now, you are making the same type of statement K&R were making
    about the pointers to int arrays. See where you said "'strings' is only
    managing pointers 'to' anonymous objects' instead of "'strings' is only
    managing pointers 'to the first element..'" So from context it's easy
    to tell what is meant by 'pointing to' an object or array.
    Technically, pointing to an object/array means the pointer has a
    reference type with size equal to the whole objects, but there is no
    harm with using 'pointing to' to describe 'pointing into the first
    element of' because context clears up the confusion.

    Probably the most unambiguous use of 'pointing to' to refer to
    'pointing into first element of' is with the word "strings." Almost
    nobody says things like (char *b = "bill";) b is a pointer to the
    'first element of a string.' Almost everyone says b is a pointer to a
    string. This is similar to the 'to an object' vs 'into first element
    of an object' I mentioned before, but has no ambiguity because everyone
    knows strings are handled by pointers to their first characters (IOW,
    "strings" is enough context to clear things up).

    >
    >


    [snipped an opinion of yours]

    >
    >


    Take care

    __________________________________

    ~A Hardware Guy Programming in C~
    kiru dot sengal at gmail dot com
    __________________________________
    Kiru Sengal, Mar 7, 2005
    #9
  10. --
    Jean Pierre Daviau
    --
    borland 5.5
    windows Xp
    asus p4 s533/333/133
    http://www.jeanpierredaviau.com
    First-chance exception in chap5.9.exe: 0xC0000005: Access Violation.
    The thread 0xF0 has exited with code -1073741510 (0xC000013A).
    Jean Pierre Daviau, Mar 10, 2005
    #10
  11. I must precise it compiles perfectly with Borland bcc32.
    Maybe I should use another thread?
    -------
    MicrosoftVisualC++
    Compiling...
    chap5_9.c
    Linking...

    chap5_9.exe - 0 error(s), 0 warning(s)
    Jean Pierre Daviau, Mar 10, 2005
    #11
  12. TTroy

    Alan Balmer Guest

    On Thu, 10 Mar 2005 07:18:39 -0500, "Jean Pierre Daviau"
    <> wrote:

    >I must precise it compiles perfectly with Borland bcc32.
    >Maybe I should use another thread?
    >-------
    >MicrosoftVisualC++
    >Compiling...
    >chap5_9.c
    >Linking...
    >
    >chap5_9.exe - 0 error(s), 0 warning(s)
    >

    If you're asking about some code that compiles with VC but not with
    BCC, you may have code that violates the standard (bcc was notoriously
    lax about such things.) Post it here and we'll look at it.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Mar 10, 2005
    #12
  13. It is the Martin Ambuhl's Code three posts up

    This is why I am surprised.



    "Alan Balmer" <> a écrit dans le message de news:
    ...
    > On Thu, 10 Mar 2005 07:18:39 -0500, "Jean Pierre Daviau"
    > <> wrote:
    >
    >>I must precise it compiles perfectly with Borland bcc32.
    >>Maybe I should use another thread?
    >>-------
    >>MicrosoftVisualC++
    >>Compiling...
    >>chap5_9.c
    >>Linking...
    >>
    >>chap5_9.exe - 0 error(s), 0 warning(s)
    >>

    > If you're asking about some code that compiles with VC but not with
    > BCC, you may have code that violates the standard (bcc was notoriously
    > lax about such things.) Post it here and we'll look at it.
    >
    > --
    > Al Balmer
    > Balmer Consulting
    >
    Jean Pierre Daviau, Mar 10, 2005
    #13
  14. On Thu, 10 Mar 2005 12:43:05 -0500, in comp.lang.c , "Jean Pierre Daviau"
    <> wrote:

    >It is the Martin Ambuhl's Code three posts up
    >
    >This is why I am surprised.


    Two possibilities
    1) martin's code contains deliberate errors for you to fix
    2) you typed it wrong


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Mar 10, 2005
    #14
  15. TTroy

    Alan Balmer Guest

    On Thu, 10 Mar 2005 12:43:05 -0500, "Jean Pierre Daviau"
    <> wrote:

    (top post corrected)
    >
    >"Alan Balmer" <> a écrit dans le message de news:
    >...
    >> On Thu, 10 Mar 2005 07:18:39 -0500, "Jean Pierre Daviau"
    >> <> wrote:
    >>
    >>>I must precise it compiles perfectly with Borland bcc32.
    >>>Maybe I should use another thread?
    >>>-------
    >>>MicrosoftVisualC++
    >>>Compiling...
    >>>chap5_9.c
    >>>Linking...
    >>>
    >>>chap5_9.exe - 0 error(s), 0 warning(s)
    >>>

    >> If you're asking about some code that compiles with VC but not with
    >> BCC, you may have code that violates the standard (bcc was notoriously
    >> lax about such things.) Post it here and we'll look at it.
    >>

    >It is the Martin Ambuhl's Code three posts up
    >
    >This is why I am surprised.
    >

    Learn to quote enough context so that readers know what you're talking
    about. And don't top post.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Mar 10, 2005
    #15
  16. "Alan Balmer" <> a écrit dans le message de news:
    ...
    > On Thu, 10 Mar 2005 12:43:05 -0500, "Jean Pierre Daviau"
    > <> wrote:
    >
    > (top post corrected)
    >>
    >>"Alan Balmer" <> a écrit dans le message de news:
    >>...
    >>> On Thu, 10 Mar 2005 07:18:39 -0500, "Jean Pierre Daviau"
    >>> <> wrote:
    >>>
    >>>>I must precise it compiles perfectly with Borland bcc32.
    >>>>Maybe I should use another thread?
    >>>>-------
    >>>>MicrosoftVisualC++
    >>>>Compiling...
    >>>>chap5_9.c
    >>>>Linking...
    >>>>
    >>>>chap5_9.exe - 0 error(s), 0 warning(s)
    >>>>
    >>> If you're asking about some code that compiles with VC but not with
    >>> BCC, you may have code that violates the standard (bcc was notoriously
    >>> lax about such things.) Post it here and we'll look at it.
    >>>

    >>It is the Martin Ambuhl's Code three posts up
    >>
    >>This is why I am surprised.
    >>

    > Learn to quote enough context so that readers know what you're talking
    > about. And don't top post.


    I start another thread.
    " an array of 20 ints "
    Jean Pierre Daviau, Mar 10, 2005
    #16
  17. TTroy

    CBFalconer Guest

    Jean Pierre Daviau wrote:
    "Alan Balmer" <> a écrit dans le message de news:
    >> "Jean Pierre Daviau" <> wrote:
    >>
    >>> I must precise it compiles perfectly with Borland bcc32.
    >>> Maybe I should use another thread?
    >>>

    .... snip ...
    >>>

    >> If you're asking about some code that compiles with VC but not
    >> with BCC, you may have code that violates the standard (bcc was
    >> notoriously lax about such things.) Post it here and we'll look
    >> at it.

    >
    > It is the Martin Ambuhl's Code three posts up


    Please don't topppost. Your answer goes after, or intermixed with,
    the material to which you reply with non-germane material snipped,
    and germane material retained.

    There is no such thing as 'three posts up'. Every article needs to
    stand on its own, and every system decides on its own what to
    maintain and what to discard, and how to display them. Without
    this context the article tends to be useless. If some code was of
    interest, it should have been quoted or a URL given for longer
    pieces. If there is a problem with the code it should be
    compilable and consist only of standard C. (at least in c.l.c
    postings).

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Mar 11, 2005
    #17
    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. kokwooi

    Major Major Problem With ASP.NET

    kokwooi, Sep 18, 2003, in forum: ASP .Net
    Replies:
    6
    Views:
    656
    NuTcAsE
    Sep 19, 2003
  2. RZ
    Replies:
    2
    Views:
    501
  3. Jef Driesen
    Replies:
    2
    Views:
    1,672
    Jef Driesen
    Jan 12, 2006
  4. ara howard
    Replies:
    0
    Views:
    214
    ara howard
    Oct 28, 2003
  5. Gavin Hamill

    Socket programming blunders....

    Gavin Hamill, Feb 3, 2005, in forum: Perl Misc
    Replies:
    5
    Views:
    98
Loading...

Share This Page