Why is ptrdiff_t a volatile?

Why is ptrdiff_t a volatile?

[Toby Douglass]

Good morning/afternoon/evening, all.

I've been writing some position independent data structure code.

As such, I've been using ptrdiff_t.

I've just noticed, while compiling, that my GCC (6.3.0) has ptrdiff_t as 
a volatile long int.

It is not clear to me why this type would be volatile.

I've googled, no luck.

So, why volatile?

Anyone know the rationale?

Re: Why is ptrdiff_t a volatile?

[Marc Glisse]

On Mon, 1 Oct 2018, Toby Douglass wrote:

> Good morning/afternoon/evening, all.
>
> I've been writing some position independent data structure code.
>
> As such, I've been using ptrdiff_t.
>
> I've just noticed, while compiling, that my GCC (6.3.0) has ptrdiff_t as a 
> volatile long int.

I doubt gcc does that. More likely your code has a broken macro somewhere. 
You don't provide enough information for us to help more...

-- 
Marc Glisse

Re: Why is ptrdiff_t a volatile?

[Toby Douglass]

On 01/10/2018 11:10, Marc Glisse wrote:
> On Mon, 1 Oct 2018, Toby Douglass wrote:
> 
>> Good morning/afternoon/evening, all.
>>
>> I've been writing some position independent data structure code.
>>
>> As such, I've been using ptrdiff_t.
>>
>> I've just noticed, while compiling, that my GCC (6.3.0) has ptrdiff_t 
>> as a volatile long int.
> 
> I doubt gcc does that. More likely your code has a broken macro 
> somewhere. You don't provide enough information for us to help more...

I thought I'd given enough for the question :-)

But I think you might be right indeed.

I've just had another line of output from GCC when it's unhappy with my 
code, which is this;

"note: expected ‘lfds720_pal_uint_t * {aka long long unsigned int *}’ 
but argument is of type ‘ptrdiff_t * {aka long int *}’"

Now before I was being told a ptrdiff_t was a volatile long int.

It looks like if I add volatile to a type, it turns up in the "aka".

I was not expecting this - I thought the aka would be the underlying 
type, sans qualifiers.

Re: Why is ptrdiff_t a volatile?

[Jonathan Wakely]

On Mon, 1 Oct 2018 at 10:31, Toby Douglass <toby@winterflaw.net> wrote:
>
> On 01/10/2018 11:10, Marc Glisse wrote:
> > On Mon, 1 Oct 2018, Toby Douglass wrote:
> >
> >> Good morning/afternoon/evening, all.
> >>
> >> I've been writing some position independent data structure code.
> >>
> >> As such, I've been using ptrdiff_t.
> >>
> >> I've just noticed, while compiling, that my GCC (6.3.0) has ptrdiff_t
> >> as a volatile long int.
> >
> > I doubt gcc does that. More likely your code has a broken macro
> > somewhere. You don't provide enough information for us to help more...
>
> I thought I'd given enough for the question :-)

No, because you're just making a claim about GCC's behaviour based on
code we can't see. It t urns out you weren't even basing it on the
code, but on the content of a diagnostic message.

> But I think you might be right indeed.
>
> I've just had another line of output from GCC when it's unhappy with my
> code, which is this;
>
> "note: expected ‘lfds720_pal_uint_t * {aka long long unsigned int *}’
> but argument is of type ‘ptrdiff_t * {aka long int *}’"
>
> Now before I was being told a ptrdiff_t was a volatile long int.

No you weren't.

> It looks like if I add volatile to a type, it turns up in the "aka".

Of course. If ptrdiff_t is a typedef for long int, then ptrdiff_t* is
long int*, and volatile ptrdiff_t* is volatile long int*.

The aka "unwraps" typedefs to show you the actual type, but it doesn't
strip qualifiers, because that would give a different type.

> I was not expecting this - I thought the aka would be the underlying
> type, sans qualifiers.

No, it's the actual type. Otherwise the message would not be very
helpful when it tells you that you can't convert const int* to int*,
because it would just show int* twice.