On 22 Jan 2004 09:03:07 -0800,
earlthenut@yahoo.com (Earl Higgins)
wrote in comp.lang.c:
[color=blue]
> The company where I work as a Senior Software Engineer is currently
> revamping their (1991 era) "Programming and Style Guidelines", and I'm
> on the committee. The company, in business for over 20 years, writes
> medical software, which must ultimately pass FDA approval and ISO 9000
> certification. The product the document applies to is a large system,
> (just over 3 million lines of code) running on a variety of platforms
> (all Unix-ish), and over 99% written in C (no C++), compiled with gcc.[/color]
So you're in a medical environment where you must deal with FDA's GMP.
To a great extent it depends on the category your product falls into
under the hazard analysis. It sounds like you have some kind of
diagnostic, imaging, or analysis software package that might possibly
cause misdiagnosis on error, but does not directly have the chance to
cause injury, such as controlling the radiation exposure or the motor
moving the patient relative to the equipment.
For C, start with this book which every C programmer should read:
Safer C: Developing Software in High-integrity and Safety-critical
Systems
Les Hatton
McGraw-Hill Education - Europe; ISBN: 0077076400
Despite the title, every professional C programmer should read this
book.
It is difficult to find this book in the US. It can be ordered from
sources like amazon.co.uk (I don't know if they ship to the US), or
from Blackwell's who do ship to the US, although it took a month for
my copy to arrive.
The next place to go is
http://www.misra.org.uk and get a copy of the
Misra C Guidelines. Version 2 won't be out until sometime in the
second quarter, but buy the original version now and the new one when
it becomes available. It is inexpensive enough.
Misra has some very excellent rules and some very poor ones, and it is
unlikely that any two experienced programmers will agree on which are
which. It leans towards rules relevant for small embedded systems.
Nevertheless it is the first serious attempt to put together a set of
rules for systems that must be highly reliable. It is largely based
on Hatton's work, and Andrew Koenig's "C Traps and Pitfalls", another
excellent source.
Then get Gimpel lint (PC-Lint or their UNIX flavor). It has a rule
set for MISRA C included. It takes some effort to tune it properly
for your code, but the payoff is enormous. If one of your platforms
is a PC, or your code base can at least build on a Windows PC, PC-Lint
is a real bargain.
[color=blue]
> There's alot wrong with the document, and there's alot of inertia in
> our Engineering Department to keep committing the same mistakes we've
> been doing since day one (e.g. casting return value from malloc), and
> even to go so far as to mandate the use of these constructs.
>
> I'd like to go into this project well-informed about a couple of
> specific topics, and was wondering if some of the veterans of this
> group could tell me whether their sympathies would lie for, or against
> each of the following actual passages from the document, and why:
>
> "C program file names must be unique within the first 14 characters.
> This is a limit imposed by at least one version of UNIX where the ...
> application is supported."[/color]
Is it the OS, or perhaps an auxiliary tool like the version control
system or make utility? If the latter, those can be replaced. It
sounds suspiciously like this might be the case, since the requirement
is "unique within the first 14 characters", rather than cannot have
more than 14 characters.
[color=blue]
> "Main programs should be at the start of the file. Higher level
> subroutines should be below that, and the lowest level detail
> functions should be at the end of the file." and "All C functions
> should have function prototypes available in a header file."[/color]
The first is pretty much a pure style rule. The second is far more
important. Whenever possible, functions should be defined with the
static keyword for internal linkage. In that case, the prototypes for
all static functions must be at the top of the source file. All
functions with external linkage must have a prototype in a header
file. That header file must be included in the source file defining
the function as well as any other source files calling it. Function
prototypes are not allowed in source files unless they functions are
static.
In my company (medical equipment, possibility of direct injury as well
as misdiagnosis), where the current coding standards are largely my
doing, the extern keyword is not allowed to appear in a C source file.
They must have declarations in a header file, and like function
prototypes, the source code defining the external object must include
the header as well as other source files that reference it.
[color=blue]
> "Avoid calling system commands with the "system()" or "popen()"
> subroutines as they have a very high overhead."[/color]
This is a pretty meaningless statement. How many runtime functions do
you use that indirectly make system calls anyway?
[color=blue]
> "Each function starts with. a form feed (Control L) enclosed in a
> comment so that each function starts on a new page, i.e.; /* ^L */."[/color]
I thought this went away with dot-matrix printers, fan-fold paper, and
the 1980s. Still, the form feed character, Control L in ASCII, is
part of the basic source character set, so all conforming compilers
can deal with it.
I find this one pretty useless. Far, far better to use something like
Doxygen to generate readable documentation than this.
[color=blue]
> Additionally, an email has been sent to the committee from the
> organizing manager hinting that he favors adding the following (among
> other things):
>
> "we should explicitly ban the ternary operator"[/color]
I disagree with this one, although it can be abused and some
programmers will never grasp the distinction between appropriate and
inappropriate use. Chained ternary operators should be absolutely
forbidden.
[color=blue]
> "Please do not create structures that contain "char foo[12]" instead
> create "char *foo" when the string is to be used in structure ... {and
> use dynamic memory allocation instead}."[/color]
In truly high reliability systems, dynamic memory allocation is not
allowed at all. Using dynamic memory for small blocks can be very
troublesome, since large memory fragmentation can result. Of course
desktop/workstation applications can always be shut down and
restarted, and the box rebooted if necessary (especially if it on
Windows). Systems that absolutely must function 24/7 without shutdown
or reboot really can't afford dynamic memory at all.
And if those structures need to be copied, you run into all the issues
of shallow vs. deep copy and the possibility of the same pointer
getting freed twice.
[color=blue]
> Any thoughts would be appreciated!
>
> Earl Higgins[/color]
--
Jack Klein
Home:
http://JK-Technology.Com
FAQs for
comp.lang.c
http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++
http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html 
