osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (05/29/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 22 May 85 Volume 6 : Issue 11
Today's Topics:
concatenation
Pointer math and ints (2 msgs)
signed and unsigned char, same size?
----------------------------------------------------------------------
Date: Tue, 21 May 85 11:27:53 edt
From: decvax!duke!george@idis
Subject: concatenation
To: duke!decvax!ihnp4!sfbc!lr@mcnc
Below is the definition of string literals
from section C.1.4 of X3J11 draft 85-008.
string-literal:
unit-string-literal
string-literal unit-string-literal
The below definition might be more useful.
string-literal:
unit-string-literal
string-literal unit-string-literal
string-literal character-constant
George Rosenberg
duke!mcnc!idis!george
------------------------------
Date: 19 May 85 16:26:34 CDT (Sun)
From: plus5!hokey (Hokey)
Subject: Pointer math and ints
>From C.3.6 Additive Operators (semantics), p. 21, draft 85-008:
> "When two pointers to members of the same array object are subtracted,
> the result is converted (by division by the size of the member) to
> a signed integer (the size of which is implementation defined)
> representing the difference of the subscripts of the two array
> members.
>
>K&R (p 189, last paragraph of 7.4) states "If two pointers to objects of
>the same type are subtracted, the result is converted (by division by
>the length of the object) to an _int_ representing the number of objects
>separating the pointed-to objects."
>
>Changing the result from "an _int_" to "a signed integer (the size of
>which is implementation defined)" breaks existing code.
>
>[ Someone can prove the above statement? -- Mod -- ]
I proved it in a later statement on the same article, paraphrased again:
An example of this problem (pointer==long, int==short) occurs when
one passes the (previously guaranteed to be an int) "p-s" as an actual
parameter to a subroutine, which is expecting an int. Under the proposed
definition, the "p-s" expression pushes a long on the stack, but the
subroutine expects a short.
[ See more on K&R on article below. -- Mod -- ]
Jack Jansen: I *never said* pointers had to fit into an int. I am not
saying it now. I *am* saying that if the result of (valid) pointer
subtraction is of arbitrary integral size instead of int, existing code
will break and it will be *hard* to find these problems.
Most current Macintosh C compilers have 4 byte pointers and longs, and
2 byte shorts and ints. Every one of these compilers puts the result
of (valid) pointer subtraction into a *long* instead of an *int*.
This means that when I try and pass the (int) length of a string to a
subroutine via pointer subtraction, 4 bytes are generated instead of 2.
Are there still people who don't see the problem?
------------------------------
Date: Tue, 21 May 85 13:07:30 edt
From: ima!haddock!ism780!ico!spence
Subject: Pointer math and ints
To: ima!cbosgd!std-c
On the subject of pointer subtraction, K&R is misleading.
((&a[1] - &a[0]) / sizeof( a[0] )) would compute one object "separating
the pointed-to objects" when in fact the two objects are adjacent.
It also has the problem of potentially indicating a negative number of
intervening objects. The proposed definition provides more information
and is more precise.
Spencer Rugaber (ima!spence)
------------------------------
Date: Tue, 21 May 85 13:07:30 edt
From: ima!haddock!ism780!ico!spence
Subject: signed and unsigned char, same size?
To: ima!cbosgd!std-c
I was asked by a friend the other day whether it was safe to store an
unsigned char into a char. The general problem is whether signed and
unsigned objects (of the same variety char/short/int/long) are guaranteed
to be the same size. I could find no discussion of the question in K&R
and can recall none from the proposed standard. It seems like a
question that the standard could reasonable speak to.
Spencer Rugaber (ima!spence)
[ Hope this helps.
"For signed char and each type of int, there is a corresponding
unsigned type (declared with the keyword unsigned) that
occupies the same amount of storage."
Section C.1.2.5 Types, p. 16, Draft 85-045 (4/30/85) --
-- Mod -- ]
------------------------------
End of mod.std.c Digest - Wed, 22 May 85 21:25:42 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.