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

[Ben Jacobs-Swearingen]

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
(e-mail address removed)

 

[Glen Herrmannsfeldt]

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

 

[Arthur J. O'Dwyer]

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

 

[Ben Jacobs-Swearingen]

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
(e-mail address removed)

 

[Glen Herrmannsfeldt]

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

 

[Ben Jacobs-Swearingen]

Figured it out -- had a bad pointer declaration in main() -- thanks for
the patience!

B
(e-mail address removed)

 

[Glen Herrmannsfeldt]

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

 

[Mark McIntyre]

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 Gordon]

On Fri, 31 Oct 2003 10:14:54 -0600

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.

 

[Sheldon Simms]

On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben

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!

 

[Ben Jacobs-Swearingen]

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
(e-mail address removed)

 

[August Derleth]

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.)

 

[Arthur J. O'Dwyer]

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

 

[Mark McIntyre]

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]

On 31 Oct 2003 21:11:20 -0800, in comp.lang.c ,

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.

 

[pete]

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.

 

[Sheldon Simms]

On Fri, 31 Oct 2003 10:14:54 -0600, in comp.lang.c , Ben

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

 

[Mark McIntyre]

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.

 

[Sheldon Simms]

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.

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

 

[Mark McIntyre]

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.

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

Agreed.