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

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

Const-qualified function return type in C - is it a part of function type?

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

Contents

  Const-qualified function return type in C - is it a part of function type? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-02-21 14:35 -0800
    Const-qualified function return type in C - is it a part of function type? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-21 15:24 -0800
      Re: Const-qualified function return type in C - is it a part of function type? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-02-21 16:19 -0800
        Re: Const-qualified function return type in C - is it a part of function type? Richard Damon <Richard@Damon-Family.org> - 2020-02-21 20:50 -0500
          Re: Const-qualified function return type in C - is it a part of function type? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-02-21 19:56 -0800
            Re: Const-qualified function return type in C - is it a part of function type? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-22 14:22 +0000
              Re: Const-qualified function return type in C - is it a part of function type? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 10:06 -0800
                Re: Const-qualified function return type in C - is it a part of function type? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-22 21:20 +0000
                  Re: Const-qualified function return type in C - is it a part of function type? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 20:58 -0800
              Re: Const-qualified function return type in C - is it a part of function type? luser droog <luser.droog@gmail.com> - 2020-02-22 19:24 -0800
                Re: Const-qualified function return type in C - is it a part of function type? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-23 03:52 +0000
                  Re: Const-qualified function return type in C - is it a part of function type? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 21:06 -0800
        Re: Const-qualified function return type in C - is it a part of function type? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-21 21:21 -0800
    Re: Const-qualified function return type in C - is it a part of function type? Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-22 07:51 +0100
      Re: Const-qualified function return type in C - is it a part of function type? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-02-22 05:00 -0800
        Re: Const-qualified function return type in C - is it a part of function type? Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-22 16:23 +0100
        Re: Const-qualified function return type in C - is it a part of function type? Guillaume <message@bottle.org> - 2020-02-22 20:37 +0100
          Re: Const-qualified function return type in C - is it a part of function type? Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-22 20:50 +0100
            Re: Const-qualified function return type in C - is it a part of function type? David Brown <david.brown@hesbynett.no> - 2020-02-23 07:29 +0100
              Re: Const-qualified function return type in C - is it a part of function type? Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-23 08:57 +0100
    Re: Const-qualified function return type in C - is it a part of function type? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 09:53 -0800

Page 1 of 2  [1] 2  Next page →

#150130 — Const-qualified function return type in C - is it a part of function type?

Here's the code

   const int foo() { return 42; }

   int main()
   {
     int (*pFunc)() = foo;
   }

(In C++ mode both GCC and Clang reject this code, which is expected.)

When this code is compiled as C, GCC remains completely quiet, even in 
presence of `-pedantic`. Clang always issues a warning about the types 
being incompatible. In `-pedantic-errors` mode Clang flags this as an error.

So, what is it really?

On the one hand, `const` in this case is applied to something that is 
definitely not an lvalue, which makes it "meaningless" per 6.7.3/5 ("The 
properties associated with qualified types are meaningful only for 
expressions that are lvalues.")

On the other hand, the concept of *compatible type* does not in any way 
rely on expression-specific context and on the concept of lvalue, which 
seems to suggest that Clang is right: the types are not compatible here.

-- 
Best regards,
Andrey Tarasevich

[toc] | [next] | [standalone]

#150132

"If the specification of a function type includes any type qualifiers,
the behavior is undefined." (6.7.3p9).

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

#150134

On 2/21/2020 3:24 PM, James Kuyper wrote:
> "If the specification of a function type includes any type qualifiers,
> the behavior is undefined." (6.7.3p9).

Um... That is completely irrelevant. What you quoted refers to 
qualifiers applied to the function type itself. My original example 
qualifies the function return type, not the function type itself.

-- 
Best regards,
Andrey Tarasevich

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

#150135

On 2/21/20 7:19 PM, Andrey Tarasevich wrote:
> On 2/21/2020 3:24 PM, James Kuyper wrote:
>> "If the specification of a function type includes any type qualifiers,
>> the behavior is undefined." (6.7.3p9).
> 
> Um... That is completely irrelevant. What you quoted refers to 
> qualifiers applied to the function type itself. My original example 
> qualifies the function return type, not the function type itself.
> 
But the return type is part of the type of the function.

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

#150136

On 2/21/2020 5:50 PM, Richard Damon wrote:
> On 2/21/20 7:19 PM, Andrey Tarasevich wrote:
>> On 2/21/2020 3:24 PM, James Kuyper wrote:
>>> "If the specification of a function type includes any type qualifiers,
>>> the behavior is undefined." (6.7.3p9).
>>
>> Um... That is completely irrelevant. What you quoted refers to 
>> qualifiers applied to the function type itself. My original example 
>> qualifies the function return type, not the function type itself.
>>
> But the return type is part of the type of the function.

So what? Almost any cv-qualifier anywhere in the function declaration is 
"part of the type of the function". Are you trying to say that this is 
undefined

    const int* foo(const void *bar);

???

To avoid any further wastage of time on this irrelevant matter I hereby 
postulate one more time: the above quoted passage refers to qualifiers 
applied to the function type itself (which, BTW, is only possible 
through typedef names). It has nothing to do with qualifiers used in 
function return type or in function parameter types.

-- 
Best regards,
Andrey Tarasevich

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

#150144

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
<cut>

> To avoid any further wastage of time on this irrelevant matter I
> hereby postulate one more time: the above quoted passage refers to
> qualifiers applied to the function type itself (which, BTW, is only
> possible through typedef names).

And interesting detail, which I can't interpret...  In all versions of
the C standard, there is a footnote attached to the paragraph

  "If the specification of an array type includes any type qualifiers,
  the element type is so qualified, not the array type. If the
  specification of a function type includes any type qualifiers, the
  behavior is undefined."

In C90, this footnote seems to be:

  59) Both of these can only occur through the use of typedefs.

By C99 it appears to have become

  118) Both of these can occur through the use of typedefs.

Why the change I wonder?  Is there a way to qualify a function or array
type without a typedef?  I can't see one.

By the way, I hedge with "seems be" and "appears to have become" because
I don't have either standard, only pre-publication drafts.  Maybe
someone with the actual text can verify?

-- 
Ben.

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

#150156

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> <cut>
>
>> To avoid any further wastage of time on this irrelevant matter I
>> hereby postulate one more time:  the above quoted passage refers to
>> qualifiers applied to the function type itself (which, BTW, is only
>> possible through typedef names).
>
> And interesting detail, which I can't interpret...  In all versions of
> the C standard, there is a footnote attached to the paragraph
>
>   "If the specification of an array type includes any type qualifiers,
>   the element type is so qualified, not the array type.  If the
>   specification of a function type includes any type qualifiers, the
>   behavior is undefined."
>
> In C90, this footnote seems to be:
>
>   59) Both of these can only occur through the use of typedefs.
>
> By C99 it appears to have become
>
>   118) Both of these can occur through the use of typedefs.
>
> Why the change I wonder?

I believe it was prompted by point 8 in this document, written by
Doug Gwyn (dated 1997):

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n762.htm

> Is there a way to qualify a function or array
> type without a typedef?  I can't see one.

I believe there is not.  My guess is Doug was confused about what
the footnoted sentence was meant to say, which in turn led him to
misinterpret the footnote.

> By the way, I hedge with "seems be" and "appears to have become" because
> I don't have either standard, only pre-publication drafts.  Maybe
> someone with the actual text can verify?

I believe the quotes you give match the published standards
exactly, except that the footnotes have different numbers.

Incidentally, when I say "I believe" it means I think the
statement following "believe" is true, even though I may not be
prepared to demonstrate its truth.  This is in contrast to
expressing an opinion, which is not about statements of
fact and so not subject to being disproved.

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

#150164

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> <cut>
>>
>>> To avoid any further wastage of time on this irrelevant matter I
>>> hereby postulate one more time:  the above quoted passage refers to
>>> qualifiers applied to the function type itself (which, BTW, is only
>>> possible through typedef names).
>>
>> And interesting detail, which I can't interpret...  In all versions of
>> the C standard, there is a footnote attached to the paragraph
>>
>>   "If the specification of an array type includes any type qualifiers,
>>   the element type is so qualified, not the array type.  If the
>>   specification of a function type includes any type qualifiers, the
>>   behavior is undefined."
>>
>> In C90, this footnote seems to be:
>>
>>   59) Both of these can only occur through the use of typedefs.
>>
>> By C99 it appears to have become
>>
>>   118) Both of these can occur through the use of typedefs.
>>
>> Why the change I wonder?
>
> I believe it was prompted by point 8 in this document, written by
> Doug Gwyn (dated 1997):
>
>     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n762.htm

Which says:

  8.  erroneous footnote 82

       8.1  the_problem

       Footnote 82 erroneously says that only through the use of
       typedefs can array or function type specifications include
       any type qualifiers.

       8.2  my_opinion

       I think this footnote was trying to be helpful, but
       incorrect footnotes are not helpful.

       8.3  my_proposal

       In 6.5.3 Type qualifiers, delete Footnote 82 and the
       reference to it.
 
>> Is there a way to qualify a function or array
>> type without a typedef?  I can't see one.
>
> I believe there is not.  My guess is Doug was confused about what
> the footnoted sentence was meant to say, which in turn led him to
> misinterpret the footnote.

What a strange state of affairs.  The original is helpful precisely
because of the one word that got removed.  And I can't see why n762
caused the vital word to be removed.

<cut>
-- 
Ben.

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

#150212

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>> <cut>
>>>
>>>> To avoid any further wastage of time on this irrelevant matter I
>>>> hereby postulate one more time:  the above quoted passage refers to
>>>> qualifiers applied to the function type itself (which, BTW, is only
>>>> possible through typedef names).
>>>
>>> And interesting detail, which I can't interpret...  In all versions of
>>> the C standard, there is a footnote attached to the paragraph
>>>
>>>   "If the specification of an array type includes any type qualifiers,
>>>   the element type is so qualified, not the array type.  If the
>>>   specification of a function type includes any type qualifiers, the
>>>   behavior is undefined."
>>>
>>> In C90, this footnote seems to be:
>>>
>>>   59) Both of these can only occur through the use of typedefs.
>>>
>>> By C99 it appears to have become
>>>
>>>   118) Both of these can occur through the use of typedefs.
>>>
>>> Why the change I wonder?
>>
>> I believe it was prompted by point 8 in this document, written by
>> Doug Gwyn (dated 1997):
>>
>>     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n762.htm
>
> Which says:
>
>   8.  erroneous footnote 82
>
>        8.1  the_problem
>
>        Footnote 82 erroneously says that only through the use of
>        typedefs can array or function type specifications include
>        any type qualifiers.
>
>        8.2  my_opinion
>
>        I think this footnote was trying to be helpful, but
>        incorrect footnotes are not helpful.
>
>        8.3  my_proposal
>
>        In 6.5.3 Type qualifiers, delete Footnote 82 and the
>        reference to it.
>
>>> Is there a way to qualify a function or array
>>> type without a typedef?  I can't see one.
>>
>> I believe there is not.  My guess is Doug was confused about what
>> the footnoted sentence was meant to say, which in turn led him to
>> misinterpret the footnote.
>
> What a strange state of affairs.  The original is helpful precisely
> because of the one word that got removed.

Personally I find the footnote helpful either with or without the
word 'only'.  For me the 'only' doesn't add much, if indeed it
adds anything helpful at all.

> And I can't see why n762 caused the vital word to be removed.

Probably because, as Doug was a member of long standing, and very
much involved in working on the Standard, he was taken at his
word that something about the footnote was inaccurate.  At the
same time it was realized that it isn't obvious how to construct
such qualified types, so the footnote was left in, in a modified
form, to help with that.

The previous paragraph is speculation on my part, so take it for
what it is worth.  I don't have any evidence to point to in
support of that speculation.

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

#150169

On Saturday, February 22, 2020 at 8:22:18 AM UTC-6, Ben Bacarisse wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> <cut>
> 
> > To avoid any further wastage of time on this irrelevant matter I
> > hereby postulate one more time: the above quoted passage refers to
> > qualifiers applied to the function type itself (which, BTW, is only
> > possible through typedef names).
> 
> And interesting detail, which I can't interpret...  In all versions of
> the C standard, there is a footnote attached to the paragraph
> 
>   "If the specification of an array type includes any type qualifiers,
>   the element type is so qualified, not the array type. If the
>   specification of a function type includes any type qualifiers, the
>   behavior is undefined."
> 
> In C90, this footnote seems to be:
> 
>   59) Both of these can only occur through the use of typedefs.
> 
> By C99 it appears to have become
> 
>   118) Both of these can occur through the use of typedefs.
> 
> Why the change I wonder?  Is there a way to qualify a function or array
> type without a typedef?  I can't see one.
> 

What about using parens?

int (const sammy[2]);
float (volatile davis)(void);

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

#150170

luser droog <luser.droog@gmail.com> writes:

> On Saturday, February 22, 2020 at 8:22:18 AM UTC-6, Ben Bacarisse wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> <cut>
>> 
>> > To avoid any further wastage of time on this irrelevant matter I
>> > hereby postulate one more time: the above quoted passage refers to
>> > qualifiers applied to the function type itself (which, BTW, is only
>> > possible through typedef names).
>> 
>> And interesting detail, which I can't interpret...  In all versions of
>> the C standard, there is a footnote attached to the paragraph
>> 
>>   "If the specification of an array type includes any type qualifiers,
>>   the element type is so qualified, not the array type. If the
>>   specification of a function type includes any type qualifiers, the
>>   behavior is undefined."
>> 
>> In C90, this footnote seems to be:
>> 
>>   59) Both of these can only occur through the use of typedefs.
>> 
>> By C99 it appears to have become
>> 
>>   118) Both of these can occur through the use of typedefs.
>> 
>> Why the change I wonder?  Is there a way to qualify a function or array
>> type without a typedef?  I can't see one.
>
> What about using parens?

I don't think you can.  I tried.

> int (const sammy[2]);

I think int (const sammy)[2]; would be closer (were it allowed) because
parentheses in a declarator are there to stop you reading in the
"default" direction -- to the right.  Reading what you wrote, you'd say
"sammy is an array of 2 const int".

> float (volatile davis)(void);

That's the way it would be written, but you can't do that as far as I
can see.

-- 
Ben.

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

#150213

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> luser droog <luser.droog@gmail.com> writes:
>
>> On Saturday, February 22, 2020 at 8:22:18 AM UTC-6, Ben Bacarisse wrote:
>>
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>> <cut>
>>>
>>>> To avoid any further wastage of time on this irrelevant matter I
>>>> hereby postulate one more time:  the above quoted passage refers to
>>>> qualifiers applied to the function type itself (which, BTW, is only
>>>> possible through typedef names).
>>>
>>> And interesting detail, which I can't interpret...  In all versions of
>>> the C standard, there is a footnote attached to the paragraph
>>>
>>>   "If the specification of an array type includes any type qualifiers,
>>>   the element type is so qualified, not the array type.  If the
>>>   specification of a function type includes any type qualifiers, the
>>>   behavior is undefined."
>>>
>>> In C90, this footnote seems to be:
>>>
>>>   59) Both of these can only occur through the use of typedefs.
>>>
>>> By C99 it appears to have become
>>>
>>>   118) Both of these can occur through the use of typedefs.
>>>
>>> Why the change I wonder?  Is there a way to qualify a function or array
>>> type without a typedef?  I can't see one.
>>
>> What about using parens?
>
> I don't think you can.  I tried.

I concur with Ben here.

>> int (const sammy[2]);
>
> I think int (const sammy)[2]; would be closer (were it allowed) because
> parentheses in a declarator are there to stop you reading in the
> "default" direction -- to the right.  Reading what you wrote, you'd say
> "sammy is an array of 2 const int".
>
>> float (volatile davis)(void);
>
> That's the way it would be written, but you can't do that as far as I
> can see.

If we are looking for an extension to supply the capability, how
about this way:

    int sammy const [2];
    float davis volatile (void);

I note with some amusement that C++ made a different choice, for
member functions:

    int x_value() const;

Of course the meaning of "const" here isn't quite the same as
the "const" we are used to, but it does modify the function
type itself:  they are commonly (or officially?) called
"const member functions".

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

#150137

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 2/21/2020 3:24 PM, James Kuyper wrote:
>> "If the specification of a function type includes any type qualifiers,
>> the behavior is undefined." (6.7.3p9).
>
> Um... That is completely irrelevant. What you quoted refers to
> qualifiers applied to the function type itself. My original example
> qualifies the function return type, not the function type itself.

I agree that that was the intent.  It wouldn't make sense to say that
    void(*)(const int*)
has undefined behavior.  But it is the specification of a function type,
and it does include a type qualifier.  I think that sentence needs to be
clarified.  (And I know this doesn't answer your original question.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#150138

> So, what is it really?

It doesn't matter if this is legal code or not because
there is n necessity to write such code.

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

#150142

On 2/21/2020 10:51 PM, Bonita Montero wrote:
>> So, what is it really?
> 
> It doesn't matter if this is legal code or not because
> there is n necessity to write such code.

This is a *language-lawyer* kind of question. And yes, it matters and 
matters a lot. And it is completely irrelevant whether there is a 
"necessity to write such code".

-- 
Best regards,
Andrey Tarasevich

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

#150145

> This is a *language-lawyer* kind of question. And yes, it matters
> and  matters a lot. And it is completely irrelevant whether there
> is a "necessity to write such code".

No, practice dictates the necessities.

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

#150160

Le 22/02/2020 à 14:00, Andrey Tarasevich a écrit :
> On 2/21/2020 10:51 PM, Bonita Montero wrote:
>>> So, what is it really?
>>
>> It doesn't matter if this is legal code or not because
>> there is n necessity to write such code.
> 
> This is a *language-lawyer* kind of question. And yes, it matters and 
> matters a lot. And it is completely irrelevant whether there is a 
> "necessity to write such code".

Agreed.
This is an interesting issue you raised here.
I just tried changing it using a typedef for the return type such as 
'typedef const int cint_t;' and using it as the return type. It didn't 
change anything: GCC is still perfectly quiet about it. So it's not just 
about the potential ambiguity of what the qualifier qualifies here. Not 
so good.

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

#150161

> Agreed.
> This is an interesting issue you raised here.

It's an issue to end in itself and having no practical sense. Theo-
retically it may be relevant for compiler-writers, but it wouldn't
hurt if even if a compiler-writer would implement it wrong because
no none writes such meaningless code.

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

#150174

On 22/02/2020 20:50, Bonita Montero wrote:
>> Agreed.
>> This is an interesting issue you raised here.
> 
> It's an issue to end in itself and having no practical sense. Theo-
> retically it may be relevant for compiler-writers, but it wouldn't
> hurt if even if a compiler-writer would implement it wrong because
> no none writes such meaningless code.

While people would be unlikely to write this sort of thing directly, all 
sorts of unusual constructs can turn up as a result of generators of 
various sorts (macros, C++ templates, typedefs, external code 
generators, etc.).  It can be useful to know the legality and effect of 
code even if it is something people would never write explicitly.

And even if it is something that would never be generated either, c.l.c. 
is perhaps one of the few places on earth where people should be free to 
discuss hypothetical and technical points about the C language without 
some killjoy trying to spoil the fun by claiming it is impractical.

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

#150177

> While people would be unlikely to write this sort of thing directly, all 
> sorts of unusual constructs can turn up as a result of generators of 
> various sorts (macros, C++ templates, typedefs, external code 
> generators, etc.).  It can be useful to know the legality and effect of 
> code even if it is something people would never write explicitly.

Sorry, there wouldn't be any code-generator that generates such
nonsense.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web