Return type of "readin" and correct error handling

[Victor Lagerkvist]

Greetings, I know it's usually a bad habit to include several questions in a
single message, but they are quite related.

I have declared and defined a function named readin, whose purpose is to get
input from stdin and save the result in a character array (provided the
input does not exceed the maximum limit). Somehow it feels natural that
readin will then have the type "char *" and return the obtained input to
whoever calls it (or rather, the address of the first element?). Such as
this:

char *readin();

However, in case anything goes wrong readin should be able to return an
error code to the function that called it.

I "solved" the problem with the following declaration of readin:

int readin (char *);

Which makes it possible to return -1, and the function that calls readin
always tests the return value in an if-clause. From my brief and
incomprehensibl e explanation, does this look like an acceptable solution -
or are there better, standardized ways to perform error testing? I'm new to
C and am therefore trying to pick up as few bad habits as possible.

[Roland Pibinger]

On Sun, 17 Jun 2007 10:02:18 GMT, Victor Lagerkvist wrote:

>However, in case anything goes wrong readin should be able to return an
error code to the function that called it.

I "solved" the problem with the following declaration of readin:

int readin (char *);

Which makes it possible to return -1, and the function that calls readin
always tests the return value in an if-clause. From my brief and
incomprehensib le explanation, does this look like an acceptable solution -
or are there better, standardized ways to perform error testing? I'm new to
C and am therefore trying to pick up as few bad habits as possible.

Compare your solution to Microsoft's (it's just a comparison of
interfaces, not the off-topic discussion of a non C-Standard library):
BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesT oRead,
LPDWORD lpNumberOfBytes Read,
LPOVERLAPPED lpOverlapped
);

http://msdn2.microsoft.com/en-us/library/aa365467.aspx
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Richard Heathfield]

Victor Lagerkvist said:

<snip>

>
char *readin();

However, in case anything goes wrong readin should be able to return
an error code to the function that called it.

I "solved" the problem with the following declaration of readin:

int readin (char *);

Which makes it possible to return -1, and the function that calls
readin always tests the return value in an if-clause.

How does readin() know how much data it can safely store in the buffer
whose first byte is pointed to by its parameter?

From my brief
and incomprehensibl e explanation, does this look like an acceptable
solution - or are there better, standardized ways to perform error
testing? I'm new to C and am therefore trying to pick up as few bad
habits as possible.

My own strategy is much like yours - I generally return an int error
code from my functions, unless they are object-creating functions, in
which case I return either a pointer to the new object or NULL if the
object could not be created.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Victor Lagerkvist wrote:

>

.... snip ...

>
I "solved" the problem with the following declaration of readin:

int readin (char *);

Which makes it possible to return -1, and the function that calls
readin always tests the return value in an if-clause. From my
brief and incomprehensibl e explanation, does this look like an
acceptable solution - or are there better, standardized ways to
perform error testing? I'm new to C and am therefore trying to
pick up as few bad habits as possible.

Sounds good. In fact, it is almost exactly what ggets does, which
returns EOF for EOF, 0 for good operation, and something positive
for i/o error. See:

<http://cbfalconer.home .att.net/download/>

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Victor Lagerkvist]

Richard Heathfield wrote:

How does readin() know how much data it can safely store in the buffer
whose first byte is pointed to by its parameter?

I currently use #define to specify the largest amount of allowed characters.

[pete]

Victor Lagerkvist wrote:

>
Richard Heathfield wrote:

How does readin() know how much data it can
safely store in the buffer
whose first byte is pointed to by its parameter?

I currently use #define to specify
the largest amount of allowed characters.

In that case, you can use fscanf.
/* BEGIN fscanf_input.c */
/*
** There are only three different values
** that can be assigned to the int variable rc
** from the fscanf calls in this program;
** They are:
** EOF
** 0
** 1
** If rc equals EOF, then the end of file was reached,
** or there is some other input problem;
** ferror and feof can be used to distinguish which.
** If rc equals 0, then an empty line
** (a line consisting only of one newline character)
** was entered, and the array contains garbage values.
** If rc equals 1, then there is a string in the array.
** Up to LENGTH number of characters are read
** from a line of a text stream
** and written to a string in an array.
** The newline character in the text line is replaced
** by a null character in the array.
** If the line is longer than LENGTH,
** then the extra characters are discarded.
*/
#include <stdio.h>

#define LENGTH 40
#define str(x) # x
#define xstr(x) str(x)

int main(void)
{
int rc;
char array[LENGTH + 1];

puts("The LENGTH macro is " xstr(LENGTH) ".");
do {
fputs("Enter any line of text to continue,\n"
"or just hit the Enter key to quit:", stdout);
fflush(stdout);
rc = fscanf(stdin, "%" xstr(LENGTH) "[^\n]%*[^\n]", array);
if (!feof(stdin)) {
getc(stdin);
}
if (rc == 0) {
array[0] = '\0';
}
if (rc == EOF) {
puts("rc equals EOF");
} else {
printf("rc is %d. Your string is:%s\n\n", rc, array);
}
} while (rc == 1);
return 0;
}

/* END fscanf_input.c */

--
pete

[Keith Thompson]

Victor Lagerkvist <pl*******@gmai l.comwrites:

Richard Heathfield wrote:

>How does readin() know how much data it can safely store in the
buffer whose first byte is pointed to by its parameter?

I currently use #define to specify the largest amount of allowed
characters.

Ok.

You said "currently" . Does that imply that you might later want it to
be more flexible, allowing the maximum size to vary for each call? If
so, you should consider allowing for that in the interface now.

On the other hand, perhaps the size will always be fixed, or perhaps
you'll want to allocate the space dynamically.

There are lots of possibilities. It can be helpful to anticipate any
changes and nail down the interface early, but that's not always
possible.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Victor Lagerkvist]

Keith Thompson wrote:

Victor Lagerkvist <pl*******@gmai l.comwrites:

>Richard Heathfield wrote:

>>How does readin() know how much data it can safely store in the
buffer whose first byte is pointed to by its parameter?

I currently use #define to specify the largest amount of allowed
characters.

Ok.

You said "currently" . Does that imply that you might later want it to
be more flexible, allowing the maximum size to vary for each call? If
so, you should consider allowing for that in the interface now.

Yes... I'm pondering whether or not it is a good idea to save all user input
in an array for future references. In that case it would be neat if the
stored arrays weren't larger than the sentences they hold (currently every
array have place for the largest amount of allowed characters, which might
be wasteful if the backlog is big). Would it suffice to first get the user
input and save it in a "big" array and then copy it's content in a smaller
one of the same size as the number of characters the user entered? It
doesn't seem perfect, but I can't think of anything else since it's
impossible to tell how huge the input is beforehand.

[Richard Heathfield]

Victor Lagerkvist said:

It doesn't seem perfect, but I can't
think of anything else since it's impossible to tell how huge the
input is beforehand.

The trick is to resize as you go.

How you do this is up to you - you can go for simple, or flexible, or
anything in between.

Here are four quite different approaches to the problem, all with full C
source code.

My own fgetline() - borders on the flexible:
http://www.cpax.org.uk/prg/writings/fgetdata.php

Chuck Falconer's ggets() - simple but unbending:
http://cbfalconer.home.att.net/download/ggets.zip

Morris Dovey's rather strangely recursive gline():
http://www.iedu.com/mrd/c/getsm.c

Eric Sosman's hide-it-all-away getline() function:
http://www.cpax.org.uk/prg/portable/...sman/index.php

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[pete]

Richard Heathfield wrote:

>
Victor Lagerkvist said:

It doesn't seem perfect, but I can't
think of anything else since it's impossible to tell how huge the
input is beforehand.

The trick is to resize as you go.

How you do this is up to you - you can go for simple, or flexible, or
anything in between.

Here are four quite different approaches to the problem, all with full C
source code.

My own fgetline() - borders on the flexible:
http://www.cpax.org.uk/prg/writings/fgetdata.php

Chuck Falconer's ggets() - simple but unbending:
http://cbfalconer.home.att.net/download/ggets.zip

Morris Dovey's rather strangely recursive gline():
http://www.iedu.com/mrd/c/getsm.c

Eric Sosman's hide-it-all-away getline() function:
http://www.cpax.org.uk/prg/portable/...sman/index.php

Hey, I've got one too!

http://www.mindspring.com/~pfilandr/...ine/get_line.c

.... and, it has 2 siblings:

http://www.mindspring.com/~pfilandr/...ne/get_delim.c
http://www.mindspring.com/~pfilandr/...t_delimeters.c

--
pete