Member Avatar for BLUEC0RE

My program has a function that reads in information until it hits a designated character, takes the text just before that character, does something with it, and then comes back for more text starting at that designated character.

So...
Special character is: 'z'
Text file: "This is a lot of text and I am only saying zune because it possess the character."

The first chunk : "This is a lot of text and I am only saying "
The second chunk: "zune because it possess the character."

My dilemma is that in order to check ahead and see the 'z', I need to first read in the z and then check its ascii number. This causes problems because the file pointer loses the 'z' and now is "une because it possess the character."

Is there any way to check ahead without losing information while reading? I'm looking for maybe a function call I overlooked or a method to do so. You do not need to present code.

Thanks

Edited by BLUEC0RE because: More Info
  • 3 Contributors
  • 7 Replies
  • 183 Views
  • 16 Hours Discussion Span
  • Latest Post Latest Post by WaltP

Dani AI

Generated

The problem you describe (needing to look ahead without permanently consuming the next character) is common when writing a streaming parser — ’s “folded line” case (detect CRLF then a space on the following line) is a classic example. Replies from and point in useful directions; here are practical, portable patterns that avoid surprising behavior when the stream is non-seekable or when you need more than one byte of lookahead.

A simple, robust approach is to implement a tiny parser-side pushback buffer. It gives full control, avoids platform text-mode seek oddities, and supports several bytes of lookahead without relying on the FILE* repositioning rules. Example sketch:

typedef struct { FILE *f; int pb[4]; int pb_cnt; } Reader;

int rdr_get(Reader *r) {
    if (r->pb_cnt > 0) return r->pb[--r->pb_cnt];
    return fgetc(r->f);
}

int rdr_unget(Reader *r, int c) {
    if (c == EOF || r->pb_cnt >= 4) return EOF; // handle overflow
    r->pb[r->pb_cnt++] = c;
    return c;
}

If the file is seekable and you prefer that route, save the byte-offset with ftell, read ahead, and fseek back — but use it only for binary or reliably local files. On some platforms text-mode streams can translate newlines or return implementation-defined positions, so ftell/fseek are less portable there.

Watch multibyte encodings: operate on decoded codepoints (or treat the stream strictly as bytes) so lookahead doesn’t split a multi-byte character. For most small lookahead needs, a parser-managed pushback buffer is the safest, most predictable choice.

Recommended Answers

All 7 Replies

Member Avatar for WaltP

You'd be better off reading the entire line and looking through the array rather than trying to mess around with complex file reading techniques. If you can read the entire file, so much the better.

Member Avatar for BLUEC0RE

hmm..
well not diving into my project too much, I need to tell whether something is "folded" which mean I need to find in sequential order'\r''\n' and a ' ' on the next line. If the space is anything other than a space it is declared not folded and will be read later. The problem occurs when there it is not folded and the program actually takes in the first character of the next string to test for the line being folded.

I just was reading my book and came across ungetc(); might be useful.

Member Avatar for BLUEC0RE

success!
ungetc() is a lifesaver. Thanks for commenting anyways. Always helpful!

Edited by BLUEC0RE because: n/a
Member Avatar for WaltP

But ungetc() is non-standard and therefore not recommended. It will not work in most compilers.

Member Avatar for BLUEC0RE

Thanks for the heads up I'll ask my TA if its okay to use.

Member Avatar for Trentacle

But ungetc() is non-standard and therefore not recommended. It will not work in most compilers.

Standard section (The ungetc function) begs to differ.

Member Avatar for WaltP

Standard section (The ungetc function) begs to differ.

Ahh, sorry. I forgot it's not related to getch() . My mistake.

But I still think it shouldn't be used.

Edited by WaltP because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.