CERT C Secure Coding Standard: last call for reviewers [LWN.net]

CERT C Secure Coding Standard: last call for reviewers

Posted Mar 14, 2008 22:45 UTC (Fri) by endecotp (guest, #36428)
In reply to: CERT C Secure Coding Standard: last call for reviewers by ajross
Parent article: CERT C Secure Coding Standard: last call for reviewers

> Strict adherence to this rule, for example:
> https://www.securecoding.cert.org/confluence/display/secc...
> ...would seem to disallow any use of dlopen()/dlsym() 

The linked-to rule says: "Do not convert a function pointer to an incompatible type".  When
you call dlsym you get a void* which you cast to the function pointer type; you're not
"converting a function pointer to" anything and so not breaking their rule, as far as I can
see.

Their example is:

static void my_function(int a)
..snip..
  int (*new_function)(int a) = my_function;
  x = (*new_function)(10);

(Log in to post comments)

CERT C Secure Coding Standard: last call for reviewers

Posted Mar 15, 2008 0:10 UTC (Sat) by nix (subscriber, #2304) [Link]

Note that casting void to a function pointer *is* an extension to the C 
Standard. I can think of several platforms on which it might not work 
without special handling (generally those like HPPA or IA64 on which 
function pointers are elaborate descriptors of some kind: of course that 
special handling has to be provided, because a Unix these days has to have 
dlsym()...)

CERT C Secure Coding Standard: last call for reviewers

Posted Mar 15, 2008 3:31 UTC (Sat) by ajross (subscriber, #4563) [Link]

No, it works fine everywhere in the modern world.  The reason for that restriction in the C
standard is that historically there have existed "Harvard Architecture" machines where the
code and data areas are physically separate regions indexed with overlapping pointer values.
The only one I can think of off the top of my head that still exists in common use is the 8051
microcontroller.

CERT C Secure Coding Standard: last call for reviewers

Posted Mar 15, 2008 11:32 UTC (Sat) by Los__D (subscriber, #15263) [Link]

In fact "Harvard Architecture" CPU's doesn't (necessarily) reference different areas, just
different busses for code and data.

Thus, any modern CPU, more or less uses Harvard Architecture because of the split code/data
cache design.

- Which is, of course, completely irrelevant to your point, carry on. :)

DSPs use Harvard architecture

Posted Mar 16, 2008 6:29 UTC (Sun) by JoeBuck (subscriber, #2330) [Link]

... and if you have a cell phone you run one. Separate program and data space, and sometimes the busses are different widths.

CERT C Secure Coding Standard: last call for reviewers

Posted Mar 17, 2008 22:00 UTC (Mon) by im14u2c (subscriber, #5246) [Link]

It only really matters if you try to compare a (void *) that points to a function against a (void *) that points to data, or if function pointers have a much different cost to carry around (e.g. one pointer type is larger than the other). The latter could happen back in the old 16-bit x86 days, depending on your memory model. For example, "near" code (16 bit offset-only pointer) vs. "far" data (32-bit segment:offset pointer) or vice versa.