TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Out of a hacker's interest, I am wondering if there is any byte sequence that can never occur in any valid TeX document before \end is processed.

I thought of things like


which opens an unclosable group, but this one can trivially be neutralized by moving the catcode 0 on \ away first.

share|improve this question

There is no byte sequence that may not occur somewhere in a file (obviously there are restrictions at the beginning of a file before you change catcodes) however there are sequences of character tokens that may never occur. Specifically relating to white space trimming and normalisation at the end of lines, white space at end of line is stripped at a very early stage by tex-the-program and this can not be controlled from within a TeX file. This is the main reason for example that the xmltex macros can not handle utf-16 Unicode encoding as white space stripping can cause the random bytes to be dropped and so the parity of the bytes for the whole document can not be ensured. (Utf-8 does not have this problem as bytes in the ascii range are never used as part of multi-byte encoded characters in utf-8) .

share|improve this answer

TeX has the concept of an invalid character (a byte sequence with \catcode 15) so if TeX is being set up with any 8 bit character having this catcode then obviously a format doing so will choke on a file containing this character.

By default (and probably for historical reasons) plain TeX and LaTeX have one character of that nature: "delete" (which is ^^K), so if you have this one in your file you get

! Text line contains an invalid character.
l.1 ^^K

But of course, once you changed the catcode the byte sequence could appear and if you do it as part of the format it could appear always, so from that perspective no byte sequence is always invalid.

share|improve this answer
That actually looks like it's leading somewhere... so what if the "invalid byte sequence" first tries to set the catcode of a character to 15 (invalid)... and tries 256 times so it does not matter WHICH character has the catcode 0... but this won't work if inside \iffalse ... \fi. Which yields another idea... a "long enough" sequence of \fi, where \ cycles through all available characters, so it is more "fi"s than the maximum allowed nesting depth... – Rudolf Polzer May 3 '13 at 14:24
I think I found the/a solution... there is no outright impossible byte sequence at all. Proof: Assume an impossible byte sequence "IMPOSSIBLE" of length $n$ exists. Then set "XYYYYYYYYYY" to a sequence of length $n+1$ consisting of one "X" and $n$ "Y". Then look at this document: \long\def\v#1XYYYYYYYYYY{} \v IMPOSSIBLE ZXYYYYYYYYYY The macro expands to nothing, and TeX has not parsed the contents of the argument yet... which means we win. If it weren't for invalid characters (\catcode 15) and \outer\def's... fixing the catcodes is easy, but can the \outer one (e.g. on "\+") be fixed too? – Rudolf Polzer May 3 '13 at 15:35
@RudolfPolzer Before calling your \v, set all category codes to 12 (say). Something like \def\v{\bgroup\count0=0\loop\catcode\count0=12\advance\count0 1 \ifnum\count0<256 \repeat\vaux} \def\vaux#1,,,,.{\egroup} \v #$%&-not-actually-impossible-\#&$^ ,,,,. – Bruno Le Floch May 3 '13 at 20:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.