[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