[C-safe-secure-studygroup] Agenda and WebEx details for meeting - 13 December 2017

Robert Seacord rcseacord at gmail.com
Wed Dec 13 15:39:01 GMT 2017


I added the following discussion for Rule 11.8 to the wiki at
https://gitlab.com/trustable/C_Safety_and_Security_Rules_Study_Group/wikis/misrarule11.8



Rule 11.8  A cast shall not remove any const or volatile qualification form
the type pointed to by a pointer.

Required and Decidable

Compliance with all of Rule 11.4, 11.8, and 19.2 prevents the creation of
non-const qualified pointer to an object declared with const-qualified type.

There is no existing TS 17961 rule, except:

5.33    Passing pointers into the same object as arguments to different
restrict-qualified parameters [restrict]

WRT UB#68 below

C11 Undefined Behaviors

64  An attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type (6.7.3).
65  An attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with
non-volatile-qualified type (6.7.3).
68  An object which has been modified is accessed through a
restrict-qualified pointer to a const-qualified type, or through a
restrict-qualified pointer and another pointer that are not both based on
the same object (6.7.3.1).

The CERT C rules are EXP40-C. Do not modify constant objects and EXP32-C.
Do not access a volatile object through a nonvolatile reference.

There is a CERT C Recommendation (not a rule) "EXP05-C. Do not cast away a
const qualification" that has a lot of exceptions to it:

EXP05-C-EX1: An exception to this recommendation is allowed when it is
necessary to cast away const when invoking a legacy API that does not
accept a const argument, provided the function does not attempt to modify
the referenced variable. For example, the following code casts away the
const qualification of INVFNAME in the call to the audit_log() function.

/* Legacy function defined elsewhere—cannot be modified */
void audit_log(char *errstr) {
  fprintf(stderr, "Error: %s.\n", errstr);
}

/* ... */
const char INVFNAME[]  = "Invalid file name.";
audit_log((char *)INVFNAME); /* EXP05-EX1 */
/* ... */
EXP05-C-EX2: A number of C standard library functions are specified to
return non-const pointers that refer to their const-qualified arguments.
When the actual arguments to such functions reference const objects,
attempting to use the returned non-const pointers to modify the const
objects would be a violation of EXP40-C. Do not modify constant objects and
would lead to undefined behavior. These functions are the following:

memchr
strchr
strpbrk
strrchr
strstr
strtod
strtof
strtold
strtol
strtoll
strtoul
strtoull
wmemchr
wcschr
wcspbrk
wcsrchr
wcsstr

For instance, in following example, the function strchr returns an
unqualified char* that points to the terminating null character of the
constant character array s (which could be stored in ROM). Even though the
pointer is not const, attempting to modify the character it points to would
lead to undefined behavior.

extern const char s[];
char* where;
where = strchr(s, '\0');
/* Modifying *s is undefined */
Similarly, in the following example, the function strtol sets the
unqualified char* pointer referenced by end to point just past the last
successfully parsed character of the constant character array s (which
could be stored in ROM). Even though the pointer is not const, attempting
to modify the character it points to would lead to undefined behavior.

extern const char s[];
long x;
char* end;
x = strtol(s, &end, 0);
/* Modifying **end is undefined */
EXP05-C-EX3: Because const means "read-only," and not "constant," it is
sometimes useful to declare struct members as (pointer to) const objects to
obtain diagnostics when the user tries to change them in some way other
than via the functions that are specifically designed to maintain that data
type. Within those functions, however, it may be necessary to strip off the
const qualification to update those members.

On Wed, Dec 13, 2017 at 10:30 AM, Laurence Urhegyi <
laurence.urhegyi at codethink.co.uk> wrote:

> # WebEx
>
> https://iso-meetings.webex.com/iso-meetings/j.php?MTID=m2713
> 47609ab420957ccc2e1775aa773f
>
> Meeting code:
>
> 950 280 499
>
> Dial in numbers:
>
> UK toll-free 0800-051-3810
> UK toll +44-203-478-5289
> Italy toll    +39 0230410 440
> Italy toll free    800-870552
> Japan toll    +81 34580 8156
> Japan toll free    0053-11-61212
> USA/Canada toll    +1 631 267 4890
> USA/Canada toll free    1-855-299-5224
>
> Meeting code:
>
> 950 280 499
>
> # Agenda
>
> Actions from the last meeting:
> Michael Wong to propose an initial draft on parallel computing rules.
>
> Rules to cover:
>
> Rule 10.7 - Roberto
>
> 11.3 - Aaron
> 11.4 - Clive - thanks for the homework
> 11.5 - Martin
> 11.6 - Roberto
> 11.7 - Gavin
> 11.8 - Robert
> 11.9 - Fulvio
>
> 12.1 - Aaron
> 12.2 - Clive - thanks for the homework
> 12.3 - Martin
> 12.4 - Roberto
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20171213/dc1dcc3c/attachment-0001.html>


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