Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #14097 > unrolled thread

Type interchange

Back to article view | Back to comp.lang.c

Contents

  Type interchange Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-30 21:53 +0000
    Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-11-30 17:29 -0500
      Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-11-30 15:22 -0800
        Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-11-30 19:10 -0500
          Re: Type interchange Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-01 03:09 +0000
            Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 07:13 -0500
              Re: Type interchange Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-01 15:55 +0000
                Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 11:28 -0500
                  Re: Type interchange Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-01 16:45 +0000
                    Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 12:00 -0500
                  Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 14:31 -0800
                    Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 20:18 -0500
                      Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 17:35 -0800
                        Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-02 12:03 -0500
                          Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-02 13:49 -0800
                            Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-02 22:12 -0500
                              Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-03 02:01 -0800
                    Re: Type interchange Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 12:47 -0800
              Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-01 11:10 -0500
                Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 11:34 -0500
                Re: Type interchange Kaz Kylheku <kaz@kylheku.com> - 2011-12-01 17:48 +0000
                Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 14:17 -0800
                  Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-01 17:43 -0500
                    Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 15:00 -0800
                      Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-01 19:29 -0500
                        Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 16:59 -0800
                          Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-02 08:35 -0500
                            Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-02 08:46 -0500
                              Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-02 13:32 -0800
                            Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-02 13:30 -0800
                              Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-02 18:45 -0500
          Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-11-30 19:17 -0800
            Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 06:50 -0500
              Re: Type interchange Keith Thompson <kst-u@mib.org> - 2011-12-01 07:15 -0800
                Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 10:36 -0500
                  Re: Type interchange pete <pfiland@mindspring.com> - 2011-12-01 11:04 -0500
                    Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-01 11:37 -0500
                  Re: Type interchange Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 13:02 -0800
              Re: Type interchange Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 13:01 -0800
      Re: Type interchange Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-12-02 22:15 +0000
        Re: Type interchange James Kuyper <jameskuyper@verizon.net> - 2011-12-03 11:39 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14176

On 2011-12-01, pete <pfiland@mindspring.com> wrote:
> James Kuyper wrote:
>  
>> Some people prefer to describe this by saying that if there's any
>> possible conforming implementation
>> where the behavior is undefined, then
>> the behavior is undefined, period, even on other implementations where
>> the condition that makes it undefined isn't true - but I find that
>> interpretation incoherent.
>
> That way, 
> whether or not a program contains undefined behavior
> is a property of the C program,
> and not a property of the 
> combination of the implementation and C program.

That's fair. A program can contain latent undefined behavior (i.e. the
potential for it) yet depend on the parameters of the implementation
such that the behavior can be avoided.

[toc] | [prev] | [next] | [standalone]

#14191

pete <pfiland@mindspring.com> writes:
> James Kuyper wrote:
>> Some people prefer to describe this by saying that if there's any
>> possible conforming implementation
>> where the behavior is undefined, then
>> the behavior is undefined, period, even on other implementations where
>> the condition that makes it undefined isn't true - but I find that
>> interpretation incoherent.
>
> That way, 
> whether or not a program contains undefined behavior
> is a property of the C program,
> and not a property of the 
> combination of the implementation and C program.

int n = 32767;
n ++;

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14196

Keith Thompson wrote:
> 
> pete <pfiland@mindspring.com> writes:
> > James Kuyper wrote:
> >> Some people prefer to describe this by saying that if there's any
> >> possible conforming implementation
> >> where the behavior is undefined, then
> >> the behavior is undefined, period, even on other implementations where
> >> the condition that makes it undefined isn't true - but I find that
> >> interpretation incoherent.
> >
> > That way,
> > whether or not a program contains undefined behavior
> > is a property of the C program,
> > and not a property of the
> > combination of the implementation and C program.
> 
> int n = 32767;
> n ++;

The behavior of that code isn't limited by the standard, is it?

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14197

pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
>> pete <pfiland@mindspring.com> writes:
>> > James Kuyper wrote:
>> >> Some people prefer to describe this by saying that if there's any
>> >> possible conforming implementation
>> >> where the behavior is undefined, then
>> >> the behavior is undefined, period, even on other implementations where
>> >> the condition that makes it undefined isn't true - but I find that
>> >> interpretation incoherent.
>> >
>> > That way,
>> > whether or not a program contains undefined behavior
>> > is a property of the C program,
>> > and not a property of the
>> > combination of the implementation and C program.
>> 
>> int n = 32767;
>> n ++;
>
> The behavior of that code isn't limited by the standard, is it?

If INT_MAX == 32767, then its behavior is undefined.  Otherwise, its
behavior is well defined (it sets n to 32768).

The point is that whether or not a program contains undefined
behavior already is "a property of the combination of the
implementation and C program".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14201

Keith Thompson wrote:
> 
> pete <pfiland@mindspring.com> writes:
> > Keith Thompson wrote:
> >> pete <pfiland@mindspring.com> writes:
> >> > James Kuyper wrote:
> >> >> Some people prefer to describe this by saying that if there's any
> >> >> possible conforming implementation
> >> >> where the behavior is undefined, then
> >> >> the behavior is undefined, period, even on other implementations where
> >> >> the condition that makes it undefined isn't true - but I find that
> >> >> interpretation incoherent.
> >> >
> >> > That way,
> >> > whether or not a program contains undefined behavior
> >> > is a property of the C program,
> >> > and not a property of the
> >> > combination of the implementation and C program.
> >>
> >> int n = 32767;
> >> n ++;
> >
> > The behavior of that code isn't limited by the standard, is it?
> 
> If INT_MAX == 32767, then its behavior is undefined.  Otherwise, its
> behavior is well defined (it sets n to 32768).
> 
> The point is that whether or not a program contains undefined
> behavior already is "a property of the combination of the
> implementation and C program".

Whether or not a program is a "strictly conforming program"
is not dependant on the implementation,
and whether or not a program is a correct program
is not dependant on the implementation.

The code that you posted was intended to have a portability issue.
A non portable program construct 
for which the standard imposes no requirements, 
is what the standard says yields undefined behavior.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14205

pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
>> pete <pfiland@mindspring.com> writes:
>> > Keith Thompson wrote:
>> >> pete <pfiland@mindspring.com> writes:
>> >> > James Kuyper wrote:
>> >> >> Some people prefer to describe this by saying that if there's any
>> >> >> possible conforming implementation
>> >> >> where the behavior is undefined, then
>> >> >> the behavior is undefined, period, even on other implementations where
>> >> >> the condition that makes it undefined isn't true - but I find that
>> >> >> interpretation incoherent.
>> >> >
>> >> > That way,
>> >> > whether or not a program contains undefined behavior
>> >> > is a property of the C program,
>> >> > and not a property of the
>> >> > combination of the implementation and C program.
>> >>
>> >> int n = 32767;
>> >> n ++;
>> >
>> > The behavior of that code isn't limited by the standard, is it?
>> 
>> If INT_MAX == 32767, then its behavior is undefined.  Otherwise, its
>> behavior is well defined (it sets n to 32768).
>> 
>> The point is that whether or not a program contains undefined
>> behavior already is "a property of the combination of the
>> implementation and C program".
>
> Whether or not a program is a "strictly conforming program"
> is not dependant on the implementation,

Agreed.

> and whether or not a program is a correct program
> is not dependant on the implementation.

Depends on what you mean by "correct".

> The code that you posted was intended to have a portability issue.

Of course.

> A non portable program construct 
> for which the standard imposes no requirements, 
> is what the standard says yields undefined behavior.

But it doesn't say that *all* uses of nonportable program constructs
yield undefined behavior.

Let's make it a complete program:

int main(void) {
    int n = 32767;
    n ++;
    return 0;
}

I say that this program (specifically its execution) has undefined
behavior under an implementation with INT_MAX == 32767, and has
well defined behavior under an implementation with INT_MAX > 32767.

What do you say?  Are you claiming that the program's behavior is
undefined regardless of the implementation?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14225

Keith Thompson wrote:
> 
> pete <pfiland@mindspring.com> writes:
> > Keith Thompson wrote:
> >> pete <pfiland@mindspring.com> writes:
> >> > Keith Thompson wrote:
> >> >> pete <pfiland@mindspring.com> writes:
> >> >> > James Kuyper wrote:
> >> >> >> Some people prefer to describe this by saying that if there's any
> >> >> >> possible conforming implementation
> >> >> >> where the behavior is undefined, then
> >> >> >> the behavior is undefined, period, even on other implementations where
> >> >> >> the condition that makes it undefined isn't true - but I find that
> >> >> >> interpretation incoherent.
> >> >> >
> >> >> > That way,
> >> >> > whether or not a program contains undefined behavior
> >> >> > is a property of the C program,
> >> >> > and not a property of the
> >> >> > combination of the implementation and C program.
> >> >>
> >> >> int n = 32767;
> >> >> n ++;
> >> >
> >> > The behavior of that code isn't limited by the standard, is it?
> >>
> >> If INT_MAX == 32767, then its behavior is undefined.  Otherwise, its
> >> behavior is well defined (it sets n to 32768).
> >>
> >> The point is that whether or not a program contains undefined
> >> behavior already is "a property of the combination of the
> >> implementation and C program".
> >
> > Whether or not a program is a "strictly conforming program"
> > is not dependant on the implementation,
> 
> Agreed.
> 
> > and whether or not a program is a correct program
> > is not dependant on the implementation.
> 
> Depends on what you mean by "correct".
> 
> > The code that you posted was intended to have a portability issue.
> 
> Of course.
> 
> > A non portable program construct
> > for which the standard imposes no requirements,
> > is what the standard says yields undefined behavior.
> 
> But it doesn't say that *all* uses of nonportable program constructs
> yield undefined behavior.
> 
> Let's make it a complete program:
> 
> int main(void) {
>     int n = 32767;
>     n ++;
>     return 0;
> }
> 
> I say that this program (specifically its execution) has undefined
> behavior under an implementation with INT_MAX == 32767, and has
> well defined behavior under an implementation with INT_MAX > 32767.
> 
> What do you say?  Are you claiming that the program's behavior is
> undefined regardless of the implementation?

Yes.

That's an example of a non portable construct
for which the standard imposes no requirements.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14227

On 12/02/2011 08:35 AM, pete wrote:
> Keith Thompson wrote:
...
>> int main(void) {
>>     int n = 32767;
>>     n ++;
>>     return 0;
>> }
>>
>> I say that this program (specifically its execution) has undefined
>> behavior under an implementation with INT_MAX == 32767, and has
>> well defined behavior under an implementation with INT_MAX > 32767.
...
> That's an example of a non portable construct
> for which the standard imposes no requirements.

It's a non-portable construct for which the standard imposes
requirements on every implementation where INT_MAX > 32767, and no
requirements on any implementation where INT_MAX == 32767.

Otherwise there's no safe way to use any number bigger than the
documented minimal ranges for each type; there would be no point in
allowing those ranges to be bigger than that minimum, because every
program that makes use of the extra range has undefined behavior, anyway.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#14241

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/02/2011 08:35 AM, pete wrote:
>> Keith Thompson wrote:
> ...
>>> int main(void) {
>>>     int n = 32767;
>>>     n ++;
>>>     return 0;
>>> }
>>>
>>> I say that this program (specifically its execution) has undefined
>>> behavior under an implementation with INT_MAX == 32767, and has
>>> well defined behavior under an implementation with INT_MAX > 32767.
> ...
>> That's an example of a non portable construct
>> for which the standard imposes no requirements.
>
> It's a non-portable construct for which the standard imposes
> requirements on every implementation where INT_MAX > 32767, and no
> requirements on any implementation where INT_MAX == 32767.
>
> Otherwise there's no safe way to use any number bigger than the
> documented minimal ranges for each type; there would be no point in
> allowing those ranges to be bigger than that minimum, because every
> program that makes use of the extra range has undefined behavior, anyway.

That's not *quite* true:

#include <stdio.h>
#include <limits.h>
int main(void) {
    int n = 32767;
    if (INT_MAX > 32767) {
        n ++;
    }
    printf("n = %d\n", n);
    return 0;
}

Programs that use arrays to do multi-precision arithmetic, for example,
can reasonably choose the range used for each "digit" based on constants
in <limits.h>; the same code might use 16 bits for element on one
implementation, 32 on another, and 64 on another.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14240

pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
[...]
>> Let's make it a complete program:
>> 
>> int main(void) {
>>     int n = 32767;
>>     n ++;
>>     return 0;
>> }
>> 
>> I say that this program (specifically its execution) has undefined
>> behavior under an implementation with INT_MAX == 32767, and has
>> well defined behavior under an implementation with INT_MAX > 32767.
>> 
>> What do you say?  Are you claiming that the program's behavior is
>> undefined regardless of the implementation?
>
> Yes.
>
> That's an example of a non portable construct
> for which the standard imposes no requirements.

And that's where I think you're wrong.  It's a non-portable construct
for which the standard *does* impose a requirement.  The requirement is
that if INT_MAX > 32767, then the value of n after "n ++;" shall be
32768.

Given a revised program:

#include <stdio.h>
int main(void) {
    int n = 32767;
    n ++;
    printf("n = %d\n", n);
    return 0;
}

do you believe that, on an implementation with INT_MAX > 32767,
and in the absence of I/O errors, that program can do anything
other than printing "n = 32768"?

A conditional requirement is still a requirement.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14249

Keith Thompson wrote:
> 
> pete <pfiland@mindspring.com> writes:
> > Keith Thompson wrote:
> [...]
> >> Let's make it a complete program:
> >>
> >> int main(void) {
> >>     int n = 32767;
> >>     n ++;
> >>     return 0;
> >> }
> >>
> >> I say that this program (specifically its execution) has undefined
> >> behavior under an implementation with INT_MAX == 32767, and has
> >> well defined behavior under an implementation with INT_MAX > 32767.
> >>
> >> What do you say?  Are you claiming that the program's behavior is
> >> undefined regardless of the implementation?
> >
> > Yes.
> >
> > That's an example of a non portable construct
> > for which the standard imposes no requirements.
> 
> And that's where I think you're wrong.  It's a non-portable construct
> for which the standard *does* impose a requirement.  The requirement is
> that if INT_MAX > 32767, then the value of n after "n ++;" shall be
> 32768.
> 
> Given a revised program:
> 
> #include <stdio.h>
> int main(void) {
>     int n = 32767;
>     n ++;
>     printf("n = %d\n", n);
>     return 0;
> }
> 
> do you believe that, on an implementation with INT_MAX > 32767,
> and in the absence of I/O errors, that program can do anything
> other than printing "n = 32768"?

No.

> A conditional requirement is still a requirement.

I'm starting to see things your way.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14126

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/30/2011 06:22 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> A function declaration that is not a function prototype, and is used in
>>> a function call expression with no arguments, can be compatible with a
>>> function defined as taking no parameters - but only if the return types
>>> are compatible. Nothing in the standard allows you to assume that 'long'
>>> and 'int' are compatible types, not even if INT_MAX == LONG_MAX. 'int'
>>> could be a one's complement type, while 'long' is a 2's complement type.
>>> 'int' could be little-endian, while 'long' could be big-endian. When
>>> used as function arguments, 'int' and 'long' values could be passed in
>>> different registers.
>> [...]
>> 
>> The standard defines the term "compatible type".  It's clear from
>> the standard that int and long are *not* compatible types.
>
> The standard says that two types are compatible if they're the same. The
> standard has several locations where it specifies that particular pairs
> of types that are not the same are still compatible. There are rules for
> derived types such as arrays, functions, structures, and unions, which
> allow them to be compatible only if the derivations are sufficiently
> similar. However, I couldn't find any place in the normative text where
> it specifies that any particular pair of basic types must be
> incompatible. Footnote 35 says that char, signed char, and unsigned char
> are incompatible types, but I can't find supporting normative text.

As I understand it, there doesn't have to be any text that says int
and long aren't compatible.  The fact that nothing says they *are*
compatible means that they aren't.  The definition of "compatible
types" is spread across 4 different sections, but I believe it's
intended to be exhaustive.  Otherwise, how would you demonstrate
that *any* pair of types are incompatible?

> I think that a particular pair of types are in fact compatible for a
> given implementation, if everything that the standard says must work
> when two types are compatible, does in fact work for that pair of types,
> when using that implementation, even if the standard fails to guarantee
> that those types are compatible.
>
> Could you cite any specific requirement that would be violated by an
> implementation that treated 'int' and 'long' as compatible types?

If int and long are compatible (even for a particular implementation),
then int* and long* are also compatible by 6.7.5.1p2.  This implies that
this:

    int *pi = NULL;
    long *pl = pi;
    ptrdiff_t pd = pl - pi;

does not necessarily violate a constraint.  I don't believe that's
the case; I believe the initialization of pl and the subtraction are
both constraint violations on all implementations.  (That doesn't
prove that int and long are incompatible, it merely demonstrates
a consequence if they were.)

And for what it's worth, gcc agrees with me; it complains

    warning: initialization from incompatible pointer type
    error: invalid operands to binary - (have 'long int *' and 'int *')

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
                        Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14148

On 11/30/2011 10:17 PM, Keith Thompson wrote:
...
> As I understand it, there doesn't have to be any text that says int
> and long aren't compatible.  The fact that nothing says they *are*
> compatible means that they aren't.  The definition of "compatible
> types" is spread across 4 different sections, but I believe it's
> intended to be exhaustive.  Otherwise, how would you demonstrate
> that *any* pair of types are incompatible?

The implementation always knows whether two types are incompatible; it
has to implement them. For the developer, I don't think that it is
possible to demonstrate from the standard that any pair of basic types
is incompatible. I think it's very bad practice to write code which
assumes that two types are compatible without being able to prove that
they are; but I think it's entirely possible that they are in fact
compatible for a given implementation, without being able to prove that
fact from the standard.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#14165

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/30/2011 10:17 PM, Keith Thompson wrote:
> ...
>> As I understand it, there doesn't have to be any text that says int
>> and long aren't compatible.  The fact that nothing says they *are*
>> compatible means that they aren't.  The definition of "compatible
>> types" is spread across 4 different sections, but I believe it's
>> intended to be exhaustive.  Otherwise, how would you demonstrate
>> that *any* pair of types are incompatible?
>
> The implementation always knows whether two types are incompatible; it
> has to implement them. For the developer, I don't think that it is
> possible to demonstrate from the standard that any pair of basic types
> is incompatible. I think it's very bad practice to write code which
> assumes that two types are compatible without being able to prove that
> they are; but I think it's entirely possible that they are in fact
> compatible for a given implementation, without being able to prove that
> fact from the standard.

Do you believe that this:

    int *ip = 0;
    long *lp = ip;

is valid (not a constraint violation) on *any* conforming
implementation?

"Compatible types" is a term defined by the standard; it needn't
conform to the English meanings of the words.  What is your basis
for assuming that the definition is not meant to be exhaustive, and
that types can be compatible when the standard doesn't say they are?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14166

On 12/01/2011 10:15 AM, Keith Thompson wrote:
...
> Do you believe that this:
> 
>     int *ip = 0;
>     long *lp = ip;
> 
> is valid (not a constraint violation) on *any* conforming
> implementation?
> 
> "Compatible types" is a term defined by the standard; it needn't
> conform to the English meanings of the words.  What is your basis
> for assuming that the definition is not meant to be exhaustive, and
> that types can be compatible when the standard doesn't say they are?

Mainly it's because 6.2.7p1 says "Additional rules for determining
whether two types are compatible are described in ...". It does not
describe them as rules for determining whether types are incompatible.
If the meaning is as you imply, it would have been clearer to say
something to the effect that two types not covered by any of these rules
are incompatible.

[toc] | [prev] | [next] | [standalone]

#14169

James Kuyper wrote:
> 
> On 12/01/2011 10:15 AM, Keith Thompson wrote:
> ...
> > Do you believe that this:
> >
> >     int *ip = 0;
> >     long *lp = ip;
> >
> > is valid (not a constraint violation) on *any* conforming
> > implementation?
> >
> > "Compatible types" is a term defined by the standard; it needn't
> > conform to the English meanings of the words.  What is your basis
> > for assuming that the definition is not meant to be exhaustive, and
> > that types can be compatible when the standard doesn't say they are?
> 
> Mainly it's because 6.2.7p1 says "Additional rules for determining
> whether two types are compatible are described in ...". It does not
> describe them as rules for determining whether types are incompatible.
> If the meaning is as you imply, it would have been clearer to say
> something to the effect that two types not covered
> by any of these rules are incompatible.

The example of char being compatible 
neither with signed char nor with unsigned char, 
should have made it clear enough.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14173

On 12/01/2011 11:04 AM, pete wrote:
> James Kuyper wrote:
>>
>> On 12/01/2011 10:15 AM, Keith Thompson wrote:
>> ...
>>> Do you believe that this:
>>>
>>>     int *ip = 0;
>>>     long *lp = ip;
>>>
>>> is valid (not a constraint violation) on *any* conforming
>>> implementation?
>>>
>>> "Compatible types" is a term defined by the standard; it needn't
>>> conform to the English meanings of the words.  What is your basis
>>> for assuming that the definition is not meant to be exhaustive, and
>>> that types can be compatible when the standard doesn't say they are?
>>
>> Mainly it's because 6.2.7p1 says "Additional rules for determining
>> whether two types are compatible are described in ...". It does not
>> describe them as rules for determining whether types are incompatible.
>> If the meaning is as you imply, it would have been clearer to say
>> something to the effect that two types not covered
>> by any of these rules are incompatible.
> 
> The example of char being compatible 
> neither with signed char nor with unsigned char, 
> should have made it clear enough.

It makes the intent clear; but since that footnote is not normative, if
there's no supporting statement in the normative text, that merely means
that the footnote was wrong, and that the normative words of the
standard failed to implement the intent of the authors.

[toc] | [prev] | [next] | [standalone]

#16230

James Kuyper <jameskuyper@verizon.net> writes [retained in full]:

> On 12/01/2011 10:15 AM, Keith Thompson wrote:
> ...
>> Do you believe that this:
>> 
>>     int *ip = 0;
>>     long *lp = ip;
>> 
>> is valid (not a constraint violation) on *any* conforming
>> implementation?
>> 
>> "Compatible types" is a term defined by the standard; it needn't
>> conform to the English meanings of the words.  What is your basis
>> for assuming that the definition is not meant to be exhaustive, and
>> that types can be compatible when the standard doesn't say they are?
>
> Mainly it's because 6.2.7p1 says "Additional rules for determining
> whether two types are compatible are described in ...". It does not
> describe them as rules for determining whether types are incompatible.
> If the meaning is as you imply, it would have been clearer to say
> something to the effect that two types not covered by any of these rules
> are incompatible.

Notice how he didn't answer your first question. :)

[toc] | [prev] | [next] | [standalone]

#16229

James Kuyper <jameskuyper@verizon.net> writes:

> On 11/30/2011 10:17 PM, Keith Thompson wrote:
> ...
>> As I understand it, there doesn't have to be any text that says int
>> and long aren't compatible.  The fact that nothing says they *are*
>> compatible means that they aren't.  The definition of "compatible
>> types" is spread across 4 different sections, but I believe it's
>> intended to be exhaustive.  Otherwise, how would you demonstrate
>> that *any* pair of types are incompatible?
>
> The implementation always knows whether two types are incompatible; it
> has to implement them. For the developer, I don't think that it is
> possible to demonstrate from the standard that any pair of basic types
> is incompatible. I think it's very bad practice to write code which
> assumes that two types are compatible without being able to prove that
> they are; but I think it's entirely possible that they are in fact
> compatible for a given implementation, without being able to prove that
> fact from the standard.

You have this backwards.  Since the Standard defines the term
'compatible', if you want to allege that int and long might
be compatible then the onus is on you to provide citations
for text in the Standard that might support that thesis.
Just saying you can't find anything that disproves it is
irrelevant;  there must be positive evidence.

[toc] | [prev] | [next] | [standalone]

#14243

On Wed, 30 Nov 2011 17:29:57 -0500, James Kuyper wrote:
> Nothing in the standard allows you to assume that 'long'
> and 'int' are compatible types, not even if INT_MAX == LONG_MAX. 'int'
> could be a one's complement type, while 'long' is a 2's complement type.
> 'int' could be little-endian, while 'long' could be big-endian. When
> used as function arguments, 'int' and 'long' values could be passed in
> different registers.

I don't think any of those would be a problem because the result is cast 
to (void) in the OP's code.

However problems would arise on those implementations where although 
LONG_MAX==INT_MAX, nonetheless sizeof(int)!=sizeof(long) because one of 
them has extra padding bits that the other does not.

//QP

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web