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

Fulvio Baccaglini fulvio_baccaglini at prqa.com
Fri Jun 1 11:35:02 BST 2018


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.

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

>  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.

>  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 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
}

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
---------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20180601/d64f8725/attachment.html>


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