very basic C question--K&R on a Mac

Discussion in 'C Programming' started by Ben Jacobs-Swearingen, Oct 31, 2003.

  1. Hello,

    I just started learning C a couple weeks ago from Kernighan and
    Ritchie (first edition -- I can't afford the newer second edition), and
    have really enjoyed it so far. But I am having trouble making the code
    at the end of Chapter 5 -- the sort function that uses function pointers
    -- to work on my machine (233 Mhz iMac, 160 MB RAM, OS 9.2 ; MPW
    environment). When I try to compile sort.c with the Symantec C compiler
    it gives me all sorts of strange errors about how the syntax (copied
    straight from the book!) is screwed up. Now when I'm at school and
    working on an OSX machine running gcc, sort.c will compile correctly
    along with everything else, but the input is all wrong (the pointers
    aren't working properly). I *think* I've traced the problem in the
    gcc-compile to sort.c as well, but I'm not sure. I really don't like
    being stalled with this because I want to continue doing the exercises
    (which are really fun) that are based on this code.

    Having looked at the code many times by now and made sure I copied
    the base code from the book correctly, I'm at my wits end. Does anyone
    know any reason why the Kernighan & Ritchie code from the end of Chapter
    5 (1st edition) might not compile correctly on a Mac? I suspect it has
    to do with some obscure detail involving the inner workings of the
    computer (that would necessitate a different arrangement of pointers?),
    or (less likely) some incompatibility with ANSI C, but I'm not sure. I'd
    much appreciate any constructive advice anyone could give me... thanks.
    I can provide my source files for someone to look at if you would think
    it would help.

    Ben
     
    Ben Jacobs-Swearingen, Oct 31, 2003
    #1
    1. Advertising

  2. "Ben Jacobs-Swearingen" <> wrote in message
    news:...

    > I just started learning C a couple weeks ago from Kernighan and
    > Ritchie (first edition -- I can't afford the newer second edition), and
    > have really enjoyed it so far. But I am having trouble making the code
    > at the end of Chapter 5 -- the sort function that uses function pointers


    (snip)

    There are some things in K&R C that just don't work anymore.

    You might see if you can get the book from the library. I always did think
    it was a little expensive, though.

    You also might try to find a used copy. If you post the error messages,
    someone might explain the difference, if any. At this point it is probably
    better not to learn K&R C. The book is nice for its historical value,
    though. Keep the book, but be careful how you use it.

    -- glen
     
    Glen Herrmannsfeldt, Oct 31, 2003
    #2
    1. Advertising

  3. On Fri, 31 Oct 2003, Ben Jacobs-Swearingen wrote:
    >
    > I just started learning C a couple weeks ago from Kernighan and
    > Ritchie (first edition -- I can't afford the newer second edition), and
    > have really enjoyed it so far. But I am having trouble making the code
    > at the end of Chapter 5 -- the sort function that uses function pointers
    > -- to work on my machine


    My copy of K&R1 is elsehome this semester, but if you'll cut and
    paste the code you're trying to compile, I (and of course others)
    will be glad to take a look and tell you what's right, what's
    wrong and what used to be right but isn't anymore. :)
    If I recall correctly, K&R doesn't start getting into platform-
    specific stuff until chapter 7 or 8, so it's almost certainly a
    problem in your typing-in of the program. But it's true that
    some of the stuff in K&R1 isn't legal C anymore, too.
    Oh, and is this code from K&R, or code you wrote as the solution
    to one of the K&R exercises? When you post the code, please
    indicate which it is, just in case we can't tell by looking. :)

    HTH,
    -Arthur
     
    Arthur J. O'Dwyer, Oct 31, 2003
    #3

  4. > My copy of K&R1 is elsehome this semester, but if you'll cut and
    > paste the code you're trying to compile, I (and of course others)
    > will be glad to take a look and tell you what's right, what's
    > wrong and what used to be right but isn't anymore. :)


    Alright, here's the code sort.c that won't compile at home. It's copied
    straight from K&R (page 116 of the first edition; it's at the end of the
    pointers chapter where they talk about function pointers), as I was
    trying to get the base program working before I went on to do the
    exercises:

    sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    char *v[]; /* into increasing order */
    int n;
    int (*comp)(), (*exch)();
    {
    int gap, i, j;

    for(gap = n/2; gap > 0; gap /= 2)
    for(i = gap; i < n; i++)
    for(j = i-gap; j >= 0; j -= gap) {
    if((*comp)(v[j], v[j+gap]) <= 0)
    break;
    (*exch)(&v[j], &v[j+gap]);
    }
    }

    looked at it again this morning and it still seems the same as the
    Kernighan code (on page 116 of the first edition; don't even know if
    it's included in the second edition). When I try to run it through the
    Symantec C compiler at home it screams at me:

    ---

    sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    ^
    File "sort.c"; line 1 #Error: identifier expected
    #-----------------------
    int (*comp)(), (*exch)();
    ^
    File "sort.c"; line 4 #Error: ')' expected
    #-----------------------
    if((*comp)(v[j], v[j+gap]) <= 0)
    ^
    File "sort.c"; line 11 #Error: expression expected
    #-----------------------
    if((*comp)(v[j], v[j+gap]) <= 0)
    ^
    File "sort.c"; line 11 #Warning 6: value of expression is not used
    #-----------------------
    break;
    ^
    File "sort.c"; line 12 #Warning 6: value of expression is not used
    #-----------------------
    break;
    ^
    File "sort.c"; line 12 #Error: ';' expected
    #-----------------------
    (*exch)(&v[j], &v[j+gap]);
    ^
    File "sort.c"; line 13 #Error: undefined identifier 'exch'

    ---

    I know that function declarations are somewhat different in ANSI C, and
    have tried declaring the function as

    sort(char *v[], int n, (*comp)(), (*exch)())

    but it doesn't make any difference. I'm going to school soon and I'll
    keep on investigating the problem wit gcc -- hope to hear back from you
    guys soon. I appreciate the patience with a non-computer-expert newbie!

    Decided to bite the bullet and order the book anyway, as you said, glen,
    there's little point trying to learn a version of C designed for the
    PDP-11 and its contemporaries.

    B
     
    Ben Jacobs-Swearingen, Oct 31, 2003
    #4
  5. "Arthur J. O'Dwyer" <> wrote in message
    news:p...
    >
    > On Fri, 31 Oct 2003, Ben Jacobs-Swearingen wrote:
    > >
    > > I just started learning C a couple weeks ago from Kernighan and
    > > Ritchie (first edition -- I can't afford the newer second edition), and
    > > have really enjoyed it so far. But I am having trouble making the code
    > > at the end of Chapter 5 -- the sort function that uses function pointers
    > > -- to work on my machine

    >
    > My copy of K&R1 is elsehome this semester, but if you'll cut and
    > paste the code you're trying to compile, I (and of course others)
    > will be glad to take a look and tell you what's right, what's
    > wrong and what used to be right but isn't anymore. :)
    > If I recall correctly, K&R doesn't start getting into platform-
    > specific stuff until chapter 7 or 8, so it's almost certainly a
    > problem in your typing-in of the program. But it's true that
    > some of the stuff in K&R1 isn't legal C anymore, too.


    Well, K&R allow writing into string constants, though I don't remember where
    in the book they do that. That could be a problem really fast, though.
    That is the first one I think of, though not related to function pointers.

    -- glen
     
    Glen Herrmannsfeldt, Oct 31, 2003
    #5
  6. Figured it out -- had a bad pointer declaration in main() -- thanks for
    the patience!

    B
     
    Ben Jacobs-Swearingen, Oct 31, 2003
    #6
  7. "Ben Jacobs-Swearingen" <> wrote in message
    news:311020031136453426%...
    >
    > Figured it out -- had a bad pointer declaration in main() -- thanks for
    > the patience!


    Could you explain a little more? Bad declarations in main shouldn't cause
    those problems.

    Since C doesn't allow internal functions, though, if you had the wrong
    number of } I might understand those errors.

    -- glen
     
    Glen Herrmannsfeldt, Oct 31, 2003
    #7
  8. On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    Jacobs-Swearingen <> wrote:

    >sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    >char *v[]; /* into increasing order */
    >int n;
    >int (*comp)(), (*exch)();


    This form of function definition is obsolete, and you reallly need to
    avoid it. Some compilers will complain about it nowadays. Also you're
    using "implicit int" for the function itself, which is disallowed in
    the newest C standard.

    int sort(char **v, int n, int(*comp(), int *exch())

    >sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    > ^
    >File "sort.c"; line 1 #Error: identifier expected


    this is the sort of error that you will get using old-style
    declarations. You really really need to get a newer book than K&R1,
    its over 20 years out of date.

    >I know that function declarations are somewhat different in ANSI C, and
    >have tried declaring the function as
    >
    >sort(char *v[], int n, (*comp)(), (*exch)())


    you need to put in the two missing "int"s.


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Oct 31, 2003
    #8
  9. Ben Jacobs-Swearingen

    Mark Gordon Guest

    On Fri, 31 Oct 2003 10:14:54 -0600
    Ben Jacobs-Swearingen <> wrote:

    <snip>

    > Alright, here's the code sort.c that won't compile at home. It's
    > copied straight from K&R (page 116 of the first edition; it's at the
    > end of the pointers chapter where they talk about function pointers),
    > as I was trying to get the base program working before I went on to do
    > the exercises:
    >
    > sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    > char *v[]; /* into increasing order */
    > int n;
    > int (*comp)(), (*exch)();


    This style is obsolete and one of the many reasons you need a more up to
    date reference. You should always specify the return type (void means it
    does not return anything) and put the parameter list including types in
    the brackets after the function name as follows:

    void sort(char *v[], int n, int (*comp)(char *a,char *b),
    void (*exch)(char *a[],char *b[]))
    /* sort strings v[0]...v[n-1]*/

    > {
    > int gap, i, j;
    >
    > for(gap = n/2; gap > 0; gap /= 2)
    > for(i = gap; i < n; i++)
    > for(j = i-gap; j >= 0; j -= gap) {
    > if((*comp)(v[j], v[j+gap]) <= 0)
    > break;
    > (*exch)(&v[j], &v[j+gap]);
    > }
    > }
    >
    > looked at it again this morning and it still seems the same as the
    > Kernighan code (on page 116 of the first edition; don't even know if
    > it's included in the second edition). When I try to run it through the
    > Symantec C compiler at home it screams at me:
    >
    > ---
    >
    > sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    > ^
    > File "sort.c"; line 1 #Error: identifier expected


    <snip>

    Apart from being old style it looks OK to my and my compiler accepts
    your original code with only warnings about the return type defaulting
    to int and reaching the end of a function returning int without having
    returned one. Neither of these warnings is required with C90.

    > I know that function declarations are somewhat different in ANSI C,
    > and have tried declaring the function as
    >
    > sort(char *v[], int n, (*comp)(), (*exch)())


    Better, but see my suggestion further up.

    > but it doesn't make any difference. I'm going to school soon and I'll
    > keep on investigating the problem wit gcc -- hope to hear back from
    > you guys soon. I appreciate the patience with a non-computer-expert
    > newbie!


    You should find that gcc accepts it.My guess is that either you are
    invoking the Symantic C compiler incorrectly or it is a buggy compiler.
    Unfortunately for you problems with your specific compiler are not
    topical here so you will have to investigate that somewhere else.

    > Decided to bite the bullet and order the book anyway, as you said,
    > glen, there's little point trying to learn a version of C designed for
    > the PDP-11 and its contemporaries.


    It's well worth the money IMHO.
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Nov 1, 2003
    #9
  10. On Fri, 31 Oct 2003 22:33:48 +0000, Mark McIntyre wrote:

    > On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    > Jacobs-Swearingen <> wrote:
    >
    > int sort(char **v, int n, int(*comp(), int *exch())
    >
    >>sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    >> ^
    >>File "sort.c"; line 1 #Error: identifier expected

    >
    > this is the sort of error that you will get using old-style
    > declarations.


    Why do you say that? Where's the error?

    When I saw this code the only thing I could think of is
    that the identifier comp is already defined as a type somewhere.

    gcc 3.3.1, at least, invoked with

    "gcc -Wall -W -ansi -std=c99 -pedantic -O2 -c test.c"

    completes with only two warnings:

    test.c:2: warning: return type defaults to `int'
    test.c: In function `sort':
    test.c:15: warning: control reaches end of non-void function

    > You really really need to get a newer book than K&R1,
    > its over 20 years out of date.


    Right!
     
    Sheldon Simms, Nov 1, 2003
    #10
  11. In article <xGzob.71194$HS4.627461@attbi_s01>,
    "Glen Herrmannsfeldt" <> wrote:

    > "Ben Jacobs-Swearingen" <> wrote in message
    > news:311020031136453426%...
    > >
    > > Figured it out -- had a bad pointer declaration in main() -- thanks for
    > > the patience!

    >
    > Could you explain a little more? Bad declarations in main shouldn't cause
    > those problems.
    >
    > Since C doesn't allow internal functions, though, if you had the wrong
    > number of } I might understand those errors.


    Sure -- the problem that was screwing the gcc compiler at school was a
    simple typo in the main() function -- I had a pointer where there should
    have been a simple address marker (i.e. I had *c instead of c):

    sort(*lineptr, nlines, strcmp, swap);

    At the time I didn't know whether or not the two problems were related.
    Now I know that they aren't, so you are right :)

    The reason for the errors at home (the ones that prompted the original
    message), as I figured out earlier tonight (after I sent that message),
    is that evidently according to my compiler "comp" and "exch" already
    have function definitions (probably in some header file on my computer
    -- who knows). Changing the names of the functions to "c" and "e" fixed
    the problem and I got a clean compile. I've had this problem
    occasionally in other pieces of code, but in those cases it was more
    obvious that the function names might have become part of the standard
    library.

    Now everything is working again and I'm plugging through the book
    (which'll be discarded in favor of K&R 2, when it arrives). Thanks for
    all the help, guys -- nice to know that there are some patient people
    out there!

    B
     
    Ben Jacobs-Swearingen, Nov 1, 2003
    #11
  12. Mark McIntyre <> wrote in message news:<>...
    > On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    > Jacobs-Swearingen <> wrote:
    >
    > >sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    > >char *v[]; /* into increasing order */
    > >int n;
    > >int (*comp)(), (*exch)();


    > int sort(char **v, int n, int(*comp(), int *exch())


    int sort(char **v, int n, int (*comp)(), int (*exch)())
    {

    /* ... */

    }

    The * binds more tightly to the left than the right in variable
    declarations, so you need the parens to tell the compiler that the
    variables themselves are pointers, instead of functions that return
    pointers.

    I think you wanted to post that, which is why your parens don't nest.
    (The last paren actually closes the malformed expression begun right
    after your second `int'. Your first paren is unclosed.)
     
    August Derleth, Nov 1, 2003
    #12
  13. On Fri, 31 Oct 2003, Ben Jacobs-Swearingen wrote:
    >
    > "Glen Herrmannsfeldt" <> wrote:
    > >
    > > Could you explain a little more? Bad declarations in main shouldn't
    > > cause those problems.

    >
    > Sure -- the problem that was screwing the gcc compiler at school was a
    > simple typo in the main() function -- I had a pointer where there should
    > have been a simple address marker (i.e. I had *c instead of c):
    >
    > sort(*lineptr, nlines, strcmp, swap);
    >
    > At the time I didn't know whether or not the two problems were related.
    > Now I know that they aren't, so you are right :)
    >
    > The reason for the errors at home (the ones that prompted the original
    > message), as I figured out earlier tonight (after I sent that message),
    > is that evidently according to my compiler "comp" and "exch" already
    > have function definitions (probably in some header file on my computer
    > -- who knows). Changing the names of the functions to "c" and "e" fixed
    > the problem and I got a clean compile. I've had this problem
    > occasionally in other pieces of code, but in those cases it was more
    > obvious that the function names might have become part of the standard
    > library.


    Many compilers have a "standard C" switch or two that you can turn
    on if you want to compile... well... standard C. (In almost all
    cases, that standard is C89, not C99, BTW.) That *should* get rid
    of those spurious declarations of "comp", etc., if you can find
    such a switch for your compiler.

    > Now everything is working again and I'm plugging through the book
    > (which'll be discarded in favor of K&R 2, when it arrives).


    Just thought I should point out that I like K&R1 a heck of a lot
    more than K&R2 -- but then I already know C, so I don't have to
    learn it from the book anymore. :) But I *did* learn C on my
    own from K&R1 and a few other sources, and there is one thing to
    be said for the First Edition: partly because it's missing the
    Second Edition's standard library reference, it's a heck of a
    lot *shorter*! (Plus, you never know when an out-of-print book
    might turn out to be worth something... hang onto it, at least.
    ;-)

    -Arthur
     
    Arthur J. O'Dwyer, Nov 1, 2003
    #13
  14. On Fri, 31 Oct 2003 21:35:29 -0500, in comp.lang.c , Sheldon Simms
    <> wrote:

    >On Fri, 31 Oct 2003 22:33:48 +0000, Mark McIntyre wrote:
    >
    >> On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    >> Jacobs-Swearingen <> wrote:
    >>
    >>>sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    >>> ^
    >>>File "sort.c"; line 1 #Error: identifier expected

    >>
    >> this is the sort of error that you will get using old-style
    >> declarations.

    >
    >Why do you say that? Where's the error?


    Most likely its a typo, but its also possible the compiler is being
    invoked in C++ mode and simply rejects pre-ansi function definitions.
    I've seen some (nonconforming) C compilers that did that too.

    In any events, retyping the definition in "modern" terms will almost
    certainly remove the problem, either by fixing the typo, or by
    silencing the compiler !

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 1, 2003
    #14
  15. On 31 Oct 2003 21:11:20 -0800, in comp.lang.c ,
    (August Derleth) wrote:

    >Mark McIntyre <> wrote in message news:<>...
    >> On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    >> Jacobs-Swearingen <> wrote:
    >>
    >> >sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    >> >char *v[]; /* into increasing order */
    >> >int n;
    >> >int (*comp)(), (*exch)();

    >
    >> int sort(char **v, int n, int(*comp(), int *exch())

    >
    >int sort(char **v, int n, int (*comp)(), int (*exch)())


    Absolutely. Typing too fast, not proofreading.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 1, 2003
    #15
  16. Ben Jacobs-Swearingen

    pete Guest

    Ben Jacobs-Swearingen wrote:

    > The reason for the errors at home
    > (the ones that prompted the original message),
    > as I figured out earlier tonight (after I sent that message),
    > is that evidently according to my compiler "comp" and "exch" already
    > have function definitions (probably in some header file on my computer
    > -- who knows).
    > Changing the names of the functions to "c" and "e" fixed
    > the problem and I got a clean compile. I've had this problem
    > occasionally in other pieces of code, but in those cases it was more
    > obvious that the function names might have become part of the standard
    > library.


    K&R is full of example functions,
    which have the same name as standard functions.
    It is something that you will have to continue to watch out for.

    --
    pete
     
    pete, Nov 1, 2003
    #16
  17. On Sat, 01 Nov 2003 10:00:20 +0000, Mark McIntyre wrote:

    > On Fri, 31 Oct 2003 21:35:29 -0500, in comp.lang.c , Sheldon Simms
    > <> wrote:
    >
    >>On Fri, 31 Oct 2003 22:33:48 +0000, Mark McIntyre wrote:
    >>
    >>> On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben
    >>> Jacobs-Swearingen <> wrote:
    >>>
    >>>>sort(v, n, comp, exch) /* sort strings v[0] ... v[n-1] */
    >>>> ^
    >>>>File "sort.c"; line 1 #Error: identifier expected
    >>>
    >>> this is the sort of error that you will get using old-style
    >>> declarations.

    >>
    >>Why do you say that? Where's the error?

    >
    > Most likely its a typo,


    Did you not read? I already said that the code compiled fine
    with gcc 3.3.1. There was no typo.

    > but its also possible the compiler is being
    > invoked in C++ mode and simply rejects pre-ansi function definitions.
    > I've seen some (nonconforming) C compilers that did that too.
    >
    > In any events, retyping the definition in "modern" terms will almost
    > certainly remove the problem, either by fixing the typo, or by
    > silencing the compiler !


    Wrong answer. The code was fine. The problem was that the name
    "comp" was already defined by the implementation. Making the
    definition modern wouldn't have helped at all.

    -Sheldon
     
    Sheldon Simms, Nov 1, 2003
    #17
  18. On Sat, 01 Nov 2003 13:45:39 -0500, in comp.lang.c , Sheldon Simms
    <> wrote:

    >On Sat, 01 Nov 2003 10:00:20 +0000, Mark McIntyre wrote:
    >
    >> On Fri, 31 Oct 2003 21:35:29 -0500, in comp.lang.c , Sheldon Simms
    >> <> wrote:
    >>
    >>>On Fri, 31 Oct 2003 22:33:48 +0000, Mark McIntyre wrote:
    >>>

    >> Most likely its a typo,

    >
    >Did you not read? I already said that the code compiled fine
    >with gcc 3.3.1. There was no typo.


    Given that the OP has admitted elsethread to a typo, I stand
    uncorrected. :)

    >Making the definition modern wouldn't have helped at all.


    I disagree. It would at the very least have rendered the error
    meaningful as the compiler would have had to complain about a
    redeclaration which was different.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 2, 2003
    #18
  19. On Sun, 02 Nov 2003 00:24:44 +0000, Mark McIntyre wrote:

    > On Sat, 01 Nov 2003 13:45:39 -0500, in comp.lang.c , Sheldon Simms
    > <> wrote:
    >
    >>On Sat, 01 Nov 2003 10:00:20 +0000, Mark McIntyre wrote:
    >>
    >>> On Fri, 31 Oct 2003 21:35:29 -0500, in comp.lang.c , Sheldon Simms
    >>> <> wrote:
    >>>
    >>>>On Fri, 31 Oct 2003 22:33:48 +0000, Mark McIntyre wrote:
    >>>>
    >>> Most likely its a typo,

    >>
    >>Did you not read? I already said that the code compiled fine
    >>with gcc 3.3.1. There was no typo.

    >
    > Given that the OP has admitted elsethread to a typo, I stand
    > uncorrected. :)


    This discussion has nothing to do with the typo. The OP was using gcc
    on Mac OSX at school. There the program compiled, but didn't work properly
    when he ran it. THAT was caused by a typo, but that is not what we were
    talking about.

    We were talking the OP's problem with Symantec C on Mac OS 9 at home,
    where the program didn't even compile. You said: "this is the sort of
    error that you will get using old-style declarations"

    I interpreted that to mean that the function would have compiled if
    it had a "new style" parameter declaration list. If that's what you
    meant, that was wrong. If you just meant that with old-style
    declarations you can get cryptic and unhelpful error, then ok.

    >>Making the definition modern wouldn't have helped at all.

    >
    > I disagree. It would at the very least have rendered the error
    > meaningful as the compiler would have had to complain about a
    > redeclaration which was different.


    It depends on why a name-clash was occurring. In this case, you're
    right.

    -Sheldon
     
    Sheldon Simms, Nov 2, 2003
    #19
  20. On Sun, 02 Nov 2003 01:23:29 -0500, in comp.lang.c , Sheldon Simms
    <> wrote:

    >meant, that was wrong. If you just meant that with old-style
    >declarations you can get cryptic and unhelpful error, then ok.


    Correct. Without proper prototypes, the compiler is struggling to help
    you. They were added to the language for a reason, I suspect.

    >>>Making the definition modern wouldn't have helped at all.

    >>
    >> I disagree. It would at the very least have rendered the error
    >> meaningful as the compiler would have had to complain about a
    >> redeclaration which was different.

    >
    >It depends on why a name-clash was occurring. In this case, you're
    >right.


    Agreed.
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 2, 2003
    #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. Ben Jacobs-Swearingen

    very basic C question -- K & R on a Mac

    Ben Jacobs-Swearingen, Oct 31, 2003, in forum: C Programming
    Replies:
    0
    Views:
    304
    Ben Jacobs-Swearingen
    Oct 31, 2003
  2. Raymond Arthur St. Marie II of III

    very Very VERY dumb Question About The new Set( ) 's

    Raymond Arthur St. Marie II of III, Jul 23, 2003, in forum: Python
    Replies:
    4
    Views:
    483
    Raymond Hettinger
    Jul 27, 2003
  3. aghazalp

    very very basic question

    aghazalp, Apr 2, 2006, in forum: Python
    Replies:
    6
    Views:
    347
    aghazalp
    Apr 2, 2006
  4. Peter

    Very very very basic question

    Peter, Feb 8, 2005, in forum: C Programming
    Replies:
    14
    Views:
    518
    Dave Thompson
    Feb 14, 2005
  5. mdh

    A very **very** basic question

    mdh, Sep 25, 2008, in forum: C Programming
    Replies:
    57
    Views:
    1,241
    August Karlstrom
    Sep 26, 2008
Loading...

Share This Page