osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/07/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 6 May 85 Volume 6 : Issue 4
Today's Topics:
ANSI standard
Function pointers
L as numeric suffix
space around #
Unions in registers; returning structures in a register
----------------------------------------------------------------------
Date: Sat, 4 May 85 17:50 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: ANSI standard
To: cbosgd!std-c@BERKELEY
Would someone on the committee PLEASE tell the net how one can get a
copy of the standard? It's very difficult to carry out a discussion when
you don't know exactly what the standard says. (See, for instance, my
recent posting to Info-C on CTRL(X).)
Mark
^.-.^ Purtill at MIT-MULTICS.ARPA **Insert favorite disclaimer here**
((")) 2-032 MIT Cambrige MA 02139
[ I'm not in the committee, but this is some information I got from
the first issue of The C Journal (tm). To request copies of the
draft standard contact
Dr. Thomas Plum
Plum Hall Inc.
1 Spruce Ave.
Cardiff, NJ 08232
I haven't verified this with Dr. Plum, and I don't have an electronic
mail address for him either.
In the past, I have distributed copies, but my own workload doesn't
allow me to do this again. Also, Larry Rosler has distributed copies
on request, though I'm not sure he has been able to keep up with
the demand.
-- Mod -- ]
------------------------------
Date: Fri, 3 May 85 16:11:21 pdt
From: John Bruner <seismo!mordor!jdb>
Subject: Function pointers
To: std-c@cbosgd
[These comments and questions are based upon the 11/84 draft standard.]
Section C.3.3.4 (The sizeof operator) states
The sizeof operator yields the size, in bytes, of its operand.
It may be applied to any object except a bit-field member of a
structure, which is the only kind of object whose size might
not be an integral number of bytes.
I believe that this should be amended to exclude applying sizeof
to a function:
int (*foo)(), atoi();
sizeof atoi() /* legal, == sizeof int */
sizeof atoi /* illegal */
sizeof *foo /* illegal */
In the same vein, section C.3.6 (Additive operators) states:
When an expression that has integral type is added to or
subtracted from a pointer, the integral value is converted
to an address offset by multiplying it by the size of the
object pointed to.
Since the size of a function object is not defined, I believe this
should be amended to disallow expressions which combine integers and
pointers to functions:
foo + 1 /* illegal */
As a more general question, is any particular significance attached
to the value of a function pointer? In a simple machine like a
VAX all that is needed to call a function is the address of the
called routine. However, in a segmented system with dynamic linking
more than one word of information may be required. The only ways I
can see to handle this are to make pointers to functions multiple
words long or not require that the variable itself hold the
address of the code for the called function, but instead point
to a block of memory which contains the necessary information.
Now, if a pointer-to-function can be several words long, it will
probably not be possible to cast it to an integer of any size
and back again without loss of information. Also, in order for
casts to and from (void *) to avoid losing information (C.2.2.3),
(void *) pointers would be required to be several words long and
casts to/from simpler data types (e.g. (char *)) would be
unnecessarily inefficient.)
On the other hand, two levels of indirection could be used. The
function pointer would contain the address of the appropriate
linkage segment entry. A pointer to a function would then have the
same size as other pointers. Casting this pointer to (void *),
an appropriate integer type, or a pointer to a function with a
different result type would be straightforward. Since "sizeof"
isn't defined for pointers to functions and they cannot be used
in additive expressions, the only case that I can think of where
the result might be other than expected is:
printf("foo = %lo\n", (long)foo);
since this would print the address of the link rather than the
address of the function. This behavior seems to me to be consistent
with the addressing structure on a segmented machine (C.3.4),
and therefore an allowable implementation.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758
UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
------------------------------
Date: 3-May-1985 14:58-EDT (Friday)
From: masscomp!trb
Subject: L as numeric suffix
To: cbosgd!std-c
It has always annoyed me that lowercase l is allowed as a suffix in C
to denote a long int constant. I think that only uppercase L should be
allowed, because lowercase l looks like a number 1 on many output
devices. I never want to see code like this again:
var = 2l; /* use: var = 2L; */
Andy Tannenbaum Masscomp Westford, MA (617) 692-6200 x274
[ As background, from Section C.1.3.1 (Floating Constants):
"An unsuffixed floating constant has type double. If suffixed
by the letter f or F, it has type float. If suffixed by the
letter l or L, it has type long double."
Draft 85-008, p. 6, C.1.3.1.
-- Mod -- ]
------------------------------
Date: Sat, 4 May 85 00:22:50 edt
From: hcr!lsuc!msb
Subject: space around #
To: hcr!cbosgd!std-c
> > Actually, in the current drafts, there can even be white space preceding
> > the #.
>
> From Section C.8, p. 46, draft 85-008
>
> "...[preprocessing capabilities] are controlled
> by directives that are "lines" in the source file that "begin with"
> a # separator character; more precisely, by a # token that is the
> first character in the source file (after any number of space and
> horizantal-tab characters) or that follows a new-line character
> (after any number of space and horizontal-tab characters)."
>
> Note that it is not white space that can go
> before the # token, only space characters and horizontal-tabs. (White
> space consists of space characters, horizontal tabs, new-lines,
> vertical tabs, form feeds, and comments. See Section C.1-Semantics.)
Seems to me that if that is going to be the rule then form feeds (and, I
suppose, vertical tabs) certainly ought to be legal too. To me, at least,
a form feed is just a super newline and does start a new line (though I see
the C compiler on my machine feels differently).
However, I do wonder whether this extension is another case of "case x..y:";
something that may be a good idea but shouldn't be added at this late date.
At least, not unless the majority of compilers already support it. Do they?
Mark Brader
------------------------------
Date: Fri, 3 May 85 11:36:09 pdt
From: nsc!turtlevax!ken@ihnp4.uucp (Ken Turkowski)
Subject: Unions in registers; returning structures in a register
The C compiler seems to not allow unions in registers, even if the
elements of the union (like char*, short*, int*, double*) all fit.
Similarly it doesn't allow structures to be returned in registers,
e.g., on a 32-bit machine:
struct { short x, y; } joe() {}
The C compiler allocates storage, and returns a pointer to it,
rather than packing them both into r0.
Is it prohibitively complicated to allow these in the compiler?
Or is there a philosophical reason not to do this? Or just pure
laziness?
--
Ken Turkowski @ CADLINC, Menlo Park, CA
UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken
ARPA: turtlevax!ken@DECWRL.ARPA
------------------------------
End of mod.std.c Digest - Mon, 6 May 85 21:16:38 EDT
******************************
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.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road
/Middletown, New Jersey, 07748 (HR 1B 316)
Tel: 201-949-9230 /UUCP: {{{ucbvax,decvax}!}{ihnp4,harpo}!}hou2d!osd