[mod.std.c] mod.std.c Digest Volume 4 : Issue 3

osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/04/85)

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Mon,  4 Mar 85       Volume 4 : Issue   3 

Today's Topics:
                     Comments on '\a' (and '\e')
         FILE * offset for fseek/ftell should not be a long.
----------------------------------------------------------------------

Date: Fri, 1 Mar 85 19:55:41 est
From: decvax!minow@cbosgd.ATT.UUCP
Subject: Comments on '\a' (and '\e')
To: cbosgd!std-c

The draft standard has the character escape \a for "alert".  I would 
assume that, on Unix machines that support the Ascii character set,
\a would map to decimal 7 (BEL).  I wish to argue that the problems 
are more complex, and this escape, and the proposed '\e', should not be
added to the language.

As a previous correspondent pointed out, a machine may not necessarily
have a representation for \a (and \e).  Even on an ascii machine,
the representation for \e may differ (and the choice may have to
be made at program execution time).  For example, to send an
escape (decimal 27) to a terminal on RSTS/E, you transmit decimal
155, while on RSX-11M, you transmit 27.  However, the same executable
image will run on both operating systems.  This implies that a
conforming compiler generate an out-of-band non-character value that
is magically interpreted when the program unit is run.

\a (Alert) is defined as producing an implementation-defined audible
or visible representation of an alert character.  Any
consequent alteration to the printing position is implementation-defined.
(B.3.2., page 9).

What in the world does that mean?  Does the compiler have to
understand what type of terminal the string will be sent to
(at compilation time), or is another magic character needed.
How does a conforming program handle an implementation-defined
"consequent alteration to the printing position."

This is a can of worms and is better left out of the standard
altogether.  Note that a conforming implementation may use the
string construction and concatenation operations to construct
appropriate magic characters:

	#ifdef rsts
	#define ESC	155
	#else
	#define	ESC	27
	#define ESC_STRING (... magic using # ...)
	...
	printf("esc:" ESC_STRING "...");

Note also that the ansi escape character is intended for use by
programs to control devices (e.g., to move the cursor) and programs
will increasingly use packages such as curses for doing this.
There will be sufficiently few curses implementors that the
feature won't be widely used.  (Same for \a, for that matter.)

In summary, the problems will outweigh the advantages.

Martin Minow
decvax!minow

------------------------------

Date: Sun, 3 Mar 85 21:06:04 est
From: ihnp4!decvax!minow
Subject: FILE * offset for fseek/ftell should not be a long.
To: ihnp4!hou2d!osd

On some systems, a long integer does not contain enough information
to reposition a file to a record boundary, let alone to a byte-offset
within a record.  Furthermore, on systems that have an underlying
record-oriented file I/O mechanism, a complicated remapping must
be done to change the absolute byte pointer into a record address.

I would recommend, therefore, that the object returned by ftell
and used as an argument to fseek be defined as a structure with
implementation defined contents and that no calculations be
permitted on the contents of that structure.

Martin Minow
decvax!minow

------------------------------

End of mod.std.c Digest - Mon,  4 Mar 85 08:15:38 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.