VMS Specific question about binary reads using fgetc

[Martin Weitzel]

In article <1951 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
[about 32-bit values beeing too small to represent file position offsets]
>A strategy that DEC could have used, but did not, would have been to
>make ftell() return a magic cookie.  The magic cookie would exactly
>encode record number and offset for small files.  For larger files, the
>magic cookie would be the index of a seek value in an internal table.
>This table would grow as needed.

The "magic cookie" approach is exactly what ANSI-C supports through
the (new) "fgetpos/fsetpos" functions. IMHO it could not be generally
applied to "ftell/fseek", because it is existing practice to do some
arithmetic with the return value (eg. to advance some bytes in either
direction).

This should also be taken as a guideline, *when* to use *which* of
the two similar functions for positioning in files.

1) Use "fgetpos/fsetpos" regardless of the file type (binary or
   text), if you only want "mark" some places for later "restore".

2) Use "ftell/fseek" only if you are sure that the following
   restrictions will be met:
   a) For a "text"-file, you only fseek to the start (offset 0
      with SEEK_SET), the current postion (offset 0 with SEEK_CUR,
      somewhat pointless but allowed) or to the end (offset 0
      with SEEK_END). 
      Otherwise you use *exactly* the value that is returned from
      "ftell" (no arithmetics!) as offset with SEEK_SET.
   b) For a "binary"-file you may "fseek" to any position, even
      one you calculate by doing some arithmetic with the return
      value of "ftell", but be sure that the maximum file size
      will fit into a long on the target hardware.

Note that 2a) opens the door for the "magic cookie"-approach,
but it can only be applied to "text"-files. Obviously, ANSI-C
misses to specify a *portable* method to seek around within
binary files with sizes that exceed the range of values for
a long. IMHO, this is not a serious drawback (though I'm sure
that there are some readers on the net who will exactly have
this requirement :-)). But consider that many operating systems
currently do not support files of this size, that even if they
do, files of this size are not very frequently found, and that
nobody forbids a C-implementation to support additional library
functions that adress the problem.
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83