ctrl+z

I have a little getline function that works okay unless there's a ctrl+z in the stream. Here's some code:

Code:

#include <stdio.h>
#include <string.h>


/* return true:
     the string is empty due to hitting a delimiter right away
     the string is not empty
   return false:
     the string is empty due to eof or a stream error */
int getline( char *string, int size, char delimiter ) {
  int i = 0;
  int c;

  if ( size > 0 ) {
    // stop reading at size, eof, or a delimiter
    while ( --size > 0
      && ( c = getchar() ) != EOF
      && ( string[i++] = c ) != delimiter );

    // trim the delimiter if it's there and end the string
    string[i - ( i && string[i - 1] == delimiter )] = '\0';

    // clear the stream  up to the next delimiter
    while ( stdin->_cnt > 0
      && !ferror( stdin )
      && ( c = getchar() ) != EOF
      && c != delimiter );
  }

  return i != 0;
}


int main( void ) {
  char array[5];

  while ( 1 ) {
    int rc = getline( array, 5, '\n' );
    printf( "%d: %s\n", rc, array );
  }

  return 0;
}

If I type "abcd^Z" it works. If I type "abc^Z", it doesn't see the eof and puts ascii 26 as the last character. I can check for ascii 26, but that's kludgy. Can somebody suggest something better?

> stdin->_cnt > 0
Why do you have this - it isn't portable.

The recognition of ctrl-z as signalling EOF only happens at the start of the line.
At other points, I see a multitude of interesting effects.

> stdin->_cnt > 0
Why do you have this - it isn't portable.

What I'm trying to do isn't portable either.

The recognition of ctrl-z as signalling EOF only happens at the start of the line.
At other points, I see a multitude of interesting effects.

The only way around it I can think of is conditional compiling if eof comes from ctrl+z...

Code:

    // stop reading at size, eof, or a delimiter
    while ( --size > 0
      && ( c = getchar() ) != EOF
#ifdef EOF_CTRLZ
      && c != 26
#endif
      && ( string[i++] = c ) != delimiter );

But I don't like it. There has to be a better way that I'm not smart enough to see.

Well I've tried it with cygwin and vc6, and neither of those seem to be returning the literal value of ctrl-z in the input buffer.

I'd be surprised if any of them do. Ctrl+Z or ctrl+D is just what the shell / console uses as EOF, not your actual program. As far as I'm aware, all it just passes EOF to them, not the ctrl+value.

Quzah.

EOF has to be represented by something, quzah. Under several flavours of unix, a CTRL-D (ASCII value 4) encountered in a file stream is taken to be an indicator of end of file; when C standard I/O functions such as fgetc() encounter a CTRL-D character in a stream they return EOF. Similarly, under windows, a CTRL-Z (ASCII value 26) is treated as an EOF marker. If you look at the workings of some file systems, a CTRL-D or CTRL-Z character (or a set of two or more such characters) is actually written to disk to mark the end of the file on disk.

Originally Posted by grumpy

EOF has to be represented by something, quzah.

Naturally. It's represented as EOF.

Originally Posted by grumpy

Under several flavours of unix, a CTRL-D (ASCII value 4) encountered in a file stream is taken to be an indicator of end of file; when C standard I/O functions such as fgetc() encounter a CTRL-D character in a stream they return EOF.

Which clearly is wrong when compared to what EOF is by definition: negative.

Originally Posted by grumpy

Similarly, under windows, a CTRL-Z (ASCII value 26) is treated as an EOF marker. If you look at the workings of some file systems, a CTRL-D or CTRL-Z character (or a set of two or more such characters) is actually written to disk to mark the end of the file on disk.

And again. EOF cannot be represented in a char. Therefore, it should never ever be represented as a positive value, because that is 180 degrees of what the standard says it is. It's negative. Always.


Quzah.

You missed the point, quzah. When CTRL-D and CTRL-Z characters (or other ones, depending on OS) occur in a file or stream they are taken as markers indicating end of that file (or a stream). When functions like fgetc() (or OS-specific functions that might be called to implement fgetc()) encounter those markers, fgetc() will return EOF. In other words, the implementation of functions like fgetc() will include logic that yields behaviour functionally equivalent to;

Code:

    if (character_read_from_stream == 4)    /*  unix behaviour: detect CTRL-D in stream */
        return EOF;

That is not wrong according to the standard: the C standard does not mandate how files are laid out on a disk or other hardware. It only requires that an end-of-file be detected, and that EOF be returned by C I/O functions when it is.

There is also no actual requirement in the C standard that EOF be a negative value. The actual requirement is that EOF be an integral value that cannot be stored in an unsigned char. A negative value is one possibility. A large positive value (which exceeds the maximum value that can be stored in an unsigned char) is another.

No, it is a part of the standard that it must be negative:

Originally Posted by The Standard, 7.19.1

EOF
which expands to an integer constant expression, with type int and a negative value, that
is returned by several functions to indicate end-of-file, that is, no more input from a
stream;

Anyway, the control characters are usually read as two keys, not one. But it seems to me that it's entirely up to your shell what key you hit to be EOF. So, it should be that it just sends EOF directly to the program, not the control key sequence. Maybe not, but that's how it seems like it should work to me.


Quzah.

It is strange that some texts I have read state that using EOF is considered poor practice, and others say it can be used in exceptional circumstances. Personally, I rarely use it, only really had to once when creating a grade book class for an assignment. Didn't work properly anyway. But I suppose everybody has a use for a function where others will always differ, All parts of the language where designed to do somthing.

Just my two cents.

I fixed that with a macro. It's not pretty, but it works for me. I can't test it on places that don't use ctrl+z for eof though. A friend also told me that it didn't work on his compiler because of the 'stdin->_cnt' part. He uses a borland compiler, so I guess whoever told me that _cnt is used everywhere was wrong. I fixed that too, but I'm not sure it's a good fix but it's portable now. You guys were kind enough to help me out before, can you give me a code review?

Code:

#include <stdio.h>
#include <string.h>


// remove this behavior with EOF instead of 26
#define EOF_CTRLZ 26


/* return true:
     the string is empty due to hitting a delimiter right away
     the string is not empty
   return false:
     the string is empty due to eof or a stream error */
int getline( char *string, int size, char delimiter ) {
  int rc = 0;

  if ( size > 0 ) {
    int c = delimiter;
    int i = 0;

    // stop reading at size - 1, eof, or a delimiter
    while ( --size > 0
      && ( c = getchar() ) != EOF
      && c != EOF_CTRLZ
      && c != delimiter ) {

      string[i++] = c;
    }

    string[i] = '\0';
    rc = i > 0 || c == delimiter;

    if ( size ) {
      // force some input so clearing doesn't block
      ungetc( delimiter, stdin );
    }

    // clear up to eof or the next delimiter
    while ( !ferror( stdin )
      && ( c = getchar() ) != EOF
      && c != EOF_CTRLZ
      && c != delimiter );
  }

  return rc;
}


int main( void ) {
  char array[5];

  while ( 1 ) {
    int rc = getline( array, 5, '\n' );
    printf( "%d: %s\n", rc, array );
  }

  return 0;
}

Correct, Borland uses a really weird File struct. Instead of _cnt it's level.... Weird.

Yeah, weird. I wonder how many other compilers are weird.

Well FILE is supposed to be an opaque type, all you ever need worry about is storing a FILE* and passing it to routines which need it. Every single implementation is free to define members of that struct (assuming it is even a struct) as it sees fit. It's only because some things like getc() can be a macro that you can see inside it at all.

Taking sneak peeks at the innards is just asking for trouble.

Holy cow people, why not just switch the file to binary mode? It's stdin, right?

Code:

freopen(NULL, "rb", stdin);

Now the Ctrl-Z will come through always, and you can process it how you want.