why can't i do this?

[MK27]

I'm trying to make a brief header function for getline() (called "linein") so that I can go:

char *line;
line = linein();

Only I would like to include the stream, so instead the second line could be:

line=linein("stdin");

This is what the function I wrote looks like:

char *linein (char *stream) {
        int len=0;
        char *line;
        line = NULL;
        getline(&line,&len,&stream);
        return line;
}

This compiles fine and actually runs, but the line returned contains nothing (nor does it test as "== NULL").

The problem is obviously to do with passing a "stream" argument to getline. Is there a proper way?

[MacGyver]

Read up on strings and files. You lack a general understanding how either of those two really work in C. It's complicated to put it all together, and to explain the misconceptions would require us to basically write the function out for you.

Also, I'm not entirely sure where you're getting getline() from.

[mingerso]

If you're using linux, read this: http://linux.die.net/man/3/getline

1. You would have to #define _GNU_SOURCE to make it work right, so use an alternative function.
2. And your "char * stream" should probably be "FILE * stream".
3. The last parameter of getline is being passed wrong too.
4. declare "char * line;" as "char * line = NULL;"
5. A header function?

[MK27]

Yes, I'm new to C and my question was definately about passing variable types. Sorry, I had forgotten getline() is GNU-specific.

Anyway I did get it to work such that "char *line=linein(stdin);" returns a correct pointer. Two lines had to change in the "header function" (by which I meant a function in a header file, what are you suppose to call such a thing?):

 31 char *linein (FILE *stream) {
 32         int len=0;
 33         char *line = NULL;
 34         getline(&line,&len,stream);
 35         return line;
 36 }

Namely lines 31 and 34. This works with "disk" file streams too obviously, and saves setting an integer which makes me really lazy. Thanks, mingerso...

[mingerso]

Typically you would just have a prototype for the function in the header.
See:
http://en.wikipedia.org/wiki/Header_file
and
http://wiki.gamedev.net/index.php/Pr...ile_Convention

[MK27]

I presume I will understand things differently later, but after reading the wikipedia thing on header files, I have to say it seems pointless to include prototypes in one file for definitions that appear in another.

Perhaps I should call it an "include" file? After all, what I have is something which just contains a bunch of (personalized) regularly used functions (error checked malloc, chomp, etc.) so I can include them with "#include <mine.h>"...

[Elysia]

It's not pointless.
When your program grows large, you split your functions into different files.
Then the compiler needs to know about those functions when you call them, so to avoid code duplication, you put them in an "include file" (also known as a header) and include it so the compiler can see the function prototypes.
Although calling functions without prototypes is valid in C, it's a very, very bad thing™. So don't do it.

[tabstop]

I presume I will understand things differently later, but after reading the wikipedia thing on header files, I have to say it seems pointless to include prototypes in one file for definitions that appear in another.

Perhaps I should call it an "include" file? After all, what I have is something which just contains a bunch of (personalized) regularly used functions (error checked malloc, chomp, etc.) so I can include them with "#include <mine.h>"...

So, in other words, you're making a library.

That's actually the best example of the point of headers -- take the standard library and consider, oh, stdio.h. stdio.h is going to contain the prototype for printf, so that you can actually use the function. But stdio.h isn't going to contain the code for printf; depending on your system, source code for printf may be unavailable. But you've got a library that's compiled, so you don't need to have the source code for that; and you've got the header file, so you (and your compiler!) know how to use the functions in the library.

(Plus, this system allows for any kind of meaningful standards across platforms; the libraries themselves are going to be radically different from architecture to architecture, but since the headers are (more-or-less) standardized, you won't have to change any of your code to recompile on a new architecture.)

[mingerso]

The main problem you will probably run into is having multiple objects that use the header with the function and linking all of the objects into the main executable. You basically are trying to redefine the function everytime the header is included... and on linux gcc you'd get a message like this:
"multiple definition of `bad_function'".... "first defined here"