osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/20/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 20 Mar 85 Volume 4 : Issue 17
Today's Topics:
#define CTRL(X)... (2 msgs)
ftell (2 msgs)
three-character escapes (3 msgs)
Unique Member Names?
----------------------------------------------------------------------
Date: Tue, 19 Mar 85 21:24:30 EST
From: ihnp4!seismo!elsie!ado
Subject: #define CTRL(X)...
To: homxa!osd7
> On one system I worked on. . .we had a macro defined as:
>
> #define CTRL(X) 'X'&'\037'
>
> ie, CTRL(A) gave you control-A. . .Can one do this in ANSI C?
> If not, why not. . .
The "why nots" have been covered by others.
One can "do this" in ANSI C with a
#define Ctrl(X) ((X)&'\037')
preprocessor directive and, ie, Ctrl('A').
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
[ An even shorter version was sent by Mark Horton.
#define Ctrl(X) ((X) & 037)
-- Mod -- ]
------------------------------
Date: 19 Mar 85 23:47:24 CST (Tue)
From: ihnp4!utzoo!henry
Subject: #define CTRL(X)...
To: ihnp4!cbosgd!std-c
> ...even in the
> restricted reading many of you seem to prefer, K&R only disallow
> replacement in strings, not character constants :-).
Sorry, the sentence in K&R mentions both strings and character constants.
We won't let you off that easy... :-)
More seriously, CTRL(X) is an interesting idea, but surely naming the
funny characters by their names (ESC, SOH, etc.) is better than naming
them by the accidents of your favorite keyboard. Note that what you
type to get, say, ESC, is keyboard-dependent to some small degree, so
the ctrl-foo notation is not as universal as one might hope.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Tue, 19 Mar 85 16:04:45 est
From: mark@cbosgd.ATT.UUCP (Mark Horton)
Subject: ftell
To: std-c@cbosgd.uucp
>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.
But the compiler or lint will catch these cases, and the change is trivial,
just change "long" to "off_t" or whatever the new cookie is called.
> 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".
Actually, this reminds me of the old V6 seek system call. I just don't
see this working out. For one thing, on many (non-UNIX) systems, the
off_t type will be a tuple, something like (block, record, char). You
can't treat this as a simple integer and do arithmetic on it and get
meaningful results. And it's too big to encode all three in a 32 bit
integer - you'd have to put unreasonable restrictions on the maximum
size of each field. The other problem is that you sometimes see code
like this:
fseek(fd, 0L, 0);
(yes, they should have used rewind, but they didn't. Lots of times this
appears as an lseek call, and there is no system call equivalent to rewind.)
I'm pretty sure I once read that the thing returned by ftell was supposed
to be treated as a magic cookie and that such cookies were the only things
that could be passed to fseek; however, the C book doesn't seem to mention
this - it barely admits that fseek is in the stdio library.
Mark Horton
------------------------------
Date: Wed, 20 Mar 85 10:54:25 est
From: decvax!bunker!garys
Subject: ftell
To: decvax!ihnp4!cbosgd!std-c
Re Dave Sherman's solution to the lseek problem (a long
may not provide enough information):
> 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.
So far so good...
> 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)...
If you're dealing with a file which might be larger, instead
of calling tell() or ftell(), how about calling tell2() or
ftell2() ? I.e., would it not be preferable to write a new
routine to handle the new situation? (Lots of small tools,
each of which does one thing well).
> This isn't all that inconsistent with the way some things
> are done in UNIX.
"A foolish consistency is the hobgoblin of little minds."
Let's not be consistent, if it means doing ugly things like
adding globals.
> 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".
A lot of people don't even examine the return values, let alone
"errno". Why couldn't the system calls return 0 if all went
well, and an error code otherwise? Or a nonnegative number,
if it needs to return some information beyond ok/not ok, and
a negative number in case of an error? Too late now, I suppose.
Gary Samuelson
------------------------------
Date: Tue, 19 Mar 85 16:04:45 est
From: mark@cbosgd.ATT.UUCP (Mark Horton)
Subject: three-character escapes
To: std-c@cbosgd.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.
How do you interpret "\SOH". Is it control A (ASCII SOH), or is it
control N followed by H (ASCII SO followed by H?) Many of the codes
are two letters long, and SO is a prefix of SOH.
>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.
I agree with this reasoning.
------------------------------
Date: 19 Mar 85 21:08:35 CST (Tue)
From: ihnp4!pesnta!lsuc!dave
Subject: three-character escapes
To: pesnta!ihnp4!cbosgd!std-c
If you introduce \ESC, \BEL etc., as mcvax!jack suggests,
then all of a sudden you have a counterintuitive difference
in parsing between
\BELHello (parsed like \007Hello)
and
\belHello (parsed as backspace followed by elHello)
That is, the case of a character after a backslash would become
important. Apart from the problems for machines which don't support
dual case (which can't completely follow the standard anyway),
this would cause severe headaches for programmers.
Dave Sherman
The Law Society of Upper Canada
ihnp4!utzoo!lsuc!dave or pesnta!lsuc!dave
------------------------------
Date: 19 Mar 85 23:47:33 CST (Tue)
From: ihnp4!utzoo!henry
Subject: three-character escapes
To: ihnp4!cbosgd!std-c
There is a problem of whose character set we base the set on; should
we include \SOS because it's in EBCDIC (according to my old yellow card),
even though it's not in ASCII or ISO? Note also that not all the funny
characters have three-letter names; some of the names are only two letters,
which will cause problems.
> 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.
Unfortunately, the result will probably be very different anyway;
identical names do not guarantee identical semantics. As various people
have mentioned, most such characters have machine-dependent effects even
if the definition of the character is relatively machine-independent. Just
because your EBCDIC compiler accepts \HT doesn't mean it will do what it
should on an EBCDIC terminal.
This is a better idea than most, actually, but I'm not sure it's
quite good enough.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: 19 Mar 85 23:47:41 CST (Tue)
From: ihnp4!utzoo!henry
Subject: Unique Member Names?
To: ihnp4!cbosgd!std-c
> 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;
> };
Draft of 11 Feb 1985, section C.1.2.3:
...each structure or union has a separate name space for
its members...
In other words, yes, it's legal.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
End of mod.std.c Digest - Wed, 20 Mar 85 14:41:28 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.