On Mon, 1 Oct 2018 at 10:31, Toby Douglass <toby@xxxxxxxxxxxxxx> 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.
