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

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

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


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

Today's Topics:
                           #def CTRL(X)...
                        \ escapes in strings.
                 fseek, ftell, and existing programs
                                ftell
                   long external names via 'entry'
                pre-processor features, documentation
                         Remarks on trigraphs
                         Unique Member Names?
----------------------------------------------------------------------

Date: Fri, 15 Mar 85 21:06 EST
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: #def CTRL(X)...
To: cbosgd!std-c@BERKELEY

On one system I worked on (neither AT&T nor Berzerkeley), we had a macro
defined as:

#define CTRL(X) 'X'&'\037'

ie, CTRL(A) gave you control-A, with the idea that this was clearer than
'\001' Can one do this in ANSI C?  If not, why not - even in the
restricted reading many of you seem to prefer, K&R only disallow
replacement in strings, not character constants :-).

Seriously, this was useful, and there should be some way to do it in the
standard.

Mark

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

Date: Wed, 13 Mar 85 11:40:55 -0100
From: seismo!mcvax!jack (Jack Jansen)
Subject: \ escapes in strings.
To: std-c@cbosgd.ATT.UUCP

How about introducing 3-character escapes like \ESC, \SOH,
\BEL, etc.? These are unambiguous, do not conflict with
the current \ escapes, are easy to understand and to remember,
and could probably be implemented in any character set.

With \a, I have to think if I want to produce a bell.
(Was it \b for bell? \r for ring? \n for noise? \t for TRRRING!!?)

If the compiler detects an unknown 3-char escape, it should
give (at least) a warning that the specified sequence is unknown.

This way, if you try to use a character that is not implemented
in the character set, you get an error.

This might sound unportable, but I think it is much more
portable than \033, which will be accepted by a compiler on
an EBCDIC machine without problems, but will result in something
very different from what the author of the program meant.
	Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
Notice new, improved, faster address         ^^^^^

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

Date: 15 Mar 85 01:47:24 EST
From: John McNamee <ucbvax!jpm@BNL.ARPA>
Subject: fseek, ftell, and existing programs
To: cbosgd!std-c@BERKELEY

If the intention of the standard is not to break correct existing programs
then ftell can't be changed to return a structure. Even if this were a good
idea (which I'm not sure it is), it would break every existing program that
uses fseek or ftell.
--

			John McNamee
		 jpm@BNL.{ARPA,BITNET,UUCP}

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

Date: 14 Mar 85 14:04:55 CST (Thu)
From: ihnp4!pesnta!lsuc!dave
Subject: ftell
To: pesnta!ihnp4!cbosgd!std-c

Re lcc!richard's question about how to get lseek et al to work
on files for which 32 bits isn't enough... I can think of one
hack which should work. It's ugly, but compatible with the old
system calls.
	Have the routines work on 32 bits, as they do now. If you
call tell(), you get back the bottom 32 bits of the address in the
file. Iff you're dealing with a file which might be larger (i.e.,
most applications probably won't bother), you check a global,
externally-declared variable _seektopbits (or whatever it's called).
Similarly, if you want to seek to position 1.0e11 in the file, you
stuff the top (left of 32) bits into _seektopbits and call lseek().
	This isn't all that inconsistent with the way some things
are done in UNIX. Consider the error return values from system calls,
for example, where you can (but most people don't) go examine the
externally-declared variable "errno".

Dave Sherman
The Law Society of Upper Canada
ihnp4!utzoo!lsuc!dave

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

Date: 16 Mar 85 00:34:50 CST (Sat)
From: ihnp4!utzoo!henry
Subject: long external names via 'entry'
To: ihnp4!cbosgd!std-c

> First, one extension has been proposed on Info-C that I would like to
> strongly second.  That is to reactivate the "entry" keyword and use it
> to allow the internal and external names of a global item be different,
> e.g.
> 
>           extern int date_and_time() entry "SYS$TIME";
>           extern int memory_size entry "CSYS$MEMSIZ";

As has been pointed out before, *if* your external names do not have
a different alphabet from the internal ones -- the $ in the examples
is troublesome -- then this can be done with the preprocessor, i.e.
without any language change at all.  The preprocessor's identifiers
are internal, hence are required to be long.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

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

Date: 15 Mar 85 02:59:15 CST (Fri)
From: ihnp4!utcs!mnetor!clewis (Chris Lewis)
Subject: pre-processor features, documentation
To: utcs!utzoo!ihnp4!hou2d!osd

I still haven't found the "Extensions to C" document from '78 that
mentions structure field name space and the define formal replacement
junk.  However, it is in the System V manuals. I quote (from page 102
"UNIX System, Programming Guide", Issue 1, June 1982):

	Strings and character constants in the token string [ body
	of parameterized macro ] are scanned for formal parameters,
	but strings and character constants in the rest of the program
	are not scanned for defined identifiers to replacement [sic!]

The line in the 78 document is similar but somewhat more obscure.
The copy of the '78 document I saw came with the distribution of C/370
from Bell Labs.
----
Chris Lewis, Motorola New Enterprises
SNail: 560 Dennison, Unit 9, Markham, Ontario, Canada, L3R 2M8
UUCP: {allegra, linus, ihnp4}!utzoo!utcs!mnetor!clewis
BELL: (416)-475-1300 ext. 321

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

Date: Thu, 14 Mar 85 16:00:30 est
From: ihnp4!watmath!watdaisy!ndiamond (Norman Diamond)
Subject: Remarks on trigraphs
To: ihnp4!cbosgd!std-c

Remarks about trigraphs...

>           ??=       #
>           ??(       [
>           ??/       \
>           ??)       ]
>           ??'       ^
>           ??<       {
>           ??!       |
>           ??>       }
>           ??-       ~

            ??/n      \n
            ??/01a    \01a
            ??/???/?  ??      ( ??/? converts to ? twice )
etc.

(1)  Why not make // a digraph for \ ??

(2)  And why not use other sensible (obvious and presently non-syntactic)
digraphs for the other characters??

(3)  If a country wishes to use some of those byte codes as alphabetics,
then what kind of substitution can be done inside a string??  Will they
end up with the same alphabetic they would have obtained by using the
individual character instead of the trigraph?  Or will the trigraph map
onto a byte value exceeding 127??  Is it really a good idea to convert
trigraphs (or digraphs) in strings??

(4)  If C is supposed to be portable, then won't EVERY program in EVERY
country have to use the trigraphs (or whatever agreed-on method) for those
characters??  And, an alphabetic in one country might be non-alphabetic in
another country (my language does not include a 27th, or 53rd depending on
how you're counting), so won't EVERY program have to avoid using those
additional alphabetics??  Portability means that the character set shrinks,
and the ambiguous characters cannot be used for any purpose, n'est-ce pas??

-- Norman Diamond

UUCP:  {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA:  ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa

"Opinions are those of the keyboard, and do not reflect on me or higher-ups."

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

Date: Sat, 16 Mar 85 22:42:21 est
From: psuvax1!dae (Dave Eckhardt)
Subject: Unique Member Names?
To: std-c@cbosgd.ATT.UUCP

Does the standard specifically mention the legality of the following?

struct foo
	{
	int length;
	char wood;
	double dealer;
	};
struct bar
	{
	int length;
	float hot_air_balloon;
	short dealer;
	};

For whatever it's worth, 4.2 cc and lint both pass the above.

--Daemon

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

End of mod.std.c Digest - Mon, 18 Mar 85 22:43:16 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.