why still use C?

[Keith Thompson]

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

C99 5.1.1.3p1:

A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior
is also explicitly specified as undefined or
implementation-defined. Diagnostic messages need not be produced
in other circumstances.

Footnote:

The intent is that an implementation should identify the nature
of, and where possible localize, each violation. Of course, an
implementation is free to produce any number of diagnostics as
long as a valid program is still correctly translated. It may also
successfully translate an invalid program.

So a compiler is allowed to produce a non-fatal warning in response to
a constraint violation.

 

[kuyper]

Robert Seacord wrote:
....

I lifted the following example from c99 6.5.16.1 Simple assignment:

const char **cpp;
char *p;
const char c = 'A';

printf("c = %c.\n", c);

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid

printf("c = %c.\n", c);

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

When a translation unit (TU) contains one or more constraint
violations, a diagnostic message is mandatory. That's the single most
important thing you need to know about constraint violations. It's
usually the case that when there's a constraint violation, the behavior
is undefined and the program is not strictly conforming (but I suspect
that there might be subtle cases where this isn't true). Therefore,
terminating translation of a TU is permitted. However, it's not
mandatory. The only case where the C standard prohibits an
implementation from translating a TU is if it contains a #error
directive which survives conditional compilation.
As a practical matter, changing the value of an object declared
constant is a problem only in two cases:
1. The implementation places the object in read-only memory.
2. The implementation makes optimizations based upon the assumption
that the value of the object can't change.

If neither of those cases applies, and the compiler chooses to
translate your program, and you choose to execute it, it might even
work as you might expect it to work. You shouldn't be surprised by that
result; but I would not recommend counting on it.

 

[Clark S. Cox III]

Clark,

Comment/question below.


I lifted the following example from c99 6.5.16.1 Simple assignment:

const char **cpp;
char *p;
const char c = 'A';

printf("c = %c.\n", c);

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid

printf("c = %c.\n", c);

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

rCs

Yes, according to 5.1.1.3:
"A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior is
also explicitly specified as undefined or implementation-defined.
Diagnostic messages need not be produced in other circumstances."

So, a conforming compiler has to at least produce a warning message
for the "cpp = &p" line. In this instance, gcc is conforming, VC++ is
not.

 

[Douglas A. Gwyn]

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

Yes, one form of "undefined behavior" is to go ahead and produce
some kind of result, which may or may not be what the programmer
naively was expecting.

Some compilers, such as those for embedded systems, may allocate
"const"-qualified objects in a read-only program section, which
in the final product might be burned into ROM. On more general-
purpose platforms, it is possible that read-only segments of a
task image might not have the "writable" bit set in the page
descriptors, in which case attempts to write to that storage
would result in an illegal-access trap (and probably task
termination).

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

A "constraint violation" is a violation of some requirement
specified in a subclaused entitled "Constraints".

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

Yes, constraint violations require a diagnostic.
However, the example was an instance of *undefined behavior*,
which is a different category of transgression.

 

[Malcolm]

Clark,

Comment/question below.


I lifted the following example from c99 6.5.16.1 Simple assignment:

const char **cpp;
char *p;
const char c = 'A';

printf("c = %c.\n", c);

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid

printf("c = %c.\n", c);

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

A compiler can accept anything and remain conforming. This is partly because
it is impossible to test that every contorted example of bad syntax will be
caught, parlty because so many compilers allow extensions.

Constraint violations are examples of "bad grammar". For instance assigning
an integer a pointer value. However often there is god reason for doing
this, because integers and pointers are often stored in exactly the same
registers, and it might be important to get the absolute value of a pointer,
for instance implementing a %p option in a printf-like function.

 

[Mark McIntyre]

I lifted the following example from c99 6.5.16.1 Simple assignment:

(snip example of constraint violation)

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005.

Thats a QOI issue, and may be because you didn't set VC into
"conforming mode". Most compilers come with lots of extensions to the
standard, and you need to turn them all off.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

Its obligated to do so, but only if in conforming mode.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Hans-Bernhard Broeker]

I guess I'm wondering what a constraint violation is.

[...]

Something that has less to do with undefined behaviour than you appear
to believe. That statement up there is crystal clear: modifying a
const-qualified object, by any means expressable in C, is as illegal
as anything in a C programming context can be: it causes undefined
behaviour.

But doesn't a compliant compiler need to issue a fatal diagnostic
for a constraint violation. Or maybe even a warning?

Of course it does. So all you've just demonstrated is that MS
compilers aren't compliant with the standard (at least not in the
operational modes you tested). That's hardly newsworthy.

 

[Herbert Rosenau]

Clark,

Comment/question below.


I lifted the following example from c99 6.5.16.1 Simple assignment:

No example will do against the standard.

Undefined behavior lives as undefined behavior ALWAYS.

There is nothing you can do against undefined behavior as avoid it
under all circumstances.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Brian Inglis]

Clark,

Comment/question below.


I lifted the following example from c99 6.5.16.1 Simple assignment:

const char **cpp;
char *p;
const char c = 'A';

printf("c = %c.\n", c);

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid

printf("c = %c.\n", c);

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

MS supports C89 and stated it has no intention of supporting C99.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

More recent versions of gcc (4+) have tightened up considerably on
what they will accept.

 

[kuyper]

Malcolm wrote:
....

A compiler can accept anything and remain conforming.

Not quite true: the one an only feature of a program that requires a
conforming implementation of C to reject it is a #error directive which
survives to the end of the pre-processing phase.

 

[SuperKoko]

MS supports C89 and stated it has no intention of supporting C99.

Even if this example is extracted from the C99 standard, this is a
constraint violation in C89 too! (in C89 there are additional
constraint violations for // comments).

So, if this compliance problem persists when all the ISO-compliance
flags are passed to the compiler, you can report a bug.

 

[lawrence.jones]

The only case where the C standard prohibits an
implementation from translating a TU is if it contains a #error
directive which survives conditional compilation.

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

-Larry Jones

What's the matter? Don't you trust your own kid?! -- Calvin

 

[Keith Thompson]

A compiler can accept anything and remain conforming. This is partly because
it is impossible to test that every contorted example of bad syntax will be
caught, parlty because so many compilers allow extensions.

That's *almost* true; a comforming compiler must reject a program that
contains a "#error" directive. The actual wording in the C99 standard
(4p4) is:

The implementation shall not successfully translate a
preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional
inclusion.

Constraint violations are examples of "bad grammar". For instance
assigning an integer a pointer value. However often there is god
reason for doing this, because integers and pointers are often
stored in exactly the same registers, and it might be important to
get the absolute value of a pointer, for instance implementing a %p
option in a printf-like function.

I think "grammar" is a poorly chosen word here. The grammar defines
the *syntax* of the language; in that sense, "bad grammar" would be
something like a missing semicolon or an extra parenthesis. I think
of constraint violations as a different class of errors. For example this:

int x = "foo";

is a constraint violation, but it doesn't violate the grammar.

 

[Douglas A. Gwyn]

MS supports C89 and stated it has no intention of supporting C99.

That's not what they have said; what they said was that they would
implement C99 features as customer demand warranted.

 

[kuyper]

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

4p4: "The implementation shall not successfully translate a
preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional
inclusion."

 

[Keith Thompson]

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

C99 4p4:

The implementation shall not successfully translate a
preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional
inclusion.

 

[Skarmander]

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

n1124, chapter 4, "Conformance": "The implementation shall not successfully
translate a preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional inclusion."

The diagnostic is covered in 6.10.5: "A preprocessing directive of the form
# error <pp-tokens_opt> <new-line> causes the implementation to produce a
diagnostic message that includes the specified sequence of preprocessing
tokens."

Technically an implementation is indeed not required to "terminate
translation", but that was not what was claimed; just that it was
"prohibit[ed] [...] from translating", which it is. An implementation could
continue translating and delete the output only at the end, for example.

S.

 

[Richard Bos]

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

In n1124.pdf, it's [4#4]:

# The implementation shall not successfully translate a preprocessing
# translation unit containing a #error preprocessing directive unless it
# is part of a group skipped by conditional inclusion.

I believe there's no similar clause in C89, though.

Richard

 

[jacob navia]

Chapter and verse, please? As far as I know, #error is only required to
produce a diagnostic, not terminate translation.

-Larry Jones

What's the matter? Don't you trust your own kid?! -- Calvin

The C standard 4.4 "Conformance"

The implementation shall not successfully translate a preprocessing
translation unit
containing a #error preprocessing directive unless it is part of a group
skipped by
conditional inclusion.

 

[Brian Inglis]

fOn 31 Aug 2006 19:19:04 GMT in comp.lang.c.moderated, "Douglas A.

That's not what they have said; what they said was that they would
implement C99 features as customer demand warranted.

From:
http://groups.google.ca/group/comp.lang.c/msg/faed0a6d66938197

I asked if MS has any plans to support C99 in the next VisualC. This
is their answer. I think we should whine more

We feel that C++ addresses this space sufficiently. In general we have
no plans to add any C99 features that duplicate functionality in C++
or conflict with it.

That also matches the feedback we have gotten from customers. In fact
the non interest in C99 is the clearest feedback I have seen of any
issue. The ratio of customers who don't want us to prioritize C99
features versus those who do is definitely higher than 100:1.

From:
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx

Q: There is one single C99 feature that has grasped my desire:
"varargs" macros. They rock! Will you be implementing these at some
point?
A: I happen to think there'll pretty cool as well. We haven't had a
lot of demand for varargs macros. We happen to have an extension
'__noop' which can be used for some of the same purposes varargs
macros are (debuging printf's).

Q: Follow-up on the C99 "varargs" question, what, if anything, from
C99 will we see in the future from VC
A: In general, we have seen little demand for many C99 features. Some
features have more demand than others, and we will consider them in
future releases provided they are compatible with C++. It is more
likely we'll entertain C99 features if they are picked up in the next
version of the C++ standard.

Q: keyword restrict?
A: We are definitely considering restrict.