473,327 Members | 2,094 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

why still use C?

no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.

i heard people say C++ is slower than C but i can't believe that. in pieces
of the application where speed really matters you can still use "normal"
functions or even static methods which is basically the same.

in C there arent the simplest things present like constants, each struct and
enum have to be prefixed with "struct" and "enum". iam sure there is much
more.

i don't get it why people program in C and faking OOP features(function
pointers in structs..) instead of using C++. are they simply masochists or
is there a logical reason?

i feel C has to benefit against C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 13 '05
687 22683
At Mon, 22 Dec 2003 11:00:34 -0600, "Douglas A. Gwyn" <DA****@null.net> writes:
"Kalle Olavi Niemitalo" <ko*@iki.fi> wrote in message
news:87************@Astalo.kon.iki.fi...
Type checks like this would be easier if the comma operator were
allowed in constant expressions.


Yes; that's an aggravating restriction.
The main argument for it seems to be to diagnose
int a[20,30];


A diagnostic for that declaration is required regardless of whether
commas are allowed in constant expressions. This is because a
direct-declarator (which is used to declare array types and their
bounds) must contain an assignment-expression, and
assignment-expressions must not contain a comma at the top level.
Seethe syntax in C99 section 6.7.5.

I think it's a good idea to have a diagnostic for that declaration, as
it's an understandably common error for C neophytes. But this issue
is independent of whether the comma operator should be allowed in
constant expressions.
Nov 14 '05 #651
In article <cl****************@plethora.net>,
CBFalconer <cb********@yahoo.com> wrote:
glen herrmannsfeldt wrote:
CBFalconer wrote:
glen herrmannsfeldt wrote:


(snip of base 1000 representation of decimal floating point)
>The normalization is done in uncompressed (BCD) form, and then
>they are converted to the base 1000 form for storage.

If you have ever designed a floating point package you will
realize that normalization takes up the majority of the time. It
needs to be simple, not a major base conversion.

Any reasonable form of decimal FP will be based on some flavor of
bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.


I haven't actually checked, but rumors are that it only takes a
few gates to convert between the base 1000 representation, and
BCD. It can be done while loading into registers, or even
as part of the ALU, itself.


If you show me (in detail) I will believe you. Not before.


The format is described at

http://www2.hursley.ibm.com/decimal/DPDecimal.html

It definitely looks simple enough to be done with a few logic gates.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #652
CBFalconer wrote:
I haven't actually checked, but rumors are that it only takes a
few gates to convert between the base 1000 representation, and
BCD. It can be done while loading into registers, or even
as part of the ALU, itself.


If you show me (in detail) I will believe you. Not before.


See: http://www2.hursley.ibm.com/decimal/DPDecimal.html

There are only two gate delays needed for the conversion (or three if
inverted signals are not available).

Mike Cowlishaw.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #653
Mike Cowlishaw wrote:
(snip of base 1000 representation of decimal floating point)
The normalization is done in uncompressed (BCD) form, and then
they are converted to the base 1000 form for storage.

If you have ever designed a floating point package you will
realize that normalization takes up the majority of the time. It
needs to be simple, not a major base conversion.

Any reasonable form of decimal FP will be based on some flavor of
bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.


I haven't actually checked, but rumors are that it only takes a
few gates to convert between the base 1000 representation, and
BCD. It can be done while loading into registers, or even
as part of the ALU, itself.


Correct. For details, see a summary at:

http://www2.hursley.ibm.com/decimal/DPDecimal.html


Thanks for the references. I am convinced as to the packing and
convertability, but offhand I don't think it solves the
normalization problem. It will still be necessary to normalize to
base 1000, or to convert to BCD and normalize to base 10, with the
effective loss of 4 to 10 bits of precision as compared to binary.

i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
is 1,000,000 while the minimum in binary is 2**29, or about
500,000,000. This is ameliorated by the need for less bits to
describe the exponent to cover the same magnitudes. We haven't
even considered the efficiency improvement of assumed leading 1
bits in binary.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #654
Mike Cowlishaw wrote:

(snip)
There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.


I still have never written a COBOL program, but is that fixed point or
floating point?

-- glen
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #655
CBFalconer wrote:
(snip)
Thanks for the references. I am convinced as to the packing and
convertability, but offhand I don't think it solves the
normalization problem. It will still be necessary to normalize to
base 1000, or to convert to BCD and normalize to base 10, with the
effective loss of 4 to 10 bits of precision as compared to binary.
One possibility is to store them in the registers in BCD.

Another is to convert to BCD, perform arithmetic operations, and
convert back to the packed form. This might be needed if the
same registers were used, and it was necessary not to enlarge
them. Though the Intel 80 bit registers should be big enough.
i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
is 1,000,000 while the minimum in binary is 2**29, or about
500,000,000. This is ameliorated by the need for less bits to
describe the exponent to cover the same magnitudes. We haven't
even considered the efficiency improvement of assumed leading 1
bits in binary.


The calculation I did some days ago included the hidden bit.

Or at least I meant it to. IEEE double is 53 bits, including the
hidden 1.

-- glen
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #656
>> There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.


I still have never written a COBOL program, but is that fixed point or
floating point?


'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is :-).

Mike
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #657
>>> (snip of base 1000 representation of decimal floating point)

> The normalization is done in uncompressed (BCD) form, and then
> they are converted to the base 1000 form for storage.

If you have ever designed a floating point package you will
realize that normalization takes up the majority of the time. It
needs to be simple, not a major base conversion.

Any reasonable form of decimal FP will be based on some flavor of
bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.

I haven't actually checked, but rumors are that it only takes a
few gates to convert between the base 1000 representation, and
BCD. It can be done while loading into registers, or even
as part of the ALU, itself.
Correct. For details, see a summary at:

http://www2.hursley.ibm.com/decimal/DPDecimal.html


Thanks for the references. I am convinced as to the packing and
convertability, but offhand I don't think it solves the
normalization problem. It will still be necessary to normalize to
base 1000, or to convert to BCD and normalize to base 10, with the
effective loss of 4 to 10 bits of precision as compared to binary.


Please explain the 'normalization problem' ... I have tried to
cover that in my FAQ but onviiously am lacking something.
i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
is 1,000,000 while the minimum in binary is 2**29, or about
500,000,000. This is ameliorated by the need for less bits to
describe the exponent to cover the same magnitudes. We haven't
even considered the efficiency improvement of assumed leading 1
bits in binary.


[I think your calculations are a bit off?]

Mike Cowlishaw
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #658
In article <cl****************@plethora.net>,
"Mike Cowlishaw" <mf*****@attglobal.net> wrote:
There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.


I still have never written a COBOL program, but is that fixed point or
floating point?


'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is :-).


As you say COBOL requires 32 decimal digits of precision. Would that be
_exactly_ 32 digits of precision or _at least_ 32 digits of precision? I
think producing _exactly_ 32 digits if what you have available is 34
digits could be difficult.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #659
On 23 Dec 2003 22:15:31 GMT
"Mike Cowlishaw" <mf*****@attglobal.net> wrote:
There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.


I still have never written a COBOL program, but is that fixed point
or floating point?


'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is
:-).

COBOL on some mainframes use true BCD arithmetic where each digit is
stored in a nybble with the sign usually taking up a nybble (I worked on
a mainframe where BCD numbers were nybble addresssable and the sign
could be either on the msb or lsb or absent. IBM mainframes, the sign is
in the low order nybble or the LSB. A number could have nearly any
precision and any number of decimal points since is was stored in
consecutive bytes. The hardware suppored this.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #660
>>>> There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.

I still have never written a COBOL program, but is that fixed point
or floating point?


'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is
:-).


As you say COBOL requires 32 decimal digits of precision. Would that
be _exactly_ 32 digits of precision or _at least_ 32 digits of
precision? I think producing _exactly_ 32 digits if what you have
available is 34 digits could be difficult.


I forget the actual wording. The final draft is on the web, somewhere,
if you want to check.

Mike Cowlishaw
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #661
"Mike Cowlishaw" <mf*****@attglobal.net> wrote
There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent. I still have never written a COBOL program, but is that fixed point
or floating point?
'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is
:-). As you say COBOL requires 32 decimal digits of precision. Would that
be _exactly_ 32 digits of precision or _at least_ 32 digits of
precision? I think producing _exactly_ 32 digits if what you have
available is 34 digits could be difficult.
I forget the actual wording. The final draft is on the web, somewhere,
if you want to check.


This precision requirement could be based on IBM's COBOL arithmetic, which
uses 30 or 31 decimal digits (I don't remember which) for all intermediate
results in fixed-point arithmetic expressions. If any floating-point
values are present in a given expression, the whole thing is done in
floating-point instead.

Anyway, 30 or 31 BCD digits plus a sign nibble fit quite naturally into
128 bits (16 bytes). IBM stipulated additional rules for handling gradual
loss of precision (i.e., truncation of least sigificant digits) for the
arithmetic operators, so that no high-order digits are lost (this differs
from PL/1 semantics).

It just so happens that IBM 360 (370, 390, etc.) hardware directly supports
signed BCD arithmetic of up to 31 digits (as do some other systems, e.g.
VAX).

-drt
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #662
David R Tribble wrote:
"Mike Cowlishaw" <mf*****@attglobal.net> wrote
There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent. I still have never written a COBOL program, but is that fixed point
or floating point? 'Standard' COBOL arithmetic. Calculate as well as possible and
then assign to a fixed-point variable. Best ask COBOL folk what
that is :-). As you say COBOL requires 32 decimal digits of precision. Would that
be _exactly_ 32 digits of precision or _at least_ 32 digits of
precision? I think producing _exactly_ 32 digits if what you have
available is 34 digits could be difficult.
I forget the actual wording. The final draft is on the web,
somewhere, if you want to check.


This precision requirement could be based on IBM's COBOL arithmetic,
which uses 30 or 31 decimal digits (I don't remember which) for all
intermediate results in fixed-point arithmetic expressions. If any
floating-point values are present in a given expression, the whole
thing is done in floating-point instead.

Anyway, 30 or 31 BCD digits plus a sign nibble fit quite naturally
into 128 bits (16 bytes). IBM stipulated additional rules for
handling gradual loss of precision (i.e., truncation of least
sigificant digits) for the arithmetic operators, so that no
high-order digits are lost (this differs from PL/1 semantics).

It just so happens that IBM 360 (370, 390, etc.) hardware directly
supports signed BCD arithmetic of up to 31 digits (as do some other
systems, e.g. VAX).


We're talking about COBOL 2002. This specifies 32-digit
intermediate results, not 31. (The conspiracy theorists suggest
that this is so that IBM BCD hardware cannot be used :-).)

mfc

-drt

--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #663
On 2003-10-12 18:49:40 -0400, Jerry Feldman <ga********@blu.orgsaid:
On 08 Oct 2003 05:35:19 GMT
"cody" <do*********************@gmx.dewrote:
>i though in standard C, there isn't such a thing like "const" you can
only use macros to fake them.
Maybe you should read the standard. The const keyword is certainly
defined, but it has a different meaning
than in C++. const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf = (int *)&foo;
*pf = x;
You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 9 '06 #664
Clark,

Comment/question below.
>const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 18 '06 #665
[mod note: I received something like 200 submissions of this post, and
there's no contact address for the author. This is the second or third time.
If I can't contact someone, I will happily just add mail filters to deal
with stuff like this. Be contactable. -mod]

Robert Seacord wrote:
Clark,

Comment/question below.
>>const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;
You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

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.
In that case you need to make sure you are compiling it as C code and
make sure you have told the compiler to follow the C standard. I don't
currently have my Windows notebook with me to test it myself since it
did not catch the same plain as me.
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.
The C standard does not mandate that programs fail to compile after
producing and required diagnostics (Warnings, Information messages,
Error, insults about your coding abilities, and of these could be issued
as a "diagnostic"). Also, once undefined behaviour is invoked, the
program is allowed to do anything. One of the infinitely many "any
things" it can do is exactly what you expect. However, tomorrow it might
not change the value of C, or after you upgrade the compiler the
behaviour might change (this does happen to people), or it might decide
to report you to the CIA for spying.
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.
At its simplest, a constraint violation is where the standard places a
constraint (limitation) on what you are allowed in your code, and you
violate that constraint in your code.
But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?
See above. Any form of "diagnostic" message is allowed, even something like:
Write out 1000 time "I will not write code with errors"
The compiler could even just fart in your general direction.

After issuing some form of message the compiler is allowed to continue
to compiler the program (although it does not matter what the program
then does) or reject the program.
--
Flash Gordon
Still sigless on this computer.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #666
Robert Seacord <rc*@sei.cmu.eduwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #667
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #668
On 2006-08-18 04:53:41 -0400, Robert Seacord <rc*@sei.cmu.edusaid:
Clark,

Comment/question below.
>>const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

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.
--
Clark S. Cox, III
cl*******@gmail.com
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #669
Robert Seacord wrote:
6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #670
"Robert Seacord" <rc*@sei.cmu.eduwrote in message
news:cl****************@plethora.net...
Clark,

Comment/question below.
>>const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

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.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #671
On 18 Aug 2006 08:53:41 GMT, in comp.lang.c , Robert Seacord
<rc*@sei.cmu.eduwrote:
>>
You are mistaken. You cannot legally do that in either language.
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #672
In comp.lang.c.moderated Robert Seacord <rc*@sei.cmu.eduwrote:
6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."
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.

--
Hans-Bernhard Broeker (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #673
On Fri, 18 Aug 2006 08:53:41 UTC, Robert Seacord <rc*@sei.cmu.edu>
wrote:
Clark,

Comment/question below.
const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;
You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

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!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #674
On 18 Aug 2006 08:53:41 GMT in comp.lang.c.moderated, Robert Seacord
<rc*@sei.cmu.eduwrote:
>Clark,

Comment/question below.
>>const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

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.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 25 '06 #675
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 31 '06 #676
Brian Inglis wrote:
On 18 Aug 2006 08:53:41 GMT in comp.lang.c.moderated, Robert Seacord
<rc*@sei.cmu.eduwrote:

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.
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 31 '06 #677
In comp.std.c ku****@wizard.net wrote:
>
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 31 '06 #678
"Malcolm" <re*******@btinternet.comwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 31 '06 #679
Brian Inglis wrote:
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Aug 31 '06 #680
la************@ugs.com wrote:
In comp.std.c ku****@wizard.net wrote:

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.
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."
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #681
la************@ugs.com writes:
In comp.std.c ku****@wizard.net wrote:
>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.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #682
la************@ugs.com wrote:
In comp.std.c ku****@wizard.net wrote:
>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.
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-linecauses 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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #683
la************@ugs.com wrote:
In comp.std.c ku****@wizard.net wrote:

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.
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #684
la************@ugs.com wrote:
In comp.std.c ku****@wizard.net wrote:
>>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
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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #685
fOn 31 Aug 2006 19:19:04 GMT in comp.lang.c.moderated, "Douglas A.
Gwyn" <DA****@null.netwrote:
>Brian Inglis wrote:
>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.
From:
http://groups.google.ca/group/comp.l...ed0a6d66938197

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/tran...io_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.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #686
Thanks for all your responses. If you would like to review and comment
on the "final" version of the secure coding rule I derived from all of
this please see:

https://www.securecoding.cert.org/co...onstant+values

Thanks,
rCs
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 18 '06 #687
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
[...]
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.
Correct, there's not.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Sep 22 '06 #688

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: William C. White | last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using cURL? Our website is hosted on a shared drive and the webhost company doesn't installed additional software (such as cURL)...
2
by: Albert Ahtenberg | last post by:
Hello, I don't know if it is only me but I was sure that header("Location:url") redirects the browser instantly to URL, or at least stops the execution of the code. But appearantely it continues...
3
by: James | last post by:
Hi, I have a form with 2 fields. 'A' 'B' The user completes one of the fields and the form is submitted. On the results page I want to run a query, but this will change subject to which...
0
by: Ollivier Robert | last post by:
Hello, I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9 system. The link succeeds but everytime I try to run php, I get a SEGV from inside the libcnltsh.so library. ...
1
by: Richard Galli | last post by:
I want viewers to compare state laws on a single subject. Imagine a three-column table with a drop-down box on the top. A viewer selects a state from the list, and that state's text fills the...
4
by: Albert Ahtenberg | last post by:
Hello, I have two questions. 1. When the user presses the back button and returns to a form he filled the form is reseted. How do I leave there the values he inserted? 2. When the...
1
by: inderjit S Gabrie | last post by:
Hi all Here is the scenerio ...is it possibly to do this... i am getting valid course dates output on to a web which i have designed ....all is okay so far , look at the following web url ...
2
by: Jack | last post by:
Hi All, What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g. select x from y where z=:parameter Which in asp/jsp would be followed by some statements to bind a value...
3
by: Sandwick | last post by:
I am trying to change the size of a drawing so they are all 3x3. the script below is what i was trying to use to cut it in half ... I get errors. I can display the normal picture but not the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.