Is C99 the final C?

[Paul Hsieh]

(e-mail address removed) says...

Since we are talking about a binary input stream, use of ftell, some simple
arithmetic, and the contents of the buffer returned by fgets will provide
all the information you want.

ftell() is fine for files that are at most LONG_MAX bytes long. I.e., even if
you expect single lines the be less than LONG_MAX bytes in length, it doesn't
help if in total they exceed this limit.

As an alternative, compare this to something like what you find here:

http://www.azillionmonkeys.com/qed/userInput.html

There's no such issue in the function shown there.

 

[Paul Hsieh]

Paul Hsieh wrote:
... snip ...

IF this is a potential problem, you are allowed to build your
input around fgetc, getc, or even getchar.

Which kind of makes you wonder exactly what value the standard C library is
giving you. If this whole "ignore '\0'" feature of fgets() was a somehow
necessary or useful feature which one could easily map to a more general
solution there would be no issue. But its not.

 

[lawrence.jones]

Which kind of makes you wonder exactly what value the standard C library is
giving you. If this whole "ignore '\0'" feature of fgets() was a somehow
necessary or useful feature which one could easily map to a more general
solution there would be no issue. But its not.

You seem to have mistaken fgets() for a general-purpose input function.
It's not. It's intended to read lines from a text file. Text files
don't contain NULs. If you want to read arbitrary data and know for
sure how much you've read, use fread.

-Larry Jones

I'm a genius. -- Calvin

 

[Paul Hsieh]

You seem to have mistaken fgets() for a general-purpose input function.

Yes, just as I have mistaken the C language for a general purpose programming
language, and the standard library to be something which abstracts the machine
into useful primitives.

But its not just me. When a programmer wants input, they don't want to learn
about why fgets() ignores '\0' or why they have to write a convoluted loop over
malloced memory that still does it wrong.

Its not like having a good, reasonable performing, useful, consistent and
generic semantic was out of the reach of the people inventing this digital
diarrhea:

http://www.pobox.com/~qed/userInput.html

It's not. It's intended to read lines from a text file. Text files
don't contain NULs.

And this is enforced by what part of the standard? Is putting a '\0' into a
"text file" singled out as causing UB in the standard?

[...] If you want to read arbitrary data and know for sure how much you've
read, use fread.

Well there's a real valuable suggestion if ever I've heard one.

 

[Arthur J. O'Dwyer]

Which kind of makes you wonder exactly what value the standard C library is
giving you. If this whole "ignore '\0'" feature of fgets() was a somehow
necessary or useful feature which one could easily map to a more general
solution there would be no issue. But its not.

Maybe you think you've already explained what you mean elsethread,
but would you take the time again, please, to explain (1) what you
mean by "ignore '\0'" in the context of fgets(); and (2) why you
consider this (whatever it is) a problem in the context of C
programming? (I certainly don't understand what your reply to
CBFalconer means -- what do you mean by "map to a more general solution,"
particularly?)

In the interest of shortening this subthread, I will explain what
*I* think you mean by (1), and why (1) is not a problem in C.

fgets() reads characters input from a file until it hits either
'\n' or EOF, and stores these characters into a buffer. When fgets()
is done reading (having hit either '\n' or EOF), it terminates the
buffer with '\0', thus making a string that it returns to the user.
(It also stops reading input when so-and-so many characters have
been read, but that's irrelevant to what I think you're discussing.)
This behavior is perfectly good for dealing with text streams,
but can fail in the following way when used on binary streams:
Suppose the input stream contains a '\0' byte. fgets() reads that
byte, sees that it is not '\n' (and that no EOF condition has been
raised), and stores it in the buffer. Then it proceeds, reading
and storing characters until '\n' or EOF.
So, if the user sees that his buffer contains a string that's
not terminated with '\n', he is unsure of whether the terminating
'\0' is due to EOF in the stream, or the actual reading of a '\0'
byte. He can check feof() to find out whether the stream *is*
at EOF, but there still remains the possibility that the stream
hit EOF after reading one or more '\0's.

So the problem is not that fgets() "ignores" null characters in
the input stream; it's rather that fgets() does *not* perform any
special operations when confronted with one. Which is perfectly
reasonable, since text streams do not contain '\0', and binary
streams assign no interesting semantics to '\n' characters (or
sequences). That is, it is /a priori/ a silly idea to use fgets()
in any situation in which the above-mentioned ambiguity could
arise.
Even if a (possibly malicious) text stream *did* contain a
'\0' byte, how could fgets() possibly deal reasonably with it?
It couldn't treat it as a normal character, because that would
be ambiguous. It couldn't treat it as '\n', because that would
break the existing semantics of fgets(), which guarantee that
each complete line read end with the terminating '\n' (although
this might be the best "solution" behavior). And it couldn't
use any kind of escape sequence to represent '\0', because all
other bytes already have unambiguous semantics in the output
of fgets().

The solution, in a C-programming context, is to use fgets()
only on text streams, and on binary streams to use fread(), getc(),
or other functions that treat all bytes symmetrically (i.e., with
no special semantics involving '\n', '\0', or whitespace).
You have implied elsethread that you think this solution a
"non-solution" (or perhaps I'm again imagining sarcasm where
none was intended). If that's the case, would you mind explaining
what you think is wrong with getc() and fread() on binary streams?

-Arthur

 

[lawrence.jones]

But its not just me. When a programmer wants input, they don't want to learn
about why fgets() ignores '\0' or why they have to write a convoluted loop over
malloced memory that still does it wrong.

fgets does *not* ignore NULs, it reads them and stores them in the
buffer just as you'd expect. The "problem", if there is one, is that it
returns a string and C strings cannot contain NULs. That's not fgets's
fault, it the natural result of a design choice. Different string
representations have different plusses and minuses; nothing's perfect,
not even your suggested replacement.

And this is enforced by what part of the standard? Is putting a '\0' into a
"text file" singled out as causing UB in the standard?

No, but 7.19.2 makes it clear that there are many limitations to what a
text stream can portably contain. In all my years of programming, I
don't think I've ever needed to read lines of text that could contain
NULs. And for most of those years, I've known that if I did, I should
use getc to do so, not fgets.

[...] If you want to read arbitrary data and know for sure how much you've
read, use fread.

Well there's a real valuable suggestion if ever I've heard one.

Are you similarly dismissive of people who tell you to use a screwdriver
for driving screws rather than a hammer? If you insist on using the
wrong tool for the job, it's more than a little disingenuous to complain
about how badly designed it is.

-Larry Jones

When I want an editorial, I'll ASK for it! -- Calvin

 

[Mark McIntyre]

But its not just me.

Nor is it every programmer.

When a programmer wants input, they don't want to learn
about why fgets() ignores '\0' or why they have to write a convoluted loop over
malloced memory that still does it wrong.

*shrug*. You're right, but irrelevant. Every language has foibles, and
every programmer has to learn to live with them. You don't like C's
malloc? Use a different general purpose language. You don't like the
way that << works in C++? Choose Basic.

Its not like having a good, reasonable performing, useful, consistent and
generic semantic was out of the reach of the people inventing this digital
diarrhea:

Yeah, well you're designing an all singing-all dancing line reader. I
rarely if ever need that and so fgets() generally work just fine
without putting in all that dihorrea.

 

[Paul Hsieh]

(e-mail address removed) says...

[...] You have implied elsethread that you think this solution a
"non-solution" (or perhaps I'm again imagining sarcasm where
none was intended). If that's the case, would you mind explaining
what you think is wrong with getc() and fread() on binary streams?

getc() only reads a character (i.e., it reads too little), and fread() only
reads a buffer and ignores line terminators (i.e., it reads too much). That
leaves writing a loop over getc() as the only solution. But then one has to
wonder, why was fgets() included with its specific semantics, if its really
just a subset of a more general solution?

fgets() is the only string function which specifically ignores '\0'. A minor
change in its semantics would have made it more consistent with the rest of the
C language without any restriction of the file mode (return the length,
terminate on either '\0' or '\n' but always add an additional '\0' at the end)
which would have made it a *superset* of what we have today without any strange
conditions or anomolies.

The value of a library function should be how much it *saves* the programmer
from having to code themselves. In the context of the C language, you might
also have other criteria like being minimal, but I don't see that it would be
significantly larger to have implemented fgets with the semantics I suggest.

 

[Martien Verbruggen]

(e-mail address removed) says...

[...] You have implied elsethread that you think this solution a
"non-solution" (or perhaps I'm again imagining sarcasm where
none was intended). If that's the case, would you mind explaining
what you think is wrong with getc() and fread() on binary streams?

getc() only reads a character (i.e., it reads too little), and
fread() only reads a buffer and ignores line terminators (i.e., it
reads too much). That leaves writing a loop over getc() as the only
solution. But then one has to wonder, why was fgets() included with
its specific semantics, if its really just a subset of a more
general solution?

fgets was designed to read text lines into a string. A string, in C,
is a bunch of characters, terminated by a '\0'.

fgets() is the only string function which specifically ignores '\0'.

I haven't been able to find a post yet in which you specify exactly
what you mean by "ignores '\0'". Other people have already explained
that fgets() does not ignore embedded null characters in text files.
It neatly reads it in, and puts it in the buffer nominated. When you
then go ahead, and treat that buffer as a string, the first zero in
there will terminate the string, as the C language requires. The rest
of the stuff in the buffer just never is visible if you look at it as
a string.

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

#define MAXLEN 40

int main(void)
{
char buf[MAXLEN];

while (fgets(buf, MAXLEN, stdin))
{
size_t length = strlen(buf);
int i = 0;
while (i < MAXLEN && buf != '\n')
i++;
if (i == MAXLEN)
puts("No newline found");
else
printf("Found newline at %d\n", i);

printf("READ %d: %s", (int)length, buf);
if ( i != (int)length - 1)
putchar('\n');
}
return 0;
}

If you compile and run the above and feed it a "text" file with
embedded null characters on stdin, you'll notice that fgets() does not
"ignore" the null characters, and neither does it stop reading on a
null character. It merrily continues until the end of line, end of
file, an error condition, or until the buffer is full. As per
specification.

You'll also notice that the embedded null characters "confuse" tools
like strlen() and %s in printf(), because they (correctly) assume that
the first null character is the end of the string.

A minor change in its semantics would have made it more consistent
with the rest of the C language without any restriction of the file
mode (return the length, terminate on either '\0' or '\n' but always
add an additional '\0' at the end) which would have made it a
*superset* of what we have today without any strange
conditions or anomolies.

There are no anomalies. fgets() was meant to read text into a string.
If you want embedded '\0' characters, it is no longer a string (or
rather, the string ends where the first zero appears). If you want to
work with buffers that have zeroes in them, it is no longer a string,
and fgets isn't the right tool.

The value of a library function should be how much it *saves* the
programmer from having to code themselves. In the context of the C
language, you might also have other criteria like being minimal, but
I don't see that it would be significantly larger to have
implemented fgets with the semantics I suggest.

Well, Dennis Ritchie didn't implement fgets() with the semantics you
suggest, so fgets() as it is, is what we got. If you feel that another
function with other semantics is needed, you should probably take it
up with the folks in comp.std.c.

But none of that means that fgets() "ignores" '\0' characters.

What you seem to be saying instead is that you want fgets() to have a
different interface, and you probably should just get over that,
because it isn't going to happen.


I'd probably find it more fruitful to argue that the standard
explicitly uses the word "string" in the description for fgets(), to
avoid this sort of pointless argument.


Martien

 

[nrk]

(e-mail address removed) says...

[...] You have implied elsethread that you think this solution a
"non-solution" (or perhaps I'm again imagining sarcasm where
none was intended). If that's the case, would you mind explaining
what you think is wrong with getc() and fread() on binary streams?

getc() only reads a character (i.e., it reads too little), and fread()
only
reads a buffer and ignores line terminators (i.e., it reads too much).
That
leaves writing a loop over getc() as the only solution. But then one has
to wonder, why was fgets() included with its specific semantics, if its
really just a subset of a more general solution?

fgets() is the only string function which specifically ignores '\0'. A
minor change in its semantics would have made it more consistent with the
rest of the C language without any restriction of the file mode (return
the length, terminate on either '\0' or '\n' but always add an additional
'\0' at the end) which would have made it a *superset* of what we have
today without any strange conditions or anomolies.

The value of a library function should be how much it *saves* the
programmer
from having to code themselves. In the context of the C language, you
might also have other criteria like being minimal, but I don't see that it
would be significantly larger to have implemented fgets with the semantics
I suggest.

The problem can be overcome by filling the buffer passed to fgets with any
value other than 0, before passing it to fgets. Now you have a perfectly
fine way of finding out exactly how much of the buffer fgets wrote into.
Of course, judging by your rants so far, you'd be unsatisfied with this
solution as well. As they say where I come from, no point in trying to
wake up one who's pretending to be asleep.

-nrk.

 

[Randy Howard]

There are no C99 compilers, compliant or otherwise.

What would this mysterious thing be then?
http://www.comeaucomputing.com/
Furthermore, if it's not compliant, is it not then "otherwise"?

What a bizarre statement. gcc -std=c99 sure seems like it might
fall into that otherwise category, but much less so.

The Intel C compiler claims to also support C99, using the same
command line syntax (-std=c99).

Specifically:

The following C99 features are supported in this version of the Intel C++
Compiler when using the -c99[-] option:

Restricted pointers (restrict keyword, available with -restrict). See Note
below.
Variable-length Arrays
Flexible array members
Complex number support (_Complex keyword)
Hexadecimal floating-point constants
Compound literals
Designated initializers
Mixed declarations and code
Macros with a variable number of arguments
Inline functions (inline keyword)
Boolean type (_Bool keyword)

These features are not supported:

#pragma STDC FP_CONTRACT
#pragma STDC FENV_ACCESS
#pragma STDC CX_LIMITED_RANGE
long double (128-bit representations)

[end quote]


The Sun Forte Developer 7 C compiler appears to support some, but
certainly not all of C99. I guess that's another otherwise. Similar
comments about the Sun ONE Studio 8 compiler collection.

The Digital Mars C compiler claims to be pretty close, except for:
"While Digital Mars C strives to be fully compatible with C99, some
features remain unimplemented, for example:
New struct member initializer syntax
tgmath.h
_Pragma
"

The Cray C compiler supports C99 with the -h c99 option, including
VLA's and restricted pointers.

HP claims C99 support for both HP-UX and OpenVMS compilers.

The Acmet C cross-compilers claim C99 support.

The Compaq UPC Tru64 C compiler supports C99, including VLA's.

The Pelles C compiler for Windows and Pocket PC claims C99 support.

The OdinMP OpenMP C compiler is apparently supporting some, but not all
C99 feaures.

The "Jazillian" C to Java converter supports all C99 conforming code.

The Dignus C compiler for Z/Architecture (24, 31, 64-bit) supports C99
features.

Care to reconsider that incredibly broad statement?

 

[Irrwahn Grausewitz]

fgets() is the only string function which specifically ignores '\0'. A minor
change in its semantics would have made it more consistent with the rest of the
C language without any restriction of the file mode (return the length,
terminate on either '\0' or '\n' but always add an additional '\0' at the end)
which would have made it a *superset* of what we have today without any strange
conditions or anomolies.

fgets is *not* a string function, it's an input function. fgets is
used to read lines of characters from text streams. fgets is not used
to read C strings from binary streams. The only valid line terminator
in C text streams is '\n'. Everything else is to be considered part
of the line. For this reason fgets takes no special action on '\0'
characters, because they have no special meaning in text streams. [1]

IMNSHO a file containing '\0's is not a text file but a binary file,
and should be treated as such. If your text files contain spurious
NUL characters your files are broken, and you cannot blame fgets for
this.

Please reconsider the restrictive definition of text streams in the
standard:

ISO/IEC 9899:1999 7.19.2 Streams
2 A text stream is an ordered sequence of characters composed into
lines, each line consisting of zero or more characters plus a
terminating new-line character. [...] Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist
only of printing characters and the control characters horizontal
tab and new-line; no new-line character is immediately preceded by
space characters; and the last character is a new-line character.
Whether space characters that are written out immediately before
a new-line character appear when read in is implementation-
defined.

If you want a way to transparently write and read data, use ...
<drum-roll> ... binary streams and the corresponding functions

The value of a library function should be how much it *saves* the programmer
from having to code themselves.

And fgets has done a good job in the past, and I suspect that won't
change soon. Just use it for the purpose it's designed for and
everything's fine. For other purposes use other suitable library
functions. And if there is none available, write one.

In the context of the C language, you might
also have other criteria like being minimal, but I don't see that it would be
significantly larger to have implemented fgets with the semantics I suggest.

That's not the point. The point is that if fgets had the semantics
you propose, it would no longer be the library function for reading
lines from text streams, and a need for the_real_fgets() would arise.

It's not so damn hard to write five lines of C code to handle broken
text files, put it in your toolbox and be happy for the rest of your
life.


[1] I could well live with a fgets implementation that invokes
undefined behaviour if it hits a NUL chartacter in a text
stream.


Regards

 

[pete]

Paul Hsieh wrote:

fgets() is the only string function which specifically ignores '\0'.

fgets is a character input/output function.
The string functions are the ones which are prototyped in string.h

 

[breitkreutz_travis_o]

Once more I am trying to cut this monstrous thread up into
identifiable sub-threads, dealing with single subjects, and with
reasonably sized articles and subjects

Conceding the chicken and egg nature of the problem, all is solved
once we can provide exclusive access to something, which in turn
allows setting and clearing of flags for whatever scheme we
prefer. The one thing that C provides is atomic access to
objects. It seems to me that this suffices to implement Dekkers
algorithm, and thus implement critical sections. The solution may
not be efficient, but it is a solution, IMO.

The standard provides for atomic access through use of the type sig_atomic_t
in signal.h, which is "the (possibly volatile-qualified) integer type of an
object
that can be accessed as an atomic entity, even in the presence of
asynchronous
interrupts." (ISO/IEC 9899:1999, clause 7.14, p. 245.) However, the
standard also states that "[w]hat constitutes an access to an object that
has
volatile-qualified type is implementation-defined." (Ibid., clause 6.7.3,
p.
109.)

Read access on such an object is usually straightforward and is normally
done
in one atomic operation if the memory is on-chip. Write access, however,
may or may not be done in one operation. In either case, access is
hardware-
specific.

In short, there is no portable means of providing a mutex, at least not one
that
is completely reliable across all platforms.

Regards,

Travis

 

[Dan Pop]

What would this mysterious thing be then?
http://www.comeaucomputing.com/
Furthermore, if it's not compliant, is it not then "otherwise"?

It's neither, because it's not what people usually mean by compiler.
Its output is non-portable C89 code (C89 + the extensions of the target
C89 compiler).

What a bizarre statement. gcc -std=c99 sure seems like it might
fall into that otherwise category, but much less so.

The "otherwise" category is meaningless, because *anything* qualifies as
a non-compliant C99 compiler (except the compliant C99 compilers, of
course).

The Intel C compiler claims to also support C99, using the same
command line syntax (-std=c99).

The same command line syntax, but with different semantics. Nice, isn't
it?

Specifically:

The following C99 features are supported in this version of the Intel C++
Compiler when using the -c99[-] option:

Restricted pointers (restrict keyword, available with -restrict). See Note
below.
Variable-length Arrays
Flexible array members
Complex number support (_Complex keyword)
Hexadecimal floating-point constants
Compound literals
Designated initializers
Mixed declarations and code
Macros with a variable number of arguments
Inline functions (inline keyword)
Boolean type (_Bool keyword)

These features are not supported:

#pragma STDC FP_CONTRACT
#pragma STDC FENV_ACCESS
#pragma STDC CX_LIMITED_RANGE
long double (128-bit representations)

[end quote]

So, it's not a conforming C99 compiler.

The Sun Forte Developer 7 C compiler appears to support some, but
certainly not all of C99. I guess that's another otherwise. Similar
comments about the Sun ONE Studio 8 compiler collection.

The Digital Mars C compiler claims to be pretty close, except for:
"While Digital Mars C strives to be fully compatible with C99, some
features remain unimplemented, for example:
New struct member initializer syntax
tgmath.h
_Pragma
"

The Cray C compiler supports C99 with the -h c99 option, including
VLA's and restricted pointers.

HP claims C99 support for both HP-UX and OpenVMS compilers.

The Acmet C cross-compilers claim C99 support.

The Compaq UPC Tru64 C compiler supports C99, including VLA's.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The Pelles C compiler for Windows and Pocket PC claims C99 support.

The OdinMP OpenMP C compiler is apparently supporting some, but not all
C99 feaures.

The "Jazillian" C to Java converter supports all C99 conforming code.

The Dignus C compiler for Z/Architecture (24, 31, 64-bit) supports C99
features.

Care to reconsider that incredibly broad statement?

Remove the "otherwise", which renders the statement trivially false and
see how many *conforming* C99 compilers you can find. After that, start
considering the *conforming* C99 library issue.

Note that in vendor speak, C99 support is not the same as C99 conformance.
The best example is the underlined text above.

Dan

 

[Johan Aurer]

(e-mail address removed) says...

1) Write a program that takes input from stdin line by line using fgets(), and
accumulates the result into an MD5 hash.

2) Now redirect an arbitrary file into it (assuming UNIX or Windows-like
redirection facilities.)

Ok, first step, of course, is to reopen the stdin as binary. (If all this
seems hoakey to you, just open any file in which someone previous performed an
fwrite with some number of '\0' s in it instead.) But after that you discover
that its impossible to know for sure exactly how much data each fgets()
operations reads!

- strlen() is just plain wrong because earlier encountered '\0's don't
correspond to the where the first '\n' or bufferlength-1 is encountered.
- scanning for '\n' is insufficient on the very last line of the file because
it might really have early terminated by an earlier '\0'

In short, fgets() does not leave you with a deterministic way of knowing how
much data was really read unless you outlaw '\0' from the input stream.

OK, then tell me what's wrong with the program below. Give an example of a
specific sequence of input characters (containing null characters) that
will cause the program to incorrectly report the number of characters read
by fgets().

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int
main(void)
{
char buf[100];
size_t nchars;

while (1) {
memset(buf, 1, sizeof buf);

if (!fgets(buf, sizeof buf, stdin))
exit(0);

for (nchars = sizeof buf - 1; buf[nchars] != '\0'; nchars--)
;

printf("%d characters read...\n", (int)nchars);
}
}

 

[Simon J Fisher]

see Rule 36 of the MISTRAY-C C coding standard at
Http://mistray-c.phaedsys.org

It is the antidote to MISRA-C and should raise a smile or three.

I am looking for some code examples to illustrate some of the rules.

regards
Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Just read the "MISTRAY-C C coding standard". Loving your work there.

I think the right way to do things lies somewhere between MISRA and
MISTRAY. MISRA is a very good example of diktats generated by
'staffers' (as a Dilbert reader would understand) who spend time
trying to lecture those actually on the front lines on how to do their
jobs. One wonders if the people responsible for MISRA-C have done any
real projects for years.

But of course it's happily kept alive by those who profit from MISRA-C
"training courses", "compliance checking tools" and the like.

 

[Chris Hills]

Just read the "MISTRAY-C C coding standard". Loving your work there.

Thanks. That was a first pass. If any one has any examples of better
wording or source code examples let me know.

I think the right way to do things lies somewhere between MISRA and
MISTRAY. MISRA is a very good example of diktats generated by
'staffers' (as a Dilbert reader would understand) who spend time
trying to lecture those actually on the front lines on how to do their
jobs.

AFAIK ALL of the current MISRA-C team have mission/safety critical code
running out there somewhere.... I am not sure about all the first team.
I will have to research this and put a MISRA-C history in MISRA-C2

One wonders if the people responsible for MISRA-C have done any
real projects for years.

Yes. Most of us, in the the MISRA-C2 team, have/are writing code.
Mainly safety/mission critical but not all in the automotive world.

But of course it's happily kept alive by those who profit from MISRA-C
"training courses",

AFAIk the people who do the MISRA-C training are not involved with
development of MISRA-C.

"compliance checking tools" and the like.

They have become involved with the second edition of MISRA-C because of
the anomalies, inconsistencies etc of the first version.

MISRA-C2 is nearing completion.

IT is still based on 9899:1990 as there are no commercial embedded
compilers that are fully compliant to C99.

It has been reviewed not only by the usual MIRA circuit but has been
reviewed by the US SAE, the Japanese SAE, members of the ISO- committee,
most of the major C code testing tool vendors (including PC-Lint).

I hope that MISTA-C2 will be available at the end of Q1 2004 with
support from the checking tool vendors by end Q3.

The next area of work is likely to be a test suite and related items.
Also with any luck comp.lang.c.misra Note it will not be comp.std.c
because misra-c is NOT a language standard. It is a coding guideline.

Then I suppose it will be on to MISRA-C3 Though the team have said they
want a 6 month break first


Regards
Chris









/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Douglas A. Gwyn]

MISRA-C2 is nearing completion.
IT is still based on 9899:1990 as there are no commercial embedded
compilers that are fully compliant to C99.

As I recall, the original MISRA-C guidelines basically amounted to selecting
a subset of Standard C. That subset might as well be of C99+TC1, in fact
would be better if based on the International Standard rather than on some
obsolete document.

 

[Chris Hills]

As I recall, the original MISRA-C guidelines basically amounted to selecting
a subset of Standard C. That subset might as well be of C99+TC1, in fact
would be better if based on the International Standard rather than on some
obsolete document.

It is based on C90+TC & A1 which is still available. It was felt that
there was little point in doing it to C99 until the compiler vendors
started to support it.

We are looking at a few years yet before there are an appreciable number
of C99 embedded compilers out there much less any sizeable body of code
written to C99.

Many systems are not likely to get C99 compilers any time soon, if at
all.

The initial work on MISRA-C2 was to get rid of the anomalies, ambiguous
parts etc . It has gone further than that.

MISRA-C3 will go got C99+Tc etc. However that will be in about 4 or 5
years time.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/