[C-safe-secure-studygroup] minutes - Example of violation of Rule 11.2

Fulvio Baccaglini fulvio_baccaglini at programmingresearch.com
Tue Nov 28 16:33:22 GMT 2017


Hi,

Finally revisiting Aaron's example :)

If I remember the context correctly, this would be an example of an
approach that is not uncommon e.g. when transferring data.

This example violates Rule 11.2: "Conversions shall not be performed
between a pointer to an incomplete type and any other type":

> from Aaron Ballman to Everyone:
> extern struct foo *f(size_t *size);
> size_t size = 0;
> struct foo *fp = f(&size);
> char *cp = (char *)fp;                    // violates Rule 11.2
> char *buffer = (char *)malloc(size);
> if (buffer) {
>   for (size_t i = 0; i < size; ++i) {
>     buffer[i] = cp[i];
>   }
> }
> from Aaron Ballman to Everyone:
> struct foo *fp2 = (struct foo *)buffer;   // violates Rule 11.2

Some draft thoughts:

Ways to clear the violation would be to:
(1) make type foo complete in the TU where foo objetcs are being converted
(2) convert foo objects in the TU where type foo is complete

However:
(1) if type foo is made complete in this example, then Dir 4.8 would be
violated: "If a pointer to structure or union is never dereferenced
within a translation unit, then the implementation of the object should
be hidden".
(1 & 2) the cast "(struct foo *)buffer" with type foo complete would
still violate Rule 11.3: "A cast shall not be performed between a
pointer to object type and a pointer to a different object type".

I believe that the main risk is with C99 undefined behaviour 22:
"Conversion between two pointer types produces a result that is
incorrectly aligned".

My understanding at the moment is that depending on how foo is aligned,
and therefore depending on how foo is defined, there may be restrictions
on where the buffer in the receiving application can be located, for the
cast "(struct foo *)buffer" not to result in undefined behaviour.

The example seems to be mixing two concerns: how to use and how to
implement (operations, like conversions on) objects of type foo, and
Rule 11.2 and Dir 4.8 seem to push towards the separation of these
concerns. Once separated, the potential for undefined behaviour would be
restricted to the TU with the implementation concern. Rule 11.3 will
still have to be deviated, requiring some analysis, but this analysis
may also be restricted to the TU where the information is available.

If Rule 11.2 or Rule 11.3 or both are dropped, then the same issue would
arise, of how to otherwise capture the possible undefined behaviour.

Cheers,
Fulvio


On 03/11/17 17:33, Robert Seacord wrote:
>
> from Robert Seacord to Everyone:
> https://gitlab.com/trustable/C_Safety_and_Security_Rules_Study_Group/wikis/misrarule11.2
> from Aaron Ballman to Everyone:
> extern struct foo *f(size_t *size);
> size_t size = 0;
> struct foo *fp = f(&size);
> char *cp = (char *)fp;
> char *buffer = (char *)malloc(size);
> if (buffer) {
>   for (size_t i = 0; i < size; ++i) {
>     buffer[i] = cp[i];
>   }
> }
> from Aaron Ballman to Everyone:
> struct foo *fp2 = (struct foo *)buffer;
> from Aaron Ballman to Everyone:
> 6.2.7 covers compatible types
>
>
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
---------------------------------------------------------------------------------------
 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/20171128/524588f0/attachment.html>


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