«

* Ioannis Vranos:
> Alf P. Steinbach wrote:
>
> > Yes. But with a difference between C and C++. C allows more bits used
> > as padding on signed types relative to corresponding unsigned, C++ does
> > not; the C++ requirements boil down to msb being used as sign bit.
>
> I did not understand what you are saying. For example, signed int and
> unsigned int cannot have padding bits?

They can. In C more of the total bits can be padding bits in the signed
int. In C++ signed and unsigned are required to have the same number of
value representation bits, per the definition of "value representation".


> >>writing on (bytes containing) padding bits is undefined behaviour.
> >
> > Yes, that is correct, but it's not the same. For one can easily ensure
> > that there are no padding bits (a simple compile time assertion).
>
> ?

In short it boils down to "is undefined behavior" versus "can be
undefined behavior". In the case of padding bits accessible to the
program it is undefined behavior. In the more general case of integer
types in C++ it isn't necessarily undefined behavior, and the
possibility of UB is only on antiquated machinery for which I'm not even
sure that C++ compilers exist, and furthermore that remote, purely
academic possibility can be avoided by a simple compile time assertion.

A compile time assertion is any statement that makes the program not
compile on a machine where some specified assumption does not hold.

So, wrt. integers in general, as opposed to the hypothetical situation
of having padding bits, it's not "is", it is "can hypothetically be".


> > And
> > furthermore there are AFAIK no modern machines that use integer padding
> > bits accessible to a program, so even the un-safety in unchecked context
> > is purely an academic one, not one that can be encountered in practice.
>
> What do you mean they are not accessible in a program.

What do you mean "they are not accessible in a program"?


> All objects are accessible including their padding bits.

All C++ objects are accessible. You would however find it difficult to
access processor registers in pure standard C++ without any platform
specific library or language extensions. Similarly, you would find it
difficult to access any padding bits used internally by some processor
(said processor being just as hypothetical and far-fetched as one that
uses padding bits visible to C++). The context of my remark was
hypothetical _machines_ that use integer padding bits -- because it
seems you think such machines should be considered in deciding whether
to use memset or not. To understand that remark better, consider a real
machine, namely the ordinary PC, that uses extra bits in floating point
calculations (those are not padding bits, but). Whether the machine
itself uses such bits is one thing, and that is similar to the context
of the remark. Whether they're accessible to C++ is another; in old
versions of Visual C++ they were, in Visual C++ 7.1 they aren't.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Why does the following compile:

int BlahChar(char)
{
char aaa = 5;
return aaa;
}

int BlahChar(signed char)
{
signed char bbb = 5;
return bbb;
}

int BlahChar(unsigned char)
{
unsigned char ccc = 5;
return ccc;
}


int main()
{
signed char jk;

Blah(jk);
}



For instance:

short == short int == signed short == signed short int

int == signed int

long == long int = signed long = signed long int


Is the above correct in ALL circumstances?



I can only presume that:

char == signed char

char == unsigned char

is not neccessilary true, and that it's implementation defined. Would I be
right?


-JKop

"JKop" <> wrote in message
news:V7aFc.3669$...
>
> Why does the following compile:
>
> int BlahChar(char)
> {
> char aaa = 5;
> return aaa;
> }
>
> int BlahChar(signed char)
> {
> signed char bbb = 5;
> return bbb;
> }
>
> int BlahChar(unsigned char)
> {
> unsigned char ccc = 5;
> return ccc;
> }
>
>
> int main()
> {
> signed char jk;
>
> Blah(jk);
> }
>
>
>
> For instance:
>
> short == short int == signed short == signed short int
>
> int == signed int
>
> long == long int = signed long = signed long int
>
>
> Is the above correct in ALL circumstances?
>

AFAIK there is not such type as signed short, signed int or signed long. But
short == short int and long == long int always.

>
>
> I can only presume that:
>
> char == signed char
>
> char == unsigned char
>
> is not neccessilary true, and that it's implementation defined. Would I be
> right?

Those are never true. Even though char is either signed or unsigned it is
not the same type as unsigned char, or signed char.

This mess is the history of C/C++. In the original C is was left undefined
whether char is signed or unsigned. I guess signed char was intorduced to
overcome this, at least you can now explicitly say you want a signed char.

john

* JKop:
>
> I can only presume that:
>
> char == signed char
>
> char == unsigned char
>
> is not neccessilary true, and that it's implementation defined. Would I be
> right?

Yes, if you mean what I think. §3.9.1/1: "Plain 'char', 'signed char',
and 'usigned char' are three distinct types."

'char' is either signed or unsigned in a given implementation, but not
the _same_ type as 'signed char' or 'unsigned char'.

The same situation holds for 'wchar_t', which is a distinct type but
mapped to another integer type, it's "underlying type" in the HS.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

In message <V7aFc.3669$>, JKop <>
writes
>
>Why does the following compile:
>
>int BlahChar(char)
>{
> char aaa = 5;
> return aaa;
>}
>
>int BlahChar(signed char)
>{
> signed char bbb = 5;
> return bbb;
>}
>
>int BlahChar(unsigned char)
>{
> unsigned char ccc = 5;
> return ccc;
>}
>
>
>int main()
>{
> signed char jk;
>
> Blah(jk);
>}
>
>
Why wouldn't it? You have three distinct function overloads there.
>
>For instance:
>
>short == short int == signed short == signed short int
>
>int == signed int
>
>long == long int = signed long = signed long int
>
>Is the above correct in ALL circumstances?
>
>
>
>I can only presume that:
>
>char == signed char
>
>char == unsigned char
>
>is not neccessilary true, and that it's implementation defined. Would I be
>right?

Depends what you mean by "==". Why not buy that copy of the Standard and
turn to 3.9.1?

Plain char, signed char and unsigned char are three distinct types, but
plain char can take exactly the same values as one of the other two
types, and this choice is implementation-defined.

--
Richard Herring

Richard Herring posted:

> In message <V7aFc.3669$>, JKop <>
> writes
>>
>>Why does the following compile:
>>
>>int BlahChar(char)
>>{
>> char aaa = 5;
>> return aaa;
>>}
>>
>>int BlahChar(signed char)
>>{
>> signed char bbb = 5;
>> return bbb;
>>}
>>
>>int BlahChar(unsigned char)
>>{
>> unsigned char ccc = 5;
>> return ccc;
>>}
>>
>>
>>int main()
>>{
>> signed char jk;
>>
>> Blah(jk);
>>}
>>
>>
> Why wouldn't it? You have three distinct function overloads there.


If I'd known that do you think I would've written my original post. Given
that, do you think your reply was in anyway stupid, ignorant or arrogant?


>>For instance:
>>
>>short == short int == signed short == signed short int
>>
>>int == signed int
>>
>>long == long int = signed long = signed long int
>>
>>Is the above correct in ALL circumstances?
>>
>>
>>
>>I can only presume that:
>>
>>char == signed char
>>
>>char == unsigned char
>>
>>is not neccessilary true, and that it's implementation defined. Would I
>>be right?
>
> Depends what you mean by "==". Why not buy that copy of the Standard
> and turn to 3.9.1?


You know exactly what I mean by "==", that's just you being ignorant again.

Because it's a rip-off.


-JKop

Alf P. Steinbach wrote:

>>I did not understand what you are saying. For example, signed int and
>>unsigned int cannot have padding bits?
>
>
> They can. In C more of the total bits can be padding bits in the signed
> int. In C++ signed and unsigned are required to have the same number of
> value representation bits, per the definition of "value representation".


You said it nicely. However both can have padding bits, and when we use
memset() to zero all bytes (including those with the padding bits), we
modify these parts of bytes too.




> In short it boils down to "is undefined behavior" versus "can be
> undefined behavior". In the case of padding bits accessible to the
> program it is undefined behavior.


Ok then we agree.



> In the more general case of integer
> types in C++ it isn't necessarily undefined behavior, and the
> possibility of UB is only on antiquated machinery for which I'm not even
> sure that C++ compilers exist, and furthermore that remote, purely
> academic possibility can be avoided by a simple compile time assertion.



It is not on antiquated machinery, only reading bytes containing padding
bits is guaranteed to be safe in the standard.





> A compile time assertion is any statement that makes the program not
> compile on a machine where some specified assumption does not hold.



Compile time assertions - if present - are system specific extensions
and their kind and use differ from system to system.

If you are saying that there are specific systems where we can
manipulate the padding bits and have no side effects, the answer is they
are. However we are talking about portability here.



> All C++ objects are accessible. You would however find it difficult to
> access processor registers in pure standard C++ without any platform
> specific library or language extensions.


Yes, however using register keyword, it is up to the implementation to
decide if it will put a variable in a register.



> Similarly, you would find it
> difficult to access any padding bits used internally by some processor
> (said processor being just as hypothetical and far-fetched as one that
> uses padding bits visible to C++). The context of my remark was
> hypothetical _machines_ that use integer padding bits -- because it
> seems you think such machines should be considered in deciding whether
> to use memset or not. To understand that remark better, consider a real
> machine, namely the ordinary PC, that uses extra bits in floating point
> calculations (those are not padding bits, but). Whether the machine
> itself uses such bits is one thing, and that is similar to the context
> of the remark. Whether they're accessible to C++ is another; in old
> versions of Visual C++ they were, in Visual C++ 7.1 they aren't.


From the standard:


5.3.3 Sizeof

"When applied to a reference or a reference type, the result is the size
of the referenced type. When applied to a class, the result is the
number of bytes in an object of that class including any padding
required for placing objects of that type in an array."



If the object's size returned by sizeof includes padding bits, then
these padding bits have to be accessible.






Regards,

Ioannis Vranos

JKop wrote:

> Why does the following compile:
>
> int BlahChar(char)
> {
> char aaa = 5;
> return aaa;
> }
>
> int BlahChar(signed char)
> {
> signed char bbb = 5;
> return bbb;
> }
>
> int BlahChar(unsigned char)
> {
> unsigned char ccc = 5;
> return ccc;
> }
>
>
> int main()
> {
> signed char jk;
>
> Blah(jk);
> }
>
>
>
> For instance:
>
> short == short int == signed short == signed short int
>
> int == signed int
>
> long == long int = signed long = signed long int
>
>
> Is the above correct in ALL circumstances?




Of course since they are the *same type* respectively!






> I can only presume that:
>
> char == signed char
>
> char == unsigned char
>
> is not neccessilary true, and that it's implementation defined. Would I be
> right?



The three above are different types, but it is required by the standard
their size to be 1 (1 byte) always.






Regards,

Ioannis Vranos

John Harrison wrote:

> AFAIK there is not such type as signed short, signed int or signed long. But
> short == short int and long == long int always.




Of course there is a type signed short, it is your "short" and "short
int". Its complete name is "signed short int" and it is glad to meet
you.

unsigned long int is also an existing type.






Regards,

Ioannis Vranos

* Ioannis Vranos:
> Alf P. Steinbach wrote:
>
> >>I did not understand what you are saying. For example, signed int and
> >>unsigned int cannot have padding bits?
> >
> >
> > They can. In C more of the total bits can be padding bits in the signed
> > int. In C++ signed and unsigned are required to have the same number of
> > value representation bits, per the definition of "value representation".
>
>
> You said it nicely. However both can have padding bits, and when we use
> memset() to zero all bytes (including those with the padding bits), we
> modify these parts of bytes too.

Well, then, you'll have to come up with at least one C++ compiler
where this is the case for some standard integer type.

But note that that just moves the potential "problem" into the realm of
possibility.

If (against expectation) such compiler is found it doesn't mean that
zeroing arrays of integers via memset is UB in general; just that the
proposition that it _can hypothetically_ be can be amended to _can_.


> > In the more general case of integer
> > types in C++ it isn't necessarily undefined behavior, and the
> > possibility of UB is only on antiquated machinery for which I'm not even
> > sure that C++ compilers exist, and furthermore that remote, purely
> > academic possibility can be avoided by a simple compile time assertion.
>
> It is not on antiquated machinery

No? Name one modern such computer, then. I.e. one in use with C++
compiler.


>, only reading bytes containing padding
> bits is guaranteed to be safe in the standard.

?


> > A compile time assertion is any statement that makes the program not
> > compile on a machine where some specified assumption does not hold.
>
> Compile time assertions - if present - are system specific extensions
> and their kind and use differ from system to system.

No no no. What needs to asserted is simply that the range of the
relevant integer type requires the full number of bits in the object.
That is very easy to assert in system-independent way.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?