[C-safe-secure-studygroup] Fwd: Can or should the pointer to void type be considered or treated as a pointer to object type?

Aaron Ballman aaron at aaronballman.com
Tue Jun 5 10:30:25 BST 2018


I just realized I had only responded to Fulvio and not the group. My
response to Fulvio is below.

FWIW, I've now received three different answers from WG14: void has
never been an object type, void changed to be an object type in C11,
and void has always been an object type. :-D However, to TL;DR it:

> I'd recommend exposition like "pointer to complete object type" if a pointer to a fully-described type is needed.

This seems to be the way the C standard does it these days. For
instance, 6.5.2p1 on the array subscripting postfix operator.

~Aaron

---------- Forwarded message ---------
From: Aaron Ballman <aaron at aaronballman.com>
Date: Fri, Jun 1, 2018 at 8:37 AM
Subject: Re: [C-safe-secure-studygroup] Can or should the pointer to
void type be considered or treated as a pointer to object type?
To: Fulvio Baccaglini <fulvio_baccaglini at prqa.com>


On Fri, Jun 1, 2018 at 6:21 AM, Fulvio Baccaglini
<fulvio_baccaglini at prqa.com> wrote:
>
> On 31/05/18 20:18, Aaron Ballman wrote:
>> On Thu, May 31, 2018 at 10:53 AM, Fulvio Baccaglini
>> <fulvio_baccaglini at prqa.com> wrote:
>>> This was a question left open at the meeting; I believe that the answer
>>> in no.
>> I've asked for clarification on the WG14 reflectors and the answers
>> coming back have been mixed. At least some people view C99 as having
>> treated void as an object type already and so C11's treatment is not a
>> change in behavior. Others view C99 as having treated void as a
>> non-object, non-function type (where "incomplete type" was its own
>> categorization rather than an orthogonal concept), and C11 as treating
>> void as an object type. The changes in question were introduced by
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1439.pdf.
>>
>> Thus far, no one has made a case that void in C17 is not an object
>> type, and similarly, no one has made a case that a pointer to void is
>> not also a pointer to object.
>>
>>> The C99 standard says:
>>>
>>> [C99-6.2.5-1] "Types are partitioned into object types (types that fully
>>> describe objects), function types (types that describe functions), and
>>> incomplete types (types that describe objects but lack information
>>> needed to determine their sizes)."
>> The people who claim void was an object type in C99 are basing that
>> off the parenthetical in this paragraph. An incomplete type is a type
>> that describes an object but lacks the information needed to determine
>> the object's size, therefore an incomplete type is an object type.
>
> Thank you for asking WG14, this clarifies a lot, especially the document
> about the changes introduced.
>
>> I was raising my concerns about "is void an object" over the rules
>> that talk about "pointer to object" and "pointer to void" as if the
>> relationship between void and object was orthogonal when it's not. I
>> believe that in C, all pointers to void are also pointers to object
>> (and only some pointers to object are pointers to void). For instance,
>> 11.4 (A conversion should not be performed between a pointer to object
>> and an integer type) and 11.6 (A cast shall not be performed between
>> pointer to void and an arithmetic type). Concretely, I would have
>> expected:
>> ```
>> void f(void *ptr, int *i_ptr) {
>> intptr_t ptr_val = (intptr_t)ptr; // #1
>> intptr_t i_ptr_val = (intptr_t)i_ptr; // 2
>> }
>> ```
>> I would expect #1 needs a MISRA deviation from 11.6 because there is
>> no exception for converting to intptr_t
>
> Yes.
>
>> and if 11.4 were mandatory
>> rather than advisory, #1 would need a deviation for 11.4 as well based
>> on the same logic.
>
> I think that Rule 11.4 does not apply to pointer to void because in the
> MISRA classification a pointer to void is not considered a pointer to
> object.

Based on your explanations, I now agree. I think this is a case where
MISRA redefined a term of art from C to be different than C and it's
caused (mild, perhaps entirely localized) confusion.

> (side note: deviations apply to required rules, while mandatory rules
> cannot be deviated).

Oh, good to know!

>> I would expect #2 only needs a MISRA deviation from
>> 11.4 only.
>
> Yes.
>
>> If I understand you properly, you're saying that I'd need
>> to deviate #1 from 11.6 only and #2 from 11.4 only.
>
> Yes.

Thank you for the clarification.

>> So it's really a
>> matter of "what rules are in scope for a void *?" kind of question --
>> do I need to consider interactions with the "pointer to object" rules
>> as well?
>
> I think that rules that refer to pointer to objects are not in scope for
> void * and interactions should not be considered.

I'll try to take that approach for future discussions.

> I agree that C17 classification and terminology should be followed as
> closely as possible for C17 rules, but even if C17 is unequivocal about
> pointer to void being a pointer to object, some rules may still need to
> be scoped over "pointer to objects that are not pointer to void". For
> instance:
>
> void f (short * x)
> {
>     (long *) x; // not OK (violates Rule 11.3)
>     (void *) x; // OK
> }

I'd recommend exposition like "pointer to complete object type" if a
pointer to a fully-described type is needed. You could distinguish
between "pointer to incomplete type" and "pointer to void" if needed
for rules that are about incomplete object types where this
distinction matters.

~Aaron

>
> Fulvio
>> ~Aaron
>
>
> ________________________________
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> ________________________________



More information about the C-safe-secure-studygroup mailing list