osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/26/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 25 Feb 85 Volume 3 : Issue 11
Today's Topics:
\l vs. \n
allowing implementors to punt
case >20 isn't the same as 'default'
Justification for "string" "concatenation"
----------------------------------------------------------------------
Date: Sun, 24 Feb 85 20:51:45 est
From: watmath!kpmartin@cbosgd.ATT.UUCP (Kevin Martin)
Subject: \l vs. \n
To: cbosgd!std-c
I know of at least one operating system which uses the record separator
character (I forget the octal value, ctrl-^) for a newline. If you write
such a character to the terminal, you get CR/LF. If you write \015, you get
just a carriage return; if you write \012, you get just a linefeed. Their
implementation language (which is sort of a cross between B and C) uses the
character escapes '*n', '*r', and '*l' for newline, return, and linefeed
respectively.
The main problem with having a \l character is that people will start
trying to use it to get a linefeed on the terminal. Such programs won't
work on systems where you can't do that (e.g. unix) without trickery.
Kevin Martin, UofW Software Development Group
------------------------------
Date: Sun, 24 Feb 85 19:08:49 est
From: ima!haddock!stevel@cbosgd.ATT.UUCP
Subject: allowing implementors to punt
To: cbosgd!std-c
In mod.std.c V3 #7 Ken Arnold states:
"which the implementor is therefore allowed to punt, as long as"
and a list of what the implementor has to document.
This is totally wrong. Why have a standard that allows portability
for every other major aspect and allow or even requires
implementors to "punt" on one of the biggest. Setting up a
portable standard and then allowing implementors to punt is
useless. The C standard should be implementable on a wide variety
of machines. Not all compiler writers have control over the
linker. Often the linker is sold by a separate company.
If the standard doesn't allow you to port your programs to all
the machines that have 6-7 character linkers, and there are a lot
of them, I say why bother with the standard.
I hope people stop arguing about external character names and
concentrate on important *** controllable *** features.
Steve Ludlum, decvax!yale-co!ima!stevel, {ihnp4!cbosgd}!ima!stevel
Interactive Systems, 7th floor, 441 Stuart st, Boston, MA 02116; 617-247-1155
------------------------------
Date: Sun, 24 Feb 85 21:02:16 est
From: watmath!kpmartin@cbosgd.ATT.UUCP (Kevin Martin)
Subject: case >20 isn't the same as 'default'
To: cbosgd!std-c
>From mod.std.c Digest - Fri, 22 Feb 85 07:31:24 EST
>From: Craig Partridge <cbosgd!ucbvax!craig@loki.ARPA>
>Kevin Martin writes to suggest adding comparative operators into
>case statements. I'd like to point out that at least
>
> case >20: -----
>
>is already handled by the language -- the appropriate keyword
>is "default".
/* Search the sorted binary tree rooted at 'p' */
while (p)
switch (strcmp(arg, p->name)) {
case >0:
p = p->right;
continue;
case 0:
return p;
case <0:
p = p->left;
continue;
}
Let's see you do that with 'default'.
For that matter, try coding the above without a switch statement, and
without a temporary variable to obscure the code.
Kevin Martin, UofW Software Development Group
------------------------------
Date: Sun, 24 Feb 85 21:16:43 est
From: watmath!kpmartin@cbosgd.ATT.UUCP (Kevin Martin)
Subject: Justification for "string" "concatenation"
To: cbosgd!std-c
>From mod.std.c Digest Fri, 22 Feb 85 Volume 3 : Issue 7
>From Ken Arnold:
>*Reference: C.1.4 String literals; Syntax & Semantics (p. 20)
>This is a new feature. It basically says that
>
> "hi" "there"
>
>is equivalent to
>
> "hithere"
>
>Now, the real question: Why? What does adding this feature to the
>language accomplish?
It allows a clean way of folding long strings across multiple lines.
You can even indent the second part of the string to match the code
which contains it. (Unlike the current \<newline>)
It also helps to avoid (but doesn't avoid completely) the prickly
question of CPP macro formal parameter replacement within strings.
e.g. rather than argue about whether
#define str(prefix) "prefix: This is a string"
char *p = str(foo);
will work, you can now do:
#define str(prefix) prefix ": This is a string"
char *p = str("foo");
which is probably slightly clearer anyway (reading the invocation of
'str', you are immediately clued in that 'foo' is just part of a string,
not an identifier).
Kevin Martin, UofW Software Development Group
------------------------------
End of mod.std.c Digest - Mon, 25 Feb 85 20:23:14 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.