On Dec 5, 2005, at 3:25 PM, Joseph S. Myers wrote:
OBringing bit-fields into the matter is just confusing things since
you
can't have pointers to bit-fields, but anyway char is not in a
comma-separated set with signed char or unsigned char and for
DR#315 it
was proposed to say that whether ch
On Mon, 5 Dec 2005, Mike Stump wrote:
> On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
> > Oh right, what I really meant was 'char' instead of 'long'.
> > In fact I just took the type from the referenced article. Sorry for that.
> >
> > So am I right that the compiler should distinguish bet
On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for
that.
So am I right that the compiler should distinguish between char,
signed char
and unsigned char in the p
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for that.
So am I right that the compiler should distinguish between char, signed char
and unsigned char in the proposed way?
>
> "long" and "signed long" are the same typ
On Mon, Dec 05, 2005 at 03:27:56PM +0100, [EMAIL PROTECTED] wrote:
> Shouldn't the compiler behave in the following way, concerning the signedness
> of pointer arguments?
>
> void f (long *l, signed long *sl, unsigned long *ul);
"long" and "signed long" are the same type. You are confused abou
Shouldn't the compiler behave in the following way, concerning the signedness
of pointer arguments?
void f (long *l, signed long *sl, unsigned long *ul);
// - Make NO assumptions about the signedness of *l and accept long,
//slong and ulong without a warning
// - treat *sl as signed l
