Thread: reading in a text file containing hex values

Hmm, it seems you're right . . . one of the pages I linked to, the first one, does mention it:

http://www.cplusplus.com/reference/c...dio/fopen.html

Additional characters may follow the sequence, although they should have no effect. For example, "t" is sometimes appended to make explicit the file is a text file.

The others don't, however. I just looked over them quickly, saw mention of "b", and thought they'd mention "t". That was after looking at the first page, which did mention "t" . . . ah well. Me being lazy as usual.

Another thing that may have confused me: the "t" flag does seem to be part of PHP.

• http://ca.php.net/fopen
• http://ptc.meelink.com/function.fopen.html
• http://www.freeopenbook.com/php5manu...ion.fopen.html

(I check all of those pages this time. Actually, they all contain the same text -- probably from a man page or something.)

And the way my first reference talks about "t" does indeed make it sound like an extension. Digging a little deeper . . .

http://velveeta.che.wisc.edu/octave/.../msg00419.html (Talking about Matlab)

Also, we do not mention 'b' and 't' flags in the help text . . . I'm not thrilled to have a different default from the POSIX interface --- it will surprise C programmers.

Seems to indicate that "t" is POSIX.

http://www.decompile.com/cpp/faq/fopen_write_append.htm

The Borland C++ Builder help page for fopen() says . . . To specify that a given file is being opened or created in text mode append a t to the mode string (rt w+t and so on).

Seems to indicate that "t" exists, in Borland at least.

http://msdn2.microsoft.com/en-us/lib...cb(VS.71).aspx

The c, n, and t mode options are Microsoft extensions for fopen and _fdopen and should not be used where ANSI portability is desired.

Definitely comes right out and says that "t" is not ANSI standard.

http://www.cygwin.com/ml/cygwin/1998-01/msg00142.html

First, since there is no "t" that can be passed to fopen(), it is impossible to tell if a call to fopen() wants a text mode open, or the default (blame POSIX/ANSI for that, I guess).

Seems to vaguely indicate that "t" is ANSI/POSIX standard.

http://www.mkssoftware.com/docs/man3/fopen.3.asp

t, open in text mode . . . CONFORMANCE: ANSI/ISO 9899-1990, with exceptions.

Is that one of the exceptions? Sigh.

http://developer.apple.com/documenta...3/fopen.3.html

The mode string can also include the letter ``b'' either as a third character or as a character between the characters in any of the two-charac-ter two-character strings described above. This is strictly for compatibility with ISO/IEC 9899:1990 (``ISO C90'') and has no effect; the ``b'' is ignored.

Seems to say that "b" is ANSI; no mention of "t".

I think it's safe to say that "t" isn't part of the ANSI standard, but whether it's POSIX or not is open to question. Either way, it's probably a good idea to avoid it -- though if it isn't standard, it's certainly quite widespread. I'm surprised it didn't make it into the C99 standard.

Anyway. That's interesting. I nearly always use "rt" for ordinary reading. I'll have to start using just plain "r".

>I'm surprised it didn't make it into the C99 standard.
Me too, actually. C99 added all kinds of goofy crap just to canonize bad or redundant practices, so why not a "t" mode to be symmetric with "b" mode?

Wow dwks, that's a lot of research for one letter.

But yeah, it surprised me too when I found out that it wasn't standard. But it sort of makes sense since it's not really needed.

Originally Posted by robwhit

Wow dwks, that's a lot of research for one letter.

LOL. Yeah, I'm sure the search argument was "c t" and he just reviewed all the results.

Todd

LOL. Yeah, I'm sure the search argument was "c t" and he just reviewed all the results.

People don't know how to google these days . . . googling for "c t" doesn't tell you anything. At least, unless you're interested in computed tomography or have a precious gem or need a cat scan or live in Connecticut . . .

Wow dwks, that's a lot of research for one letter.

Yes, well, I like to be thorough . . . .