1

I am trying to read the user's input. When I compile the program I get the message, 'control reaches end of non-void function [-Wreturn-type] }'.

char *read_line(char *buf, size_t sz) {
    while(fgets(buf, sz, stdin)) {
        fputs(buf, stdout);
    }
}

int main(int argc, char** argv) {
    char *buf;

    read_line(buf, 1024);
}

I want the program to take the user's input, press enter, and have their input printed back out to them. I gotta do it using the methods I have used (it's part of some homework).

I don't fully know what is going on under the hood of C, so it is just causes some many problems like this :).

Eugene Sh.
  • 17,802
  • 8
  • 40
  • 61
Jake Jackson
  • 1,055
  • 1
  • 12
  • 34
  • 2
    You never return anything from `read_line`. Do you really want it to be `char*`, or do you want it to return nothing and be `void`? – Carcigenicate Nov 12 '19 at 17:01
  • 1
    `buf` isn't pointing to anything. You probably want an array instead of a pointer. – dbush Nov 12 '19 at 17:02
  • 1
    Also, `main()` is defined to be `int` but it's not returning anything either; best to add `return 0;` (or other suitable error code) at the end of that function. – Steve Friedl Nov 12 '19 at 17:04
  • In the my problem sheet, the method's type and arguments are given to us in the way it is in my code - I just gotta work around that. I am pretty confused about it because I am pretty new to C. – Jake Jackson Nov 12 '19 at 17:04
  • 1
    @SteveFriedl `main` is special in that it returns 0 by default. – interjay Nov 12 '19 at 17:05
  • `#define MAXC 1024` then in `main(...)` Declare `char buf[MAXC];` and call `read_line (buf, MAXC);` Add `return buf;` at the end of `read_line {...}` – David C. Rankin Nov 12 '19 at 17:05
  • @SteveFriedl `main` is the one function that will default `return 0` (C99 and on). – Weather Vane Nov 12 '19 at 17:11
  • @interjay return can be omitted in C99 or C11, but technically it can't be omitted in older standards. – SurvivalMachine Nov 12 '19 at 17:12

2 Answers2

3

For starters the function has undefined behavior because it uses an unitialized pointer.

And the function shall have a return statement if its return type is not void.

It seems you mean the following

#include <stdio.h>

void read_line( char *buf, size_t sz ) 
{
    while( fgets(buf, sz, stdin) && buf[0] != '\n' ) 
    {
        fputs(buf, stdout);
    }
}

int main( void ) 
{
    enum { N = 1024 };
    char buf[N];

    read_line( buf, N );
}

Or something like the following

#include <stdio.h>

char * read_line( char *buf, size_t sz ) 
{
    if  ( fgets(buf, sz, stdin) && buf[0] != '\n' ) 
    {
        return buf;
    }
    else
    {
        return NULL;
    }
}

int main( void ) 
{
    enum { N = 1024 };
    char buf[N];

    char *p = read_line( buf, N );\

    if ( p != NULL ) fputs( p, stdout );
}
Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • I appreciate this but my homework sheet wants us to use 'char' rather than 'void' for the method. – Jake Jackson Nov 12 '19 at 17:06
  • 1
    @JakeJackson It does not make sense taking into account what you wrote relative to the assignment. – Vlad from Moscow Nov 12 '19 at 17:08
  • The C standard does not require a function to have a `return` statement even if it has a non-void return type, and reaching the end of a function with non-void return type does not, by itself, have undefined behavior. – Eric Postpischil Nov 12 '19 at 17:59
-2
char *read_line(char *buf, size_t sz) {
    while(fgets(buf, sz, stdin)) {
        fputs(buf, stdout);
    }
     return buf;
}

0___________
  • 60,014
  • 4
  • 34
  • 74
  • this compiles but when I enter something, such as 'name', it it just says, 'Segmentation fault (core dumped)'. – Jake Jackson Nov 12 '19 at 17:09
  • 2
    @JakeJackson That's because of the *undefined behavior* your code exhibits due to stuffing data into memory targeted by an indeterminate pointer in `main`, passed to `read_line`. It is also an entirely different problem than the question you posted. This answer is correct for what you asked (why is that warning being emitted), though it could certainly do a better job of explaining what is fixed, and why. Code-only answers are usually pretty lousy. – WhozCraig Nov 12 '19 at 17:10
  • 4
    For such a beginner question, maybe you can add an explanation instead of a code dump. – interjay Nov 12 '19 at 17:13