osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/25/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 25 Mar 85 Volume 4 : Issue 19
Today's Topics:
_seektopbits and arithmetic routines for type off_t
fseek/ftell
six character externals
----------------------------------------------------------------------
Date: Sun, 24 Mar 85 09:13:15 est
From: ihnp4!watmath!kpmartin (Kevin Martin)
Subject: _seektopbits and arithmetic routines for type off_t
To: std-c@cbosgd.ATT.UUCP
The idea of putting the upper seek address bits in an external is a
bad idea. And another similar bad idea ('errno') is no justification for it.
The use of externals by the library is in general a bad idea, since this
causes problems when multiple processes share their external variables,
or when coroutines are used, or even if you handle signals (you get
a signal between a failed system call and the caller's 'errno' checking
code, and the signal handler itself gets an error, then returns. The main
part of the code now finds an error code completely unrelated to the error
which actually occurred).
The idea of arithmetic routines to manipulate seek offsets only works
if the fields in the off_t structure represent fixed-size items, e.g.
byte-within-block and block number. But as Mark Horton pointed out, many
systems are record-oriented, and with variable-length records, the only
way to do such arithmetic is to actually re-position the file and see
where you end up! So you need the file pointer (since the effect depends
on all the lengths of the records between cookie and cookie+offset)
The only functionality that can be implemented on non-unix systems is:
rewind(fp)
seek_to_eof(fp)
seek_to_location(fp, cookie)
seek_relative(fp, offset) /* 'offset' in bytes */
seek_relative_far(fp, offset) /* 'offset' in some large unit */
cookie = return_location(fp)
'cookie' would be an implementation-defined type. 'offset' would have an
integral type (perhaps 'int'). Since the 'seek_relative_far' routine
exists, there is no need to make the offset a really huge number.
It should be pointed out that, for a given position in a file, the cookie
should always be the same (unless the file changes, of course), no matter
how often you open and close the file, move it, rename it, copy it, etc.
Otherwise, there would be no reliable way of keeping seek addresses in
another file for later use.
Kevin Martin, UofW Software Development Group
------------------------------
Date: Sun, 24 Mar 85 11:45 EST
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: fseek/ftell
To: cbosgd!std-c@BERKELEY
If we get fseek and ftell to use a structure called off_t, when C++
comes around, we can overload + and - to act like we want them to,
i.e., call off_add(off,inc) for off + inc, etc.
Hence, I think this is a good idea.
Mark
------------------------------
Date: Sun, 24 Mar 85 11:57 EST
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: six character externals
To: cbosgd!std-c@BERKELEY
<fnord>
As long as we're going to have six character externals built into the
standard (and it looks like we will), the standard should specify that
1. If there are less than 31 chars/2 cases, there must be a reason
EXTERNAL to the compiler for it (e.g. the loader). Otherwise there will
be brain-damaged compilers that allow only 6 chars running on OSs that
allow more.
2. If there are less than 31 chars/2 cases, the compiler must generate a
warning if it sees an identify longer than its signifigant limit, and
must internally keep track of the externs to 31 chars/2 cases and give a
warning if two externs (in the same file) are different under the 31/2
model, but give the same external name to 6 or however many letter.
I.e., if the compiler has only six characters, monocase, this
extern int pigs_say_oink_1, pigs_say_oink_2 ;
generateds errors something like
WARNING: some characters in external variable(s) ignored:
pigs_say_oink_1 pigs_say_oink_2
WARNING: ambiguous external varaibles:
pigs_say_oink_1 pigs_say_oink_2
both have external name PIGS_S
(Better error messages are possible, but you get the idea.)
Mark
------------------------------
End of mod.std.c Digest - Mon, 25 Mar 85 08:26:59 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.