A byte can be greater than 8 bits?

[borophyll]

As I read it, C99 states that a byte is an:

"addressable unit of data storage large enough to hold any member of
the basic character
set of the execution environment" (3.6)

and that a byte must be at least 8 bits:

"The values given below shall be replaced by constant expressions
suitable for use in #if
preprocessing directives. Moreover, except for CHAR_BIT and
MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as
would an
expression that is an object of the corresponding type converted
according to the integer
promotions. Their implementation-defined values shall be equal or
greater in magnitude
(absolute value) to those shown, with the same sign."

number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8 (5.2.4.2.1)

Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)? I have gotten the impression that a byte, or unsigned char, was
always 8 bits, but perhaps I was wrong. If I am not, is there
somewhere in the standard that defines a byte as always being 8 bits?

Regards,
B.

[Roberto Waltman]

bo*******@gmail.com wrote:

>As I read it, C99 states that a byte is an:
"addressable unit of data storage large enough to hold any member of
the basic character set of the execution environment" (3.6)

and that a byte must be at least 8 bits:
...
Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)? I have gotten the impression that a byte, or unsigned char, was
always 8 bits, but perhaps I was wrong.

Correct - For example, Texas Instruments C compiler for the DSP 2000
processor family defines CHAR_BIT == 16, and sizeof(char) ==
sizeof(short) == sizeof(int) == 1
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[Richard]

I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

Martin Wells <wa****@eircom.netwrites:

>Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)?

Yes, a byte can have more than eight bits. Welcome to the world of
portable C programming :D Here's a few other things to look out for in
portable programming:

A) Systems where a byte is more than 8 bits :

>
1: Null pointers aren't necessarily represented as all-bits-zero, so
think twice about using memset(array_of_pointers,0,sizeof
array_of_pointers).

B) Systems where a NULL pointer can not be set by applying 0s.

>
2: Integer types other than unsigned char may contain padding bits, so
stay away from memcmp(arr1,arr2,sizeof arr1).

C) Places where the padding bits are not concistently set between 2
arrays of the same types.

>
3: Number systems other than two's complement may be used, so be
careful about doing things like using -1 to represent all-bits-one.

D) Where -1 is not an all bits on.

>
4: Function pointers might not fit inside ANY of the other types (e.g.
such as void* or unsigned long), so don't do that.

E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

[Philip Potter]

Richard wrote:

I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

I partly agree and partly disagree here. I agree because it shows to new
people that strictly following the standard /is/ important because these
common assumptions aren't necessarily true. But I disagree because it
may encourage the view that if a system cannot be found which differs
from the norm, then it doesn't matter that we're making assumptions.

Martin Wells <wa****@eircom.netwrites:

>>Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)?

Yes, a byte can have more than eight bits. Welcome to the world of
portable C programming :D Here's a few other things to look out for in
portable programming:

A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

>1: Null pointers aren't necessarily represented as all-bits-zero, so
think twice about using memset(array_of_pointers,0,sizeof
array_of_pointers).

B) Systems where a NULL pointer can not be set by applying 0s.

What do you mean by "applying 0s"? Null pointers can always be set by:
foo *x = (foo *)0;
(I'm not sure if the cast is necessary) even if the null pointer
representation is not all-bits-zero.

I personally don't know of any non-all-bits-zero null pointer systems,
but I've never seen reason to worry about it. I know /my/ code will work
everywhere regardless. As Kernighan and Ritchie wisely point out, ``if
you don't know how they are done on various machines, that innocence may
help to protect you.''

>2: Integer types other than unsigned char may contain padding bits, so
stay away from memcmp(arr1,arr2,sizeof arr1).

C) Places where the padding bits are not concistently set between 2
arrays of the same types.

That is user-program dependent. Any system with padding bits can have
them set by the user program:
int main(void) {
unsigned int arr1[2], arr2[2];
arr1[0] = arr1[1] = (unsigned int) -1;
memset(arr2,2*sizeof(unsigned int),1,(unsigned char)-1);
/* At this point, arr1's values equal arr2's values but
the padding bits may differ. */
}

>3: Number systems other than two's complement may be used, so be
careful about doing things like using -1 to represent all-bits-one.

D) Where -1 is not an all bits on.

This is compicated again. For unsigned types, -1 is always all-bits-one.
I can't think why you'd want to set a signed type to all-bits-one.

>4: Function pointers might not fit inside ANY of the other types (e.g.
such as void* or unsigned long), so don't do that.

E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

I can't think why you'd want to do this.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:

>I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

I partly agree and partly disagree here. I agree because it shows to
new people that strictly following the standard /is/ important because
these common assumptions aren't necessarily true. But I disagree
because it may encourage the view that if a system cannot be found
which differs from the norm, then it doesn't matter that we're making
assumptions.

No. I think it's important to show that these systems really
exist. Otherwise a lot of people will think it's all a lot of hot
air. It does no harm to demonstrate WHERE the standard benefits the
programmer. Not some airy fairy "there might be a system with a 13 bit
char" for example.

>

>Martin Wells <wa****@eircom.netwrites:

>>>Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)?

Yes, a byte can have more than eight bits. Welcome to the world of
portable C programming :D Here's a few other things to look out for in
portable programming:

A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

>>1: Null pointers aren't necessarily represented as all-bits-zero, so
think twice about using memset(array_of_pointers,0,sizeof
array_of_pointers).

B) Systems where a NULL pointer can not be set by applying 0s.

What do you mean by "applying 0s"? Null pointers can always be set by:
foo *x = (foo *)0;

See above where it clearly says using memset.

(I'm not sure if the cast is necessary) even if the null pointer
representation is not all-bits-zero.

I personally don't know of any non-all-bits-zero null pointer systems,
but I've never seen reason to worry about it. I know /my/ code will
work everywhere regardless. As Kernighan and Ritchie wisely point out,
if you don't know how they are done on various machines, that
innocence may help to protect you.''

Yes, but this has nothing to do with the question. The question being
posed is to demonstrate where this might be an issue if you do NOT stick
to the rules.

>

>>2: Integer types other than unsigned char may contain padding bits, so
stay away from memcmp(arr1,arr2,sizeof arr1).

C) Places where the padding bits are not concistently set between 2
arrays of the same types.

That is user-program dependent. Any system with padding bits can have
them set by the user program:
int main(void) {
unsigned int arr1[2], arr2[2];
arr1[0] = arr1[1] = (unsigned int) -1;
memset(arr2,2*sizeof(unsigned int),1,(unsigned char)-1);
/* At this point, arr1's values equal arr2's values but
the padding bits may differ. */
}

This is a forced issue and nothing to do with the question about
compiler or platform specifics. We are talking two arrays of the same
objects begin compared without using memset. In the real word - not the
hypothetical world.

>

>>3: Number systems other than two's complement may be used, so be
careful about doing things like using -1 to represent all-bits-one.

D) Where -1 is not an all bits on.

This is compicated again. For unsigned types, -1 is always
all-bits-one. I can't think why you'd want to set a signed type to
all-bits-one.

This is not the question. The question is what real platforms does -1
not get represented by an all bits on. This comes up all the time.

>

>>4: Function pointers might not fit inside ANY of the other types (e.g.
such as void* or unsigned long), so don't do that.

E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

I can't think why you'd want to do this.

This is not the question. The question is where it would not work.

[Philip Potter]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>Richard wrote:

>>I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

I partly agree and partly disagree here. I agree because it shows to
new people that strictly following the standard /is/ important because
these common assumptions aren't necessarily true. But I disagree
because it may encourage the view that if a system cannot be found
which differs from the norm, then it doesn't matter that we're making
assumptions.

No. I think it's important to show that these systems really
exist. Otherwise a lot of people will think it's all a lot of hot
air. It does no harm to demonstrate WHERE the standard benefits the
programmer. Not some airy fairy "there might be a system with a 13 bit
char" for example.

But again, if you don't know how things are done on systems, you will be
protected from it. I know that NULL is not guaranteed to be
all-bits-zero, and I don't know where it is and where it isn't. I'm not
even sure whether or not NULL is all-bits-zero on x86, and I'm happy to
stay that way.

It's good to have a couple of examples of why certain common assumptions
shouldn't be relied on, but compiling a comprehensive list is asking for
people to rely on that list instead.

>>Martin Wells <wa****@eircom.netwrites:

Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)?
Yes, a byte can have more than eight bits. Welcome to the world of
portable C programming :D Here's a few other things to look out for in
portable programming:
A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

>>>1: Null pointers aren't necessarily represented as all-bits-zero, so
think twice about using memset(array_of_pointers,0,sizeof
array_of_pointers).
B) Systems where a NULL pointer can not be set by applying 0s.

What do you mean by "applying 0s"? Null pointers can always be set by:
foo *x = (foo *)0;

See above where it clearly says using memset.

>(I'm not sure if the cast is necessary) even if the null pointer
representation is not all-bits-zero.

I personally don't know of any non-all-bits-zero null pointer systems,
but I've never seen reason to worry about it. I know /my/ code will
work everywhere regardless. As Kernighan and Ritchie wisely point out,
if you don't know how they are done on various machines, that
innocence may help to protect you.''

Yes, but this has nothing to do with the question. The question being
posed is to demonstrate where this might be an issue if you do NOT stick
to the rules.

This is why writing standard C is the /easy/ way: because you don't need
to compile such compatibility lists.

>>>2: Integer types other than unsigned char may contain padding bits, so
stay away from memcmp(arr1,arr2,sizeof arr1).
C) Places where the padding bits are not concistently set between 2
arrays of the same types.

That is user-program dependent. Any system with padding bits can have
them set by the user program:
int main(void) {
unsigned int arr1[2], arr2[2];
arr1[0] = arr1[1] = (unsigned int) -1;
memset(arr2,2*sizeof(unsigned int),1,(unsigned char)-1);
/* At this point, arr1's values equal arr2's values but
the padding bits may differ. */
}

This is a forced issue and nothing to do with the question about
compiler or platform specifics. We are talking two arrays of the same
objects begin compared without using memset. In the real word - not the
hypothetical world.

Why does your requirement exclude use of memset? Someone who uses
memcmp() will also use memset(). Someone who uses memset() may not do so
for every array he uses.

>>>3: Number systems other than two's complement may be used, so be
careful about doing things like using -1 to represent all-bits-one.
D) Where -1 is not an all bits on.

This is compicated again. For unsigned types, -1 is always
all-bits-one. I can't think why you'd want to set a signed type to
all-bits-one.

This is not the question. The question is what real platforms does -1
not get represented by an all bits on. This comes up all the time.

Give me an example of code which relies on -1 being all-bits-one.

>>>4: Function pointers might not fit inside ANY of the other types (e.g.
such as void* or unsigned long), so don't do that.
E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

I can't think why you'd want to do this.

This is not the question. The question is where it would not work.

Why is that question relevant if noone tries to do it? I don't see you
asking for a list of platforms where NULL is 0xdeadbeef, because no code
depends on that.

--
Philip Potter pgp <atdoc.ic.ac.uk

[jacob navia]

Philip Potter wrote:

>
Give me an example of code which relies on -1 being all-bits-one.

#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

int main(void)
{
unsigned i;
unsigned u = (unsigned)-1;

for (i=0; i<32;i++)
printf("Masking lower %d bits of %x is: %x\n",
i,u,maskNLowerBits(u,i));
}

Output:
Masking lower 0 bits of ffffffff is: ffffffff
Masking lower 1 bits of ffffffff is: fffffffe
Masking lower 2 bits of ffffffff is: fffffffc
Masking lower 3 bits of ffffffff is: fffffff8
Masking lower 4 bits of ffffffff is: fffffff0
Masking lower 5 bits of ffffffff is: ffffffe0
Masking lower 6 bits of ffffffff is: ffffffc0
Masking lower 7 bits of ffffffff is: ffffff80
Masking lower 8 bits of ffffffff is: ffffff00
Masking lower 9 bits of ffffffff is: fffffe00
Masking lower 10 bits of ffffffff is: fffffc00
Masking lower 11 bits of ffffffff is: fffff800
Masking lower 12 bits of ffffffff is: fffff000
Masking lower 13 bits of ffffffff is: ffffe000
Masking lower 14 bits of ffffffff is: ffffc000
Masking lower 15 bits of ffffffff is: ffff8000
Masking lower 16 bits of ffffffff is: ffff0000
Masking lower 17 bits of ffffffff is: fffe0000
Masking lower 18 bits of ffffffff is: fffc0000
Masking lower 19 bits of ffffffff is: fff80000
Masking lower 20 bits of ffffffff is: fff00000
Masking lower 21 bits of ffffffff is: ffe00000
Masking lower 22 bits of ffffffff is: ffc00000
Masking lower 23 bits of ffffffff is: ff800000
Masking lower 24 bits of ffffffff is: ff000000
Masking lower 25 bits of ffffffff is: fe000000
Masking lower 26 bits of ffffffff is: fc000000
Masking lower 27 bits of ffffffff is: f8000000
Masking lower 28 bits of ffffffff is: f0000000
Masking lower 29 bits of ffffffff is: e0000000
Masking lower 30 bits of ffffffff is: c0000000
Masking lower 31 bits of ffffffff is: 80000000

OK?

And you haven't given ANY example as Richard asked!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

jacob navia wrote:

Philip Potter wrote:

>>
Give me an example of code which relies on -1 being all-bits-one.

#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[jacob navia]

Eric Sosman wrote:

jacob navia wrote:

>Philip Potter wrote:

>>>
Give me an example of code which relies on -1 being all-bits-one.

#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

jacob navia wrote:

Eric Sosman wrote:

>jacob navia wrote:

>>Philip Potter wrote:

Give me an example of code which relies on -1 being all-bits-one.
#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

Yes: unary minus takes an "arithmetic type" (6.5.3.3).

--
Eric Sosman
es*****@ieee-dot-org.invalid

[jacob navia]

Eric Sosman wrote:

jacob navia wrote:

>Eric Sosman wrote:

>>jacob navia wrote:
Philip Potter wrote:
>
Give me an example of code which relies on -1 being all-bits-one.
>

#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

Yes: unary minus takes an "arithmetic type" (6.5.3.3).

Anyway, that relies still in that all bits not dropping
of the left side are all 1. And that did not change with this minor
cosmetic change!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Philip Potter wrote:

[snip]

The fact that Philippe could not bring a single example
means probably that there isn't any machines where
all those terrible conditions apply!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:

>Philip Potter <pg*@see.sig.invalidwrites:

>>Richard wrote:
I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:
I partly agree and partly disagree here. I agree because it shows to
new people that strictly following the standard /is/ important because
these common assumptions aren't necessarily true. But I disagree
because it may encourage the view that if a system cannot be found
which differs from the norm, then it doesn't matter that we're making
assumptions.

No. I think it's important to show that these systems really
exist. Otherwise a lot of people will think it's all a lot of hot
air. It does no harm to demonstrate WHERE the standard benefits the
programmer. Not some airy fairy "there might be a system with a 13 bit
char" for example.

But again, if you don't know how things are done on systems, you will
be protected from it. I know that NULL is not guaranteed to be
all-bits-zero, and I don't know where it is and where it isn't. I'm
not even sure whether or not NULL is all-bits-zero on x86, and I'm
happy to stay that way.

It's good to have a couple of examples of why certain common
assumptions shouldn't be relied on, but compiling a comprehensive list
is asking for people to rely on that list instead.

No. It is there to make the point that it really is true. I never asked
for a comprehensive list. Just some examples.

"Look, if you do it the proper way wou wont get in a jam like you would
if you did it that way and your code moves to platform X".

[Ben Bacarisse]

jacob navia <ja***@nospam.orgwrites:

Eric Sosman wrote:

>jacob navia wrote:

>>Philip Potter wrote:

Give me an example of code which relies on -1 being all-bits-one.
#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int', the '-' negates this. The result (mathematical
-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

--
Ben.

[jacob navia]

Ben Bacarisse wrote:

jacob navia <ja***@nospam.orgwrites:

>Eric Sosman wrote:

>>jacob navia wrote:
Philip Potter wrote:
Give me an example of code which relies on -1 being all-bits-one.
>
#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}
Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int', the '-' negates this. The result (mathematical
-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

Anyway...

AND the rest of the code supposes that this is all ones.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Charlie Gordon]

"jacob navia" <ja***@nospam.orga écrit dans le message de news:
47***********************@news.orange.fr...

Philip Potter wrote:

>>
Give me an example of code which relies on -1 being all-bits-one.

#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}

Jacob, you know this invokes undefined behaviour.

You should have written ``-1U << n'' and that would be portable across all
representations.

Personally, I would prefer if Standard C mandated 2s-complement and defined
the behaviour of shifting signed integer types left and right. Maybe we
should define a new language, Real-C where these awkward historical detail
would be removed...

int main(void)
{
unsigned i;
unsigned u = (unsigned)-1;

Cast is useless.
If the compiler complains, use ``-1U''.

for (i=0; i<32;i++)
printf("Masking lower %d bits of %x is: %x\n",
i,u,maskNLowerBits(u,i));
}

Output:
Masking lower 0 bits of ffffffff is: ffffffff
Masking lower 1 bits of ffffffff is: fffffffe

....

Masking lower 30 bits of ffffffff is: c0000000
Masking lower 31 bits of ffffffff is: 80000000

OK?

Mostly irrelevant.

And you haven't given ANY example as Richard asked!

I get the same answers: some DSPs do, once a friend told me of a computer
that did weird stuff...

Some DSPs do have non 8 bit bytes, and some old Crays too.
Using those for anything non specific is bound to cause surprises!

For the rest (non twos-complement, padding bytes in integers...) we can
safely ignore the issues.

--
Chqrlie.

[Ben Bacarisse]

jacob navia <ja***@nospam.orgwrites:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.orgwrites:

>>Eric Sosman wrote:
jacob navia wrote:
Philip Potter wrote:
>Give me an example of code which relies on -1 being all-bits-one.
>>
#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}
Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int', the '-' negates this. The result (mathematical
-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

Anyway...

AND the rest of the code supposes that this is all ones.

It is guaranteed to be all ones in the value bits -- which is just
about as much as one can hope for. On an implementation with padding
bits in unsigned types of size 1, one could do tricks involving
arrays of unsigned char to get at padding bits, but "masking for bits"
usually means masking for "value bits".

What problem are you seeing? Have I missed something here? Eric's
remark simply means that -1u does not depend on -1 being all-bits-one.

--
Ben.

[Philip Potter]

jacob navia wrote:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.orgwrites:

>>Eric Sosman wrote:
jacob navia wrote:
Philip Potter wrote:
>Give me an example of code which relies on -1 being all-bits-one.
>>
#include <stdio.h>
int maskNLowerBits(unsigned d,int n)
{
return d & (-1 << n);
}
Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.

??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int', the '-' negates this. The result (mathematical
-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

Anyway...

AND the rest of the code supposes that this is all ones.

...which is not necessarily the case because of padding bits. But relying
on -1u being all ones is not the same as relying on -1 being all ones.
--
Philip Potter pgp <atdoc.ic.ac.uk

[Philip Potter]

jacob navia wrote:

Philip Potter wrote:

[snip]

The fact that Philippe could not bring a single example
means probably that there isn't any machines where
all those terrible conditions apply!

I'm flattered that you think so! But my knowledge of particular quirks
of different C implementations is much more restricted than you think. I
have only coded for three implementations: windows, linux, and
microblaze. I don't know the ins-and-outs of these implementations, for
reasons I've already given.

I'm quite certain that others, if they wanted, could provide details of
some implementations with some of the requested features.

Besides, I did provide a single example:

A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Philip Potter]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>It's good to have a couple of examples of why certain common
assumptions shouldn't be relied on, but compiling a comprehensive list
is asking for people to rely on that list instead.

No. It is there to make the point that it really is true. I never asked
for a comprehensive list. Just some examples.

"Look, if you do it the proper way wou wont get in a jam like you would
if you did it that way and your code moves to platform X".

In that case, I agree with the principles of your idea. But I can't
provide any examples because I'm quite ignorant of quirks of various C
implementations.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

jacob navia wrote:

>Philip Potter wrote:

[snip]

The fact that Philippe could not bring a single example
means probably that there isn't any machines where
all those terrible conditions apply!

I'm flattered that you think so! But my knowledge of particular quirks
of different C implementations is much more restricted than you
think. I have only coded for three implementations: windows, linux,
and microblaze. I don't know the ins-and-outs of these
implementations, for reasons I've already given.

I'm quite certain that others, if they wanted, could provide details
of some implementations with some of the requested features.

Besides, I did provide a single example:

>A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

No, you didn't. You mentioned a range of HW where it may or may not be
true :)

[Eric Sosman]

jacob navia wrote On 10/01/07 09:42,:

Eric Sosman wrote:

>>jacob navia wrote:

>>>Eric Sosman wrote:

jacob navia wrote:

>Philip Potter wrote:
>
>>Give me an example of code which relies on -1 being all-bits-one.
>>
>
>#include <stdio.h>
>int maskNLowerBits(unsigned d,int n)
>{
return d & (-1 << n);
>}

Maybe Philip should have specified "code that doesn't
invoke undefined behavior." After the fix s/1/1u/ the
corrected code no longer relies on -1 being all-bits-one.
??
Is it legal to make -1u??
Unary minus applied to unsigned operand?

Yes: unary minus takes an "arithmetic type" (6.5.3.3).

Anyway, that relies still in that all bits not dropping
of the left side are all 1. And that did not change with this minor
cosmetic change!

6.5.7p4 defines the value of the result of `-1u << n'
once UINT_MAX and n are known (and if n is in range).
6.2.6.2p4 specifies that this value is represented by n
bits zero and the rest one. That is, the fixed code relies
on the guarantees of the Standard and does not rely on the
representation of `-1'.

6.5.7p4 also says that `-1 << n' gives undefined behavior.

The difference between undefined and defined seems to me
more than "minor" or "cosmetic."

--
Er*********@sun.com

[Philip Potter]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>Besides, I did provide a single example:

>>>>A) Systems where a byte is more than 8 bits :
DSPs are a common example here.

No, you didn't. You mentioned a range of HW where it may or may not be
true :)

Well you wanted the examples, you go find them! :P

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:

>Philip Potter <pg*@see.sig.invalidwrites:

>>Besides, I did provide a single example:

>A) Systems where a byte is more than 8 bits :
DSPs are a common example here.

No, you didn't. You mentioned a range of HW where it may or may not be
true :)

Well you wanted the examples, you go find them! :P

Er, I was. Here. From the people who keep telling us about them all.

[Richard Heathfield]

Philip Potter said:

<snip>

[...] Null pointers can always be set by:
foo *x = (foo *)0;
(I'm not sure if the cast is necessary)

(No, it isn't.)

even if the null pointer representation is not all-bits-zero.

Yes, even if it means the compiler doing some magic to make it all work.

I personally don't know of any non-all-bits-zero null pointer systems,

Several such machines are mentioned in the FAQ.

I can't think why you'd want to [store a function pointer in a void *].

It's not all that unusual a thing to want to do, actually, although in
practice there's always a way around it if you want it badly enough.

As for whether systems exist that lose information when copying a function
pointer value into a void *, the answer is yes, and I've got one right
here.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Philip Potter]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>Richard wrote:

>>Philip Potter <pg*@see.sig.invalidwrites:
Besides, I did provide a single example:

>>A) Systems where a byte is more than 8 bits :
DSPs are a common example here.
No, you didn't. You mentioned a range of HW where it may or may not be
true :)

Well you wanted the examples, you go find them! :P

Er, I was. Here. From the people who keep telling us about them all.

Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT != 8.

Meanwhile, I won't make these assumptions, and I won't have to rely on
the implementations I use to comply with these assumptions.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:

>Philip Potter <pg*@see.sig.invalidwrites:

>>Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:
Besides, I did provide a single example:
>
>>>A) Systems where a byte is more than 8 bits :
>DSPs are a common example here.
No, you didn't. You mentioned a range of HW where it may or may not be
true :)
Well you wanted the examples, you go find them! :P

Er, I was. Here. From the people who keep telling us about them all.

Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

As for putting some "effort" in - I am. I am asking *here* where there
are a plethora of people who know a lot about such systems. I am hoping
they will give some examples of where a byte is more than 8 bits or
CHAR_BITS is more than 8. And it is a benevolent quest. I want to see
these systems and look at their specs too. It would be really good to
reference them whenever telling people their code is not standards
compliant.

>
Meanwhile, I won't make these assumptions, and I won't have to rely on
the implementations I use to comply with these assumptions.

But to do that you need to know the standard backwards. Whereas real
examples give real warnings.

[santosh]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>Richard wrote:

>>Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:
>Besides, I did provide a single example:
>>
>>>>A) Systems where a byte is more than 8 bits :
>>DSPs are a common example here.
No, you didn't. You mentioned a range of HW where it may or may not be
true :)
Well you wanted the examples, you go find them! :P

Er, I was. Here. From the people who keep telling us about them all.

Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

Concrete examples of systems with CHAR_BITS 8 have been mentioned before.
IIRC Jack Klein gave an example a few months ago. I also believe Keith
Thompson said that some Cray Vector machines he was familiar with had this
property.

[Philip Potter]

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

>Richard wrote:

>>Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:
>Besides, I did provide a single example:
>>
>>>>A) Systems where a byte is more than 8 bits :
>>DSPs are a common example here.
No, you didn't. You mentioned a range of HW where it may or may not be
true :)
Well you wanted the examples, you go find them! :P
Er, I was. Here. From the people who keep telling us about them all.

Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements.

God helps those who help themselves:
http://groups.google.com/group/comp....rch+this+group

There is your answer, already answered several times in the history of
clc. All I did was put "DSP CHAR_BIT" into a google groups search of clc.

So no, I'm not joking. I honestly thought the information I had given
you would be enough. If I was wrong, I apologise.

Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

As for putting some "effort" in - I am. I am asking *here* where there
are a plethora of people who know a lot about such systems.

....and where the question has been answered a plethora of times before.
Have a look through the archives on google groups. And the FAQ (Richard
Heathfield pointed out elsethread there are some examples of
non-all-bits-zero NULLs there).

I am hoping
they will give some examples of where a byte is more than 8 bits or
CHAR_BITS is more than 8. And it is a benevolent quest. I want to see
these systems and look at their specs too. It would be really good to
reference them whenever telling people their code is not standards
compliant.

Yes, it would be very useful. I want to stress that it is not necessary,
that is, even if there is no system where you can't fit a function
pointer into a void *, you still shouldn't do it. But it is good to have
examples of where assumptions are wrong.

>Meanwhile, I won't make these assumptions, and I won't have to rely on
the implementations I use to comply with these assumptions.

But to do that you need to know the standard backwards. Whereas real
examples give real warnings.

Or heed the advice such as in the response to the OP in this thread.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

santosh <sa*********@gmail.comwrites:

Richard wrote:

>Philip Potter <pg*@see.sig.invalidwrites:

>>Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
>Philip Potter <pg*@see.sig.invalidwrites:
>>Besides, I did provide a single example:
>>>
>>>>>A) Systems where a byte is more than 8 bits :
>>>DSPs are a common example here.
>No, you didn't. You mentioned a range of HW where it may or may not be
>true :)
Well you wanted the examples, you go find them! :P

Er, I was. Here. From the people who keep telling us about them all.

Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

Concrete examples of systems with CHAR_BITS 8 have been mentioned before.
IIRC Jack Klein gave an example a few months ago. I also believe Keith
Thompson said that some Cray Vector machines he was familiar with had this
property.

Yes, so lets get them with links now so we can keep them. I would gladly
keep a list up to date.

As for Cray Vector machines, lets try and get a list of machines more
available to the common man but they would be a good start if we could
get a link to the specs.

[Richard]

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:

>Philip Potter <pg*@see.sig.invalidwrites:

>>Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
>Philip Potter <pg*@see.sig.invalidwrites:
>>Besides, I did provide a single example:
>>>
>>>>>A) Systems where a byte is more than 8 bits :
>>>DSPs are a common example here.
>No, you didn't. You mentioned a range of HW where it may or may not be
>true :)
Well you wanted the examples, you go find them! :P
Er, I was. Here. From the people who keep telling us about them all.
Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements.

God helps those who help themselves:
http://groups.google.com/group/comp....rch+this+group

There is your answer, already answered several times in the history of
clc. All I did was put "DSP CHAR_BIT" into a google groups search of
clc.

So no, I'm not joking. I honestly thought the information I had given
you would be enough. If I was wrong, I apologise.

I was asking for individuals input. Anyone can google. Here and
now. Google answers 99% of all problems asked here if you take that view.

>

>Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

As for putting some "effort" in - I am. I am asking *here* where there
are a plethora of people who know a lot about such systems.

...and where the question has been answered a plethora of times
before. Have a look through the archives on google groups. And the FAQ
(Richard Heathfield pointed out elsethread there are some examples of
non-all-bits-zero NULLs there).

>I am hoping
they will give some examples of where a byte is more than 8 bits or
CHAR_BITS is more than 8. And it is a benevolent quest. I want to see
these systems and look at their specs too. It would be really good to
reference them whenever telling people their code is not standards
compliant.

Yes, it would be very useful. I want to stress that it is not
necessary, that is, even if there is no system where you can't fit a

It is necessary in the real world. People need
examples. Sorry. Otherwise it's like Pandoras box. Never look in, just
take our word ....

function pointer into a void *, you still shouldn't do it. But it is
good to have examples of where assumptions are wrong.

I'm particularly interested in this void * not being able to hide a
function pointer bit. I wonder how casting a func pointer to a void
printf works then? Or it isn't?

>

>>Meanwhile, I won't make these assumptions, and I won't have to rely on
the implementations I use to comply with these assumptions.

But to do that you need to know the standard backwards. Whereas real
examples give real warnings.

Or heed the advice such as in the response to the OP in this thread.

Some people need examples. I am one such. The examples I am looking to
gather in a single place are to avoid having to rely on certain posters
assertions.

[jacob navia]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Richard wrote:

>>Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:
>
>Richard wrote:
>>Philip Potter <pg*@see.sig.invalidwrites:
>>>Besides, I did provide a single example:
>>>>
>>>>>>A) Systems where a byte is more than 8 bits :
>>>>DSPs are a common example here.
>>No, you didn't. You mentioned a range of HW where it may or may not be
>>true :)
>Well you wanted the examples, you go find them! :P
Er, I was. Here. From the people who keep telling us about them all.
Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.
Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

Concrete examples of systems with CHAR_BITS 8 have been mentioned before.
IIRC Jack Klein gave an example a few months ago. I also believe Keith
Thompson said that some Cray Vector machines he was familiar with had this
property.

Yes, so lets get them with links now so we can keep them. I would gladly
keep a list up to date.

As for Cray Vector machines, lets try and get a list of machines more
available to the common man but they would be a good start if we could
get a link to the specs.

K. Thomson said it was in a very old Cray implementation. Probably
the newer ones do not use that since ages.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Kenneth Brody]

Philip Potter wrote:

>
Richard wrote:

[...]

No. I think it's important to show that these systems really
exist. Otherwise a lot of people will think it's all a lot of hot
air. It does no harm to demonstrate WHERE the standard benefits the
programmer. Not some airy fairy "there might be a system with a 13 bit
char" for example.

But again, if you don't know how things are done on systems, you will be
protected from it. I know that NULL is not guaranteed to be
all-bits-zero, and I don't know where it is and where it isn't. I'm not
even sure whether or not NULL is all-bits-zero on x86, and I'm happy to
stay that way.

It's good to have a couple of examples of why certain common assumptions
shouldn't be relied on, but compiling a comprehensive list is asking for
people to rely on that list instead.

A "comprehensive list" also runs into the issue of finding "real
world" examples for all such things. Suppose, for example, that
you came up with CHAR_BITS != 8, NULL not all-bits-zero, and a
whole bunch of others, but couldn't find a system where int's
have padding bits which may be different between two ints of the
same value. Might that add to the impression that that particular
"rule" could be safely ignored?

(That's not to say that I don't have memsets on structs with
pointers in them, to set the pointers to NULL. But, I am aware
of the situation, and the application already has a bunch of
system-dependent code in it, so this particular issue is not of
concern -- for this application.)

[...]

>>3: Number systems other than two's complement may be used, so be
careful about doing things like using -1 to represent all-bits-one.
D) Where -1 is not an all bits on.
This is compicated again. For unsigned types, -1 is always
all-bits-one. I can't think why you'd want to set a signed type to
all-bits-one.

This is not the question. The question is what real platforms does -1
not get represented by an all bits on. This comes up all the time.

Give me an example of code which relies on -1 being all-bits-one.

Toggling bits by xor-ing with -1.

>

>>4: Function pointers might not fit inside ANY of the other types (e.g.
such as void* or unsigned long), so don't do that.
E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)
I can't think why you'd want to do this.

This is not the question. The question is where it would not work.

I used to work on a platform where function pointers were 32 bits
and data pointers were 16 bits. You can't store a generic array
of function pointers in an array of void pointers.

Why is that question relevant if noone tries to do it? I don't see you
asking for a list of platforms where NULL is 0xdeadbeef, because no code
depends on that.

There's a world of difference between assuming NULL is 0xdeadbeef
and assuming NULL is all-bits-zero. For latter is often done in
code which memsets structs to zero.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

santosh <sa*********@gmail.comwrites:
[...]

Concrete examples of systems with CHAR_BITS 8 have been mentioned before.
IIRC Jack Klein gave an example a few months ago. I also believe Keith
Thompson said that some Cray Vector machines he was familiar with had this
property.

Quibble: CHAR_BIT, not CHAR_BITS.

No, the Cray vector machines I've used had CHAR_BIT==8. The C
compiler had to go to considerable lengths to make this work, since
the smallest directly hardware-addressable unit of storage is a 64-bit
word. It would have been easier, and arguably more logical, for the C
compiler to use CHAR_BIT==64, but that would have broken compatibility
with other systems with which they had to communicate. The systems in
question ran a Unix operating system (UNICOS); I think POSIX requires
CHAR_BIT=8.

The last Cray vector system I used was the T90; it was shut down in
2002. There were newer Cray vector systems, but I never used them --
but since the need for interoperability certainly wouldn't have gone
away, I'd be very surprised if they had CHAR_BIT 8.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Richard <rg****@gmail.comwrites:

I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

[snip]

E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

A small quibble: Putting C identifiers or keywords in all-caps for
emphasis is not a good idea. void is a keyword; VOID is an identifier
and could very plausibly be a macro name (for example, I've seen code
that conditionally uses ``#define VOID int'' for pre-ANSI
compatibility). This is, as the phrase "small quibble" implies, not a
big deal, and I wouldn't have bothered to mention if it I weren't also
making another point.

Attempting to convert a function pointer to void* invoked undefined
behavior. (I had thought it was a constraint violation, but a quick
check of the standard doesn't support that.) A compiler isn't even
required to compile code that attempts such a conversion, regardless
of whether it *could* meaningfully do so. I would be unsurprised to
see a C compiler that rejects a program that attempts such a
conversion.

As for a specific example, I believe IBM AS/400 has been presented
here as such a system. My vague recollection is that function
pointers are considerably larger than void*. I've never used an
AS/400 system, so I can't confirm that.

If you're not getting some of the specific examples you're asking for,
it may be partly because some of the people who know about such
example have killfiled you. Behavior has consequences.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenneth Brody]

Ben Bacarisse wrote:

>
jacob navia <ja***@nospam.orgwrites:

[...]

Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

Because is just looks "wrong". :-)

To me, it looks like "take negative one as an unsigned value", even
though the real meaning is "negate the unsigned int value 1, and give
the result as an unsigned int".

In other words, as I understand it (now that I've looked into it a
little), "-1u" is really two tokens -- "-" and "1u".

It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int', the '-' negates this. The result (mathematical
-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Mon, 01 Oct 2007 14:17:23 -0700, Keith Thompson wrote:

santosh <sa*********@gmail.comwrites: [...]

>Concrete examples of systems with CHAR_BITS 8 have been mentioned
before. IIRC Jack Klein gave an example a few months ago. I also
believe Keith Thompson said that some Cray Vector machines he was
familiar with had this property.

Quibble: CHAR_BIT, not CHAR_BITS.

No, the Cray vector machines I've used had CHAR_BIT==8. The C compiler
had to go to considerable lengths to make this work, since the smallest
directly hardware-addressable unit of storage is a 64-bit word. It
would have been easier, and arguably more logical, for the C compiler to
use CHAR_BIT==64, but that would have broken compatibility with other
systems with which they had to communicate. The systems in question ran
a Unix operating system (UNICOS); I think POSIX requires CHAR_BIT=8.

<OTBefore the end of 2001, it didn't. (And after that, it only did
because C99 added a pointless requirement that uint8_t contain no padding
bits.) If they defined CHAR_BIT as 8, that's most likely a very sensible
decision, but one that had little to do with POSIX.

[Walter Roberson]

In article <08************@news.individual.net>,
Richard <rg****@gmail.comwrote:

>I was asking for individuals input. Anyone can google.

>Some people need examples. I am one such. The examples I am looking to
gather in a single place are to avoid having to rely on certain posters
assertions.

I have *individually* indicated a few times in the past that
I have personally worked on Honeywell L6 series machines which
used 9 bit characters. But since you do not appear to have chosen
to have listened to that, it would appear that I am one of
the "certain posters" whose assertions you do not trust.

Perhaps you will be more trusting of this header file, marked
copyright Motorola:

http://leo.sprossenwanne.at/dsp/Entw...CLUDE/LIMITS.H

/* the 561c supports 16 bit chars and ints, and 32 bit longs. */
/* the 56k supports 24 bit chars and ints, and 48 bit longs. */
/* the 96k supports 32 bit chars, ints, and longs. */

Or this data sheet from Texas Instruments:
http://www.datasheetarchive.com/preview/3430205.html
(Note the lack of 8 bit I/O -- everything is in 16 bit "words")

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[CBFalconer]

Charlie Gordon wrote:

>

.... snip ...

>
Personally, I would prefer if Standard C mandated 2s-complement
and defined the behaviour of shifting signed integer types left
and right. Maybe we should define a new language, Real-C where
these awkward historical detail would be removed...

Horrors. Then Real-C might even become popular, and all sorts of
code written in it by eager neophytes, which code can no longer be
made to run on older or newer machines, which in turn take
advantage of one or more of the known (or presently unknown)
advantages of sign-magnitude or 1's complement.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Kenneth Brody]

Keith Thompson wrote:

>
Richard <rg****@gmail.comwrites:

[...]

E) Where a function pointer can not be stored in a VOID
pointer. (Regardless of style)

A small quibble: Putting C identifiers or keywords in all-caps for
emphasis is not a good idea. void is a keyword; VOID is an identifier
and could very plausibly be a macro name (for example, I've seen code
that conditionally uses ``#define VOID int'' for pre-ANSI
compatibility).

BTDTGTHF.

This is, as the phrase "small quibble" implies, not a
big deal, and I wouldn't have bothered to mention if it I weren't also
making another point.

Attempting to convert a function pointer to void* invoked undefined
behavior. (I had thought it was a constraint violation, but a quick
check of the standard doesn't support that.) A compiler isn't even
required to compile code that attempts such a conversion, regardless
of whether it *could* meaningfully do so. I would be unsurprised to
see a C compiler that rejects a program that attempts such a
conversion.

The compiler on this system, with warnings turned up, gives a warning
about "nonstandard extension, function/data pointer conversion in
expression". But, it does compile.

As for a specific example, I believe IBM AS/400 has been presented
here as such a system. My vague recollection is that function
pointers are considerably larger than void*. I've never used an
AS/400 system, so I can't confirm that.

Well, on a related note, the AS/400 C compiler manual does say:

When you convert a valid function (procedure) pointer, system
pointer, invocation pointer, label pointer, or suspend pointer
to a signed or unsigned integer type, the result is always zero.

http://publib.boulder.ibm.com/infoce.../cpprog440.htm

I don't see anything about code-vs-data pointers.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 01 Oct 2007 14:29:17 -0700, Keith Thompson wrote:

Attempting to convert a function pointer to void* invoked undefined
behavior. (I had thought it was a constraint violation, but a quick
check of the standard doesn't support that.) A compiler isn't even
required to compile code that attempts such a conversion, regardless of
whether it *could* meaningfully do so. I would be unsurprised to see a
C compiler that rejects a program that attempts such a conversion.

If the behaviour is undefined, the compiler must accept the conversion,
unless it can prove the conversion will be performed in every possible
execution path of the program.

You're right that the behaviour is undefined. It should be a constraint
violation. Compilers in practise already treat it as such. This is
similar to conversions between pointers and floating point types.

[Flash Gordon]

Kenneth Brody wrote, On 01/10/07 21:26:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.orgwrites:

[...]

>>Is it legal to make -1u??
Unary minus applied to unsigned operand?

If you suspect it is not, why not say why?

Because is just looks "wrong". :-)

To me, it looks like "take negative one as an unsigned value", even
though the real meaning is "negate the unsigned int value 1, and give
the result as an unsigned int".

In other words, as I understand it (now that I've looked into it a
little), "-1u" is really two tokens -- "-" and "1u".

Either interpretation will give you the correct result in this case. -1
converted to unsigned int is guaranteed to be UINT_MAX. An unsigned int
with a value of 1 that is negated is also guaranteed to give you
UINT_MAX. However, in the case of C, there is not really any such thing
as a negative constant, there are only positive constants which are the
operand of a unary minus. This is why you often see odd looking
definitions of INT_MIN if you look in limits.h

>It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int',

There is no promotion involved, the u is part of the token 1u.

the '-' negates this. The result (mathematical

>-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

Again, no promotion involved, but the basic idea is correct.
--
Flash Gordon

[Ben Bacarisse]

Flash Gordon <sp**@flash-gordon.me.ukwrites:

Kenneth Brody wrote, On 01/10/07 21:26:

>Ben Bacarisse wrote:

>>jacob navia <ja***@nospam.orgwrites:

[...]

>>>Is it legal to make -1u??
Unary minus applied to unsigned operand?
If you suspect it is not, why not say why?

Because is just looks "wrong". :-)

To me, it looks like "take negative one as an unsigned value", even
though the real meaning is "negate the unsigned int value 1, and give
the result as an unsigned int".

In other words, as I understand it (now that I've looked into it a
little), "-1u" is really two tokens -- "-" and "1u".

Either interpretation will give you the correct result in this
case. -1
converted to unsigned int is guaranteed to be UINT_MAX. An unsigned
int with a value of 1 that is negated is also guaranteed to give you
UINT_MAX. However, in the case of C, there is not really any such
thing as a negative constant, there are only positive constants which
are the operand of a unary minus. This is why you often see odd
looking definitions of INT_MIN if you look in limits.h

>>It seems to me to to be perfectly well defined. The '1u' has promoted
type 'unsigned int',

There is no promotion involved, the u is part of the token 1u.

I did not say there was. Arithmetic operations are defined to be
applied to the promoted operand and, in case anyone quibbled, I was
stating that what the promoted type is. Obviously this requires no
actual action.

>the '-' negates this. The result (mathematical

>>-1) is converted back to the promoted type (unsigned int) by
repeatedly adding (or subtracting) one more than the maximum value
representable in that type (UINT_MAX + 1).

Again, no promotion involved, but the basic idea is correct.

and again I did not say there was. The definition of '-' says that
the "result has the promoted type" -- I was using that wording to
prevent any quibbles!

--
Ben.

[CBFalconer]

Keith Thompson wrote:

Richard <rg****@gmail.comwrites:

.... snip ...

>
If you're not getting some of the specific examples you're asking
for, it may be partly because some of the people who know about
such example have killfiled you. Behavior has consequences.

I'm in that group (plonkers). Know about is another question, and
varies. I have unplonked all from the topicality thread. So far I
have not found any that deserve permanent unplonking.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

Keith Thompson wrote:

>Richard <rg****@gmail.comwrites:

.... snip ...

>If you're not getting some of the specific examples you're asking
for, it may be partly because some of the people who know about
such example have killfiled you. Behavior has consequences.

I'm in that group (plonkers).

Now you wouldn't want to make that admission in the British English
speaking world :)

--
Ian Collins.

[CBFalconer]

Ben Bacarisse wrote:

>

.... snip ...

>
and again I did not say there was. The definition of '-' says that
the "result has the promoted type" -- I was using that wording to
prevent any quibbles!

On c.l.c? You must be dreaming. :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Sjouke Burry]

Ian Collins wrote:

CBFalconer wrote:

>Keith Thompson wrote:

>>Richard <rg****@gmail.comwrites:

.... snip ...

>>If you're not getting some of the specific examples you're asking
for, it may be partly because some of the people who know about
such example have killfiled you. Behavior has consequences.

I'm in that group (plonkers).

Now you wouldn't want to make that admission in the British English
speaking world :)

Tssk... A dirty mind is a joy forever :) :)
But do you HAVE to let us know that??

[Richard Heathfield]

Keith Thompson said:

<snip>

If you're not getting some of the specific examples you're asking for,
it may be partly because some of the people who know about such
example have killfiled you. Behavior has consequences.

Indeed it does. So does a marked improvement in behaviour, though. If it
ever happens, presumably it will show up in replies from those who haven't
killfiled him, and that may well lead to some modding up. In the meantime,
his constant unpleasantness has damaged his chances of getting good
answers to the questions he asks here. I doubt very much whether my
killfile is the only one he's in.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jack Klein]

On Mon, 01 Oct 2007 13:03:29 +0100, Philip Potter
<pg*@see.sig.invalidwrote in comp.lang.c:

Richard wrote:

I would be very interested for posters here to list the current systems
they use which would cause problems by breaking the rules. It might be a
good edition to the FAQ for people to go out and find real systems so as
to understand better why they need to be careful:

I partly agree and partly disagree here. I agree because it shows to new
people that strictly following the standard /is/ important because these
common assumptions aren't necessarily true. But I disagree because it
may encourage the view that if a system cannot be found which differs
from the norm, then it doesn't matter that we're making assumptions.

Martin Wells <wa****@eircom.netwrites:

>Does this mean that a byte can be larger than 8 bits (ie CHAR_BIT >
8)?

Yes, a byte can have more than eight bits. Welcome to the world of
portable C programming :D Here's a few other things to look out for in
portable programming:

A) Systems where a byte is more than 8 bits :

DSPs are a common example here.

Specifically, the TMS32C28xxx DSP family from Texas Instruments,
extremely popular in motion control and power supply generation.

CHAR_BIT is 16, sizeof(char)==sizeof(short)==sizeof(int) = 1.
sizeof(long) = 2. sizeof(long long) = 4. sizeof(float) = 2.

Not a "theoretical possibility", but a part I do a lot of work with,
including writing code for today.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Jack Klein]

On Mon, 01 Oct 2007 20:17:44 +0200, jacob navia <ja***@nospam.org>
wrote in comp.lang.c:

Richard wrote:

santosh <sa*********@gmail.comwrites:

Richard wrote:

Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
Philip Potter <pg*@see.sig.invalidwrites:

Richard wrote:
>Philip Potter <pg*@see.sig.invalidwrites:
>>Besides, I did provide a single example:
>>>
>>>>>A) Systems where a byte is more than 8 bits :
>>>DSPs are a common example here.
>No, you didn't. You mentioned a range of HW where it may or may not be
>true :)
Well you wanted the examples, you go find them! :P
Er, I was. Here. From the people who keep telling us about them all.
Was my answer not good enough for you? It sounded to me that you had a
benevolent quest to convince people that their assumptions about the
implementation were not necessarily correct. Surely you can put some
effort into finding some? I've already given you a hint for CHAR_BIT
!= 8.
Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.
Concrete examples of systems with CHAR_BITS 8 have been mentioned before.
IIRC Jack Klein gave an example a few months ago. I also believe Keith
Thompson said that some Cray Vector machines he was familiar with had this
property.

Yes, so lets get them with links now so we can keep them. I would gladly
keep a list up to date.

As for Cray Vector machines, lets try and get a list of machines more
available to the common man but they would be a good start if we could
get a link to the specs.

K. Thomson said it was in a very old Cray implementation. Probably
the newer ones do not use that since ages.

So you address the issue of Keith Thompson's posts, but ignore mine?
There is nothing obsolete or old about the TMS320C28xxx DSP family
that I am using today on multiple circuit boards. The production
version of the original parts began shipping less than 3 years ago.

Since then they have added literally dozens of models in the family,
the newest ones introduced in June and just starting to ship now.

Just to convince you, here is a copy and past from a small part of the
manual for the C and C++ compiler:

<--begin quotation-->
Type Size Representation Minimum Maximum
char, signed char 16 bits ASCII 32768 32767
unsigned char 16 bits ASCII 0 65535
short 16 bits 2s complement 32768 32767
unsigned short 16 bits binary 0 65535
int, signed int 16 bits 2s complement 32768 32767
unsigned int 16 bits binary 0 65535
long, signed long 32 bits 2s complement 2147483648 2147483647
unsigned long 32 bits binary 0 4294967295
<--end quotation-->

That's from a version of the compiler from several years ago. The
newer version adds 64-bit signed and unsigned long long, 64 bits, four
bytes.

I wrote (and linted and compiled) code for this implementation TODAY.

The best estimates I have seen recently are that about 2% of the CPU
chips made in the world today go into desktop, laptop, server, or
workstation products as the main processor, 32- or 64- bit chips
executing in a hosted environment of Windows, MacOS, various other
UNIX/Linux flavors, OS/2, QNX, VxWorks, and so on.

You are not familiar with more than a small percentage of these
processor/OS combinations, and next to nothing at all about the
operating environments and programming of the remaining 98% of the
CPUs made in the world.

While C is becoming much less widely used on the hosted platforms
listed above, it is the main tool for those other 98%.

You seem to think that your experience, however great, on 32- and
64-bit hosted environments makes you a profound expert on all C
platforms and implementations everywhere and anywhere. You could not
be more mistaken.

Just because your compiler and your customers have no interest in C
implementations where CHAR_BIT is 16, or 24, or 32, your arrogance
leads you to pronounce that such systems do not exist, or are not
important.

You are very, very wrong and in your arrogance you parade your
ignorance.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html