Updated documentation to match API 0.7.2

[projects/chimara/chimara.git] / docs / reference / glk-porting.sgml

diff --git a/docs/reference/glk-porting.sgml b/docs/reference/glk-porting.sgml
index b90f7c37b7a784a62c93dbc492dd4e90c118df26..6931986cc0b8c538300b2a8a9f70ffd604d65d1c 100644 (file)
--- a/docs/reference/glk-porting.sgml
+++ b/docs/reference/glk-porting.sgml
@@ -84,7 +84,7 @@ By the way, the next person I see who <code>#define</code>s <function>memmove()<
 This is the real nuisance, because Glk provides a limited set of stream and file functions. And yet there are all these beautiful ANSI stdio calls, which have all these clever tricks &mdash; <function>ungetc()</function>, fast macro <function>fgetc()</function>, formatted <function>fprintf()</function>, not to mention the joys of direct pathname manipulation. Why bother with the Glk calls?
 </para>
 <para>
-The problem is, the stdio library really isn't always the best choice. PalmOS and Newton simply don't use stdio. The Mac has a stdio library built on top of its native file API, but it's a large extra library which porters may not wish to link in.
+The problem is, the stdio library really isn't always the best choice, particularly on mobile OSes.
 </para>
 <para>
 There's also the problem of hooking into the Glk API. Window output goes through Glk streams.