osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (01/13/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 13 Jan 86 Volume 13 : Issue 1
Today's Topics:
mod.std.c Digest V12#1 (type of '%')
proposals to ANSI C
Subtraction of (void *)
----------------------------------------------------------------------
Date: Sat, 9 Nov 85 20:22:31 est
From: Arnold Robbins <gatech!arnold>
Subject: mod.std.c Digest V12#1 (type of '%')
To:
>Date: Tue, 29 Oct 85 09:45:39 est
>From: packard!topaz!harvard!wjh12!teddy!panda!jpn (John P. Nelson)
>Subject: Suggested ANSI C changes for international character set support
>To: std-c@cbosgd
>
>>expressions: how do you make "short" character strings instead of
>>"char" character strings, or indicate that '%' means a short '%' rather
>>than a char '%'? (replace % with your favorite Chinese glyph.)
>
>The constant '%' is ALREADY of type INT not type CHAR!!
The constant '%' is of type char, as is the constant '\377'; it will
get promoted to int on assignment to or comparison with, an int, otherwise
it stays a char. This kind of thing can bite you if you're not careful
on machines that do sign extension. The problem is that char's are also
very small ints, since you can do math on them.
This is particularly important, since the draft now says that if promotion
to a larger type isn't necessary, it doesn't have to be done. This was added
mainly to ease float <=> double situations, but should apply as well to
chars vs. ints. Admittedly, the char/int boundary is not clearly marked.
The ANSI standard should help.
--
Arnold Robbins
CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa
UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold
Hello. You have reached the Coalition to Eliminate Answering Machines.
Unfortunately, no one can come to the phone right now....
------------------------------
Date: Tue, 7 Jan 86 16:34 CST
From: David Tribble <tribble_acn%uta.csnet@CSNET-RELAY.ARPA>
Subject: proposals to ANSI C
To: cbosgd!std-c
This is not necessarily to be considered an article, but just some
input to the ANSI C discussion.
----- part the first ------
I propose that standard #pragma's be defined. These would be portable,
meaning that any program using them would compile, though compilers may
choose to ignore their effect (but still recognize them, ie, do not issue
error messages). Some useful ones would be:
#pragma message <token> {<token>}
/* print #defined names, strings, etc, to listing output */
#pragma float
#pragma double
/* force precision of following arithmetic statement */
#pragma interrupt [<type>]
/* following function will be used as interrupt handler */
#pragma [no] optimize
#pragma [no] optimize time
#pragma [no] optimize space
/* [don't] enable optimizations */
#pragma [no] debug
/* [don't] generate debugging code */
#pragma foreign [<type>]
/* following function uses foreign (eg, FORTRAN) calling */
ps. It is strictly my opinion, but 'pragma' is one hellish word to
type; back in 1982 before I'd even heard of ANSI C, I decided to try my
hand at writing an 8080 C compiler, and I though up a '#option' directive,
which was identical to the ANSI '#pragma'. I also feel that C should not
borrow from Ada.
----- part the second ------
I propose that '\l' (backslash ell) be considered the character 'line feed'.
This would complete the 'useful' available control character set. It would
also agree with ASCII and EBCDIC usage (I'm not sure about others, though).
The argument that this escape character is not needed because everyone
uses '\n' is a bad one because K&R explicitly state that a 'newline' character
is implementation-defined (even though it is usually implemented as ASCII
octal 012). This would bring the list up to-
char name ASCII EBCDIC
---- ---- ----- ------
'\a' alarm 007 2F
'\b' back space 010 16
'\t' tab 011 05
'\l' line feed 012 25
'\v' vertical tab 013 0B
'\f' form feed 014 0C
'\r' return 015 0D
'\n' newline <implementation-specific>
It might also be wise to actually define what all these characters, except
newline, actually are for ASCII, EBCDIC, and possibly others.
----- part the third -----
I propose that all the printf and scanf '%' conversion specifications be
made available as individual functions. This would remove the requirement
that printf and scanf (and their associated functions) need be interpretive
(ie, evaluated at execution time). For example, the printf call:
printf("%3d %24.18e %20s\n", i, d, "and many more");
could be called as separate functions:
printd(i, 3);
putchar(' ');
printe(d, 24, 18);
putchar(' ');
prints("and many more", 20);
putchar('\n');
This also alleviates the need to drag in unused runtime code, such as floating
point to character conversions, when they aren't needed.
Obvious function names are:
printd for %d
printl for %ld
prints for %s (or puts?)
printe for %e
printf for %f
etc.
----- part the fourth -----
I propose that pre-#defined names (such as _INTSZ, _DOUBLESZ, etc.) exist
which define the sizes of the basic types (in bytes or 'words'). Also the
names '_BYTESZ and '_CHARSZ' would indicate the number of bits in a byte
and a character, respectively:
#define _BYTESZ 8
#define _CHARSZ 7
#define _INTSZ 2
#define _SHORTSZ 2
#define _LONGSZ 4
#define _FLOATSZ 4
#define _DOUBLESZ 8
#define _POINTERSZ 4
etc.
An alternative proposal would be to allow the use of
#if ... sizeof ( <type> ) ...
preprocessor expression terms which evaluate to int values. <type> may be
one of:
char unsigned
int double
short float
long pointer
It would also be extremely useful to pre-#define names that describe the
compiler and operating system environment:
#define _OPSYS VMS_4
#define _CPU VAX11
or, alterately:
#define _VMS_4 1
#define _VAX11 1
Of course, compiler writers would have to be careful to choose non-conflicting
identifiers (this fact makes this a bad suggestion).
David R. Tribble Univ. Texas at Arlington
<tribble_acn@uta> via CSNET
------------------------------
Date: Fri, 10 Jan 86 16:29:13 pst
From: jon@cit-vax.ARPA (Jonathan P. Leech)
Subject: Subtraction of (void *)
To: cbosgd!std-c
What is the result of subtracting two pointers to void? It
does not seem to be explicitly disallowed (according to the April 30
draft) but it's not clear what the result will be, either. By analogy
with void pointers, I was thinking that this might be a portable way
to represent offsets in structures to different member types, i.e.
struct foo {
int i;
double d;
} bar;
((void *)&foo.d) - ((void *)&foo)
/* offset of member d in foo (in what units?) */
Would anyone more familiar with the issues involved care to comment?
Please keep the flames mild if I missed something making this
illegal.
-- Jon Leech (jon@cit-vax.arpa)
__@/
------------------------------
End of mod.std.c Digest - Mon, 13 Jan 86 08:29:30 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.