14

I'm reading the C Programming Language (chapter 5), and I'm confused by this example:

int n, array[SIZE], getint(int *);

Why is this function call in here like that? Is this just some tricky example and invalid code?

Motheus
  • 533
  • 5
  • 21
  • 1
    What kinda book it is and in which context this is mentioned? If it is given as a suggestion on how to actually write code, through the book away and never pick it up. – SergeyA Feb 15 '19 at 18:56
  • @SergeyA it is this book:https://3.bp.blogspot.com/-3H1iJSfZVCs/Wcd5CW-CXVI/AAAAAAAAAjQ/dFdRebqpksQfsiIAHVIfQukTpLKdYi2cgCLcBGAs/s320/_20170924_111559.JPG –  Feb 15 '19 at 19:18
  • 1
    @Goxm OK, Famous K&R book. Is it super dated now, but you should not throw it away. Just be mindful that it describes language was it was 30 years ago. – SergeyA Feb 15 '19 at 19:23
  • What should I read for modern C programming? – Motheus Feb 15 '19 at 20:34
  • 4
    I think K&R is a fine book to start out with. It's somewhat dated but not as impossibly dated as other commenters seem to imply. Sure, the second edition is 30 years old, but the C language has changed remarkably little in that time. Additionally, while I and many others prefer to declare only one variable per line, declaring multiple variables is both a totally valid use of the language, and a style that you *will* encounter when reading code in the wild -- and thus, it's good for a book that introduces you to the language to describe such things. – Daniel Pryden Feb 15 '19 at 20:59
  • @Motheus [The Definitive C Book Guide and List](https://stackoverflow.com/q/562303/3342206) – 8bittree Feb 15 '19 at 21:32
  • 1
    Would you recognize it if equivalently if it said `int getint(int *), n, array[SIZE];` ? It's clearly a function defn not a call, since `getint(int *)` can't be passing an actual arg. – smci Feb 16 '19 at 01:57

2 Answers2

19

It's not calling the function; it's declaring its prototype. It's equivalent to:

int n;
int array[SIZE];
int getint(int*);
Ray
  • 1,706
  • 22
  • 30
  • That was going to be my guess. Why would you do it like that though? Is the book just trying to show shorthand? –  Feb 15 '19 at 18:19
  • Who is this book by? – P Varga Feb 15 '19 at 18:20
  • 6
    @Chipster The sort of code style that's favored has changed over the years. Back then, shorter code was considered more readable, since you can fit more on the screen. These days, people tend to prefer more code, but with lines that are individually more clear. (I tend to be in the camp that favors shorter code, but even I would write this one out on three lines.) – Ray Feb 15 '19 at 18:22
  • 2
    @ııı Kernighan and Ritchie (the latter being the creator of C). The second edition is considered the canonical text on the language, although it's out of date now. (and will remain so, since Ritchie's dead.) – Ray Feb 15 '19 at 18:22
  • 3
    @Ray Which also made sense back in the days. Monitors could not show many rows on one screen. – klutt Feb 15 '19 at 18:23
  • @Ray Interesting. I didn't realize you could do that, although it makes sense now that I think about it. I personally would do 2 lines. 1 for n and array (those I don't mind together as much) and 1 for the prototype. –  Feb 15 '19 at 18:25
  • 3
    K&R style C is a nightmare I'm glad we've woken up from. – tadman Feb 15 '19 at 18:26
  • 2
    @Broman There's still a case to be made for compact code even now. The more code on the screen, the easier it is to see the big picture. Bigger monitors just mean we can see even *more* of the program at once. The algorithms are the hard parts to understand; fitting more on screen helps with that more than it hurts line-level readability. And a lot of the compact K&Risms only seem hard to read today because people aren't used to them. If you're fluent in both the language and the idioms, you can just glance at this sort of code and understand it as easily as you would `i = j + 1`. – Ray Feb 15 '19 at 18:30
  • @Chipster: Books, PowerPoint slides, and similar media have limited space, so they tend to use a more dense and compact coding style to fit more code on the page. As far as the compiler is concerned, `getint(int *)` is just another declarator like `n` and `array[SIZE]`. Outside of preprocessor directives, C doesn't care about newlines (or whitespace in general) except to separate tokens. You could theoretically write all your non-preprocessor code on a single source line. Not that you'd *do* that, but you could. – John Bode Feb 15 '19 at 19:11
  • @JohnBode You could theoretically write all your non-preprocessor code as a [single](https://www.ioccc.org/1988/phillipps.c) [statement](https://www.ioccc.org/1988/phillipps.hint). You *really* shouldn't do that, though. – Ray Feb 15 '19 at 19:15
  • @Ray I agree that's a bad idea, but it'd be fun to try writing all your code as a single statement. –  Feb 15 '19 at 19:19
  • 1
    LOL guys it is funny we complain about "this" and "that" and what we take for granted. Take a look at some FreeBSD code that was written before ANSI standard. Back then you could not declare variables anywhere but at the beginning of function. –  Feb 15 '19 at 19:28
  • 1
    @Gox what are you referring to?! The *"Ansi C"*, i.e. ISO C90 only allowed declarations at the beginning of each *block/compound statement*; and this was the same as in K&R 1st ed. from 1978! – Antti Haapala -- Слава Україні Feb 15 '19 at 21:49
  • 1
    @AnttiHaapala???? So when did they allow variable declaration in the middle of the bock? K&R ANSI C (2nd edition) uses it all the time. –  Feb 15 '19 at 22:01
  • 1
  • @Gox it doesn't. 2nd ed 4.9.: *"Declarations of variables (including initializations) may follow the left brace that introduces any compound statement, not just the one that begins a function."* – Antti Haapala -- Слава Україні Feb 15 '19 at 22:07
  • The second edition of the book used C89, and the first edition did not have prototypes. As others have mentioned, you wouldn’t see this kind of definition today outside an obfuscated C contest. – Davislor Feb 16 '19 at 01:03
  • @Davislor actually even the second ed *predates* the final standard, having been published in January 1988 – Antti Haapala -- Слава Україні Feb 16 '19 at 10:14
3

Since the statement began with a type specifier, namely int, then it suggests declaration. Thus what follows is a bunch of comma separated list of identifiers.

n being a single int variable.

array being an array of int.

getint being a function that returns an int and has one parameter that is an int pointer. It is unnamed and that is not important because this is a function declaration/prototype.

n0rd
  • 11,850
  • 5
  • 35
  • 56
machine_1
  • 4,266
  • 2
  • 21
  • 42