CERT C Secure Coding Standard - last call for reviewers

[CBFalconer]

"Doesn't ever" is too strong -- the whole point of standard
platform ABIs and run-time libraries is to allow different
compilers' object code to be linked together and work. It's
another lesson that Microsoft has been very slow to learn, but it
works just dandy in lots of other environments (like VMS, Unix,
and MVS/ESA). One of my company's main products is written in a
combination of C, C++, and Fortran, compiled by two or three
different compilers, all linked together into a single executable.
It works just fine on all major current platforms. That's not to
say that it's *easy* -- there are lots of potential traps and
pitfalls -- but it can be done.

Actually, for once, I don't think this is to be blamed on MS. The
x86 chips have had a long history, and a wide performance span, and
have never really had a consistent system for which to design
libraries, calling sequences, etc. Even their opcodes have been
heavily modified. Remember, the family is already over 30 years
old.

 

[Ben Bacarisse]

Keith Thompson wrote, On 22/03/08 00:48:

Flash Gordon wrote:
jacob navia wrote, On 21/03/08 21:47: [...]
Well, they are accepted

double _Complex a,b;
// ...
a = a+b;

If my compiler uses operator overloading to implement that,
it complies with the AS IF rule, as far as I see.
Ah, but does it still work and produce all required diagnostics if
you put it in standard compliant mode? I seem to recall that for
operator overloading you use a syntax that in standard compliant
mode requires a diagnostic (not that there is anything wrong with
extensions that require a diagnostic in standard compliant mode).
1) During compilation of tgmath.h I put the compiler in non-compliant
mode even if you requested the contrary. After compiling that, I
reset it again, the AS IF rule is then followed. Unless you
modify tgmath.h what is not a good idea.

Not a bad approach. Standard headers absolutely don't have to be
written in standard-conforming C (they don't have to be written in C,
or even exist as files).

<snip>

I agree with Keith that there is absolutely nothing wrong with this
approach.

That is fine for standard headers, but what about the user's program?
As far I can see, operator overloading is needed for complex numbers
to work at all. Maybe I've got this wrong, but it looks that way.

Jacob, if you are interested I will post bug reports to
comp.compilers.lcc. I would be very pleased to see another
C99-conforming compiler.

 

[Flash Gordon]

Ben Bacarisse wrote, On 22/03/08 16:42:

Keith Thompson wrote, On 22/03/08 00:48:

Flash Gordon wrote:
jacob navia wrote, On 21/03/08 21:47:
[...]
Well, they are accepted

double _Complex a,b;
// ...
a = a+b;

If my compiler uses operator overloading to implement that,
it complies with the AS IF rule, as far as I see.
Ah, but does it still work and produce all required diagnostics if
you put it in standard compliant mode? I seem to recall that for
operator overloading you use a syntax that in standard compliant
mode requires a diagnostic (not that there is anything wrong with
extensions that require a diagnostic in standard compliant mode).
1) During compilation of tgmath.h I put the compiler in non-compliant
mode even if you requested the contrary. After compiling that, I
reset it again, the AS IF rule is then followed. Unless you
modify tgmath.h what is not a good idea.
Not a bad approach. Standard headers absolutely don't have to be
written in standard-conforming C (they don't have to be written in C,
or even exist as files).

<snip>

I agree with Keith that there is absolutely nothing wrong with this
approach.

That is fine for standard headers, but what about the user's program?
As far I can see, operator overloading is needed for complex numbers
to work at all. Maybe I've got this wrong, but it looks that way.

Yes, it relies on operator overloading. I suspect the standards mode
doesn't disable overloaded definitions that are already set up, only
prevents further definitions from being added. Since a conforming
program cannot tell that it is a "user defined" overloaded operator
making things work and the user still cannot define his/her own
overloaded operators, this is fine.

Jacob, if you are interested I will post bug reports to
comp.compilers.lcc. I would be very pleased to see another
C99-conforming compiler.

I don't believe a bug report is needed for this as I don't believe it is
a bug.

 

[Keith Thompson]

What does it mean "to define _Complex_I in portable C"? Can
you define 1.0L in portable C?

_Complex_I is a macro, and it has to expand to some expression. My
question is whether it's possible to write that expression portably.

It's somewhat similar to the situation with the offsetof() macro,
except that offsetof() is typically written using only standard C
constructs, but in a non-portable way.

1.0L isn't a macro; it's already a portable standard C expression.

 

[Keith Thompson]

Keith Thompson wrote, On 22/03/08 00:48:

Flash Gordon wrote:
jacob navia wrote, On 21/03/08 21:47:
[...]
Well, they are accepted

double _Complex a,b;
// ...
a = a+b;

If my compiler uses operator overloading to implement that,
it complies with the AS IF rule, as far as I see.
Ah, but does it still work and produce all required diagnostics if
you put it in standard compliant mode? I seem to recall that for
operator overloading you use a syntax that in standard compliant
mode requires a diagnostic (not that there is anything wrong with
extensions that require a diagnostic in standard compliant mode).
1) During compilation of tgmath.h I put the compiler in non-compliant
mode even if you requested the contrary. After compiling that, I
reset it again, the AS IF rule is then followed. Unless you
modify tgmath.h what is not a good idea.

Not a bad approach. Standard headers absolutely don't have to be
written in standard-conforming C (they don't have to be written in C,
or even exist as files).

<snip>

I agree with Keith that there is absolutely nothing wrong with this
approach.

That is fine for standard headers, but what about the user's program?
As far I can see, operator overloading is needed for complex numbers
to work at all. Maybe I've got this wrong, but it looks that way.

C already has restricted operator overloading, though it doesn't make
it available to user code. For example, "+" can be applied to any
arithmetic type, or to an integer and a pointer. User programs just
can't define their own new overloadings.

If an implementation supports user-defined overloading as an
extension, and uses that extension to implement the language-defined
operators on complex types, I see no fundamental conformance problem
with that -- as long as any attempts to declare overloaded functions
outside the system headers are diagnosed.

Jacob, if you are interested I will post bug reports to
comp.compilers.lcc. I would be very pleased to see another
C99-conforming compiler.

Good luck with that. A good attitude regarding bug reports is very
important.

 

[jacob navia]

Jacob, if you are interested I will post bug reports to
comp.compilers.lcc. I would be very pleased to see another
C99-conforming compiler.

Yes, that would be nice. I am interested in fixing my bugs of
course, and my compiler *is* very important to me. Just tell me
what you see it doesn't work.

Thanks in advance.

 

[Keith Thompson]

Yes, that would be nice. I am interested in fixing my bugs of
course, and my compiler *is* very important to me. Just tell me
what you see it doesn't work.

Thanks in advance.

A refreshing attitude! (Seriously.)

 

[Ben Bacarisse]

Ben Bacarisse wrote, On 22/03/08 16:42:

Keith Thompson wrote, On 22/03/08 00:48:
Flash Gordon wrote:
jacob navia wrote, On 21/03/08 21:47:
[...]
Well, they are accepted

double _Complex a,b;
// ...
a = a+b;

If my compiler uses operator overloading to implement that,
it complies with the AS IF rule, as far as I see.
Ah, but does it still work and produce all required diagnostics if
you put it in standard compliant mode? I seem to recall that for
operator overloading you use a syntax that in standard compliant
mode requires a diagnostic (not that there is anything wrong with
extensions that require a diagnostic in standard compliant mode).
1) During compilation of tgmath.h I put the compiler in non-compliant
mode even if you requested the contrary. After compiling that, I
reset it again, the AS IF rule is then followed. Unless you
modify tgmath.h what is not a good idea.
Not a bad approach. Standard headers absolutely don't have to be
written in standard-conforming C (they don't have to be written in C,
or even exist as files).
<snip>

I agree with Keith that there is absolutely nothing wrong with this
approach.

That is fine for standard headers, but what about the user's program?
As far I can see, operator overloading is needed for complex numbers
to work at all. Maybe I've got this wrong, but it looks that way.

Yes, it relies on operator overloading.

But as far as I can see, that means you can't turn on "standards mode"
(the -ansic flag) with any complex number programs. This, in turn,
means that other valid programs are rejected because of the
extensions. It seems that:

int main(void)
{
double _Complex x = 1.0;
return 0;
}

is rejected by lcc-win32. Adding #include <complex.h> allows it to
compile, but it is still rejected if -ansic is specified. For more
details see my post in comp.compilers.lcc.

I suspect the standards mode
doesn't disable overloaded definitions that are already set up, only
prevents further definitions from being added. Since a conforming
program cannot tell that it is a "user defined" overloaded operator
making things work and the user still cannot define his/her own
overloaded operators, this is fine.


I don't believe a bug report is needed for this as I don't believe it
is a bug.

How can you say "this" does not need one? I may have it all wrong,
but you seem to be guessing at what I think the bug is since I have
not reported one yet!

 

[Ben Bacarisse]

If an implementation supports user-defined overloading as an
extension, and uses that extension to implement the language-defined
operators on complex types, I see no fundamental conformance problem
with that -- as long as any attempts to declare overloaded functions
outside the system headers are diagnosed.

That is my point. It seems to me that proviso is missing in
lcc-win32. I have posted some examples to comp.compilers.lcc.

 

[Flash Gordon]

Ben Bacarisse wrote, On 23/03/08 02:04:

Ben Bacarisse wrote, On 22/03/08 16:42:

Keith Thompson wrote, On 22/03/08 00:48:
Flash Gordon wrote:
jacob navia wrote, On 21/03/08 21:47:
[...]
Well, they are accepted

double _Complex a,b;
// ...
a = a+b;

If my compiler uses operator overloading to implement that,
it complies with the AS IF rule, as far as I see.
Ah, but does it still work and produce all required diagnostics if
you put it in standard compliant mode? I seem to recall that for
operator overloading you use a syntax that in standard compliant
mode requires a diagnostic (not that there is anything wrong with
extensions that require a diagnostic in standard compliant mode).
1) During compilation of tgmath.h I put the compiler in non-compliant
mode even if you requested the contrary. After compiling that, I
reset it again, the AS IF rule is then followed. Unless you
modify tgmath.h what is not a good idea.
Not a bad approach. Standard headers absolutely don't have to be
written in standard-conforming C (they don't have to be written in C,
or even exist as files).
<snip>

I agree with Keith that there is absolutely nothing wrong with this
approach.
That is fine for standard headers, but what about the user's program?
As far I can see, operator overloading is needed for complex numbers
to work at all. Maybe I've got this wrong, but it looks that way.

Yes, it relies on operator overloading.

But as far as I can see, that means you can't turn on "standards mode"
(the -ansic flag) with any complex number programs. This, in turn,

Jacob said you can and I had no reason to disbelieve him not having his
compiler.

means that other valid programs are rejected because of the
extensions. It seems that:

int main(void)
{
double _Complex x = 1.0;
return 0;
}

is rejected by lcc-win32. Adding #include <complex.h> allows it to
compile, but it is still rejected if -ansic is specified. For more
details see my post in comp.compilers.lcc.

OK, then there is a reason.

How can you say "this" does not need one? I may have it all wrong,
but you seem to be guessing at what I think the bug is since I have
not reported one yet!

I had believed what Jacob said which was that it would work in standards
compatible mode. Obviously as you have demonstrated it does not a bug
report is appropriate.

The method Jacob said of enabling extensions within his headers is
perfectly valid and *could* be made to work transparently. All it needs
is that the overloading defined in his headers is not lost when
standards mode is re-enabled at the end of the header, and I had assumed
that this was what Jacob did.

 

[jacob navia]

The method Jacob said of enabling extensions within his headers is
perfectly valid and *could* be made to work transparently. All it needs
is that the overloading defined in his headers is not lost when
standards mode is re-enabled at the end of the header, and I had assumed
that this was what Jacob did.

I had just forgotten to write
#pragma extensions(push,on)
....
#pragma extensions(po)

in complex.h now it works.

 

[Antoninus Twink]

CBFalconer said:


Those who have nothing to say should say nothing, and those who breach
netiquette guidelines should stop doing so before preaching netiquette to
others.

Miaow! Ladies, please, put down your handbags.

<usual irritatingly pompous vacuities snipped>

 

[Antoninus Twink]

Chuck,

Consider me told. I have seen your message I have read your links
save the off topic posts that everyone else has to endure. If
you must tell me do so privately. I will arrange for my filters to
ignore the messages and you will get the satisfaction of pointing
out a wrong and the rest of the newgroup will not endure endless
off topic threads whose subject line doesn't fit the message
of top vs bottom vs 4 line signature (yours is 9 btw).

Falconer is a hypocrite and a troll. No one in this group takes him
seriously - just ignore his prissy net-nannying.

 

[Ben Bacarisse]

I had just forgotten to write
#pragma extensions(push,on)
...
#pragma extensions(po)

"pop", here I think.

in complex.h now it works.

This does not do it for me.

 

[Ben Bacarisse]

Ben Bacarisse wrote, On 23/03/08 02:04:

I had believed what Jacob said which was that it would work in
standards compatible mode.

Yes, so had I. I should have made it plain at the start that I had
believed him until I saw evidence to the contrary.

Obviously as you have demonstrated it does
not a bug report is appropriate.

The method Jacob said of enabling extensions within his headers is
perfectly valid and *could* be made to work transparently. All it
needs is that the overloading defined in his headers is not lost when
standards mode is re-enabled at the end of the header, and I had
assumed that this was what Jacob did.

It is not quite that simple. A file can use complex numbers and not
include any header files[1], so the overloading, if it is needed for
complex numbers to work, must be there in programs that never see
complex.h[1, again]. It was this thought that made me look to see if
it had been done in the right way.

This is, in part, the point made earlier by Keith Thompson -- that C
already has operator overloading for arithmetic and extending that
using compiler extensions as a way to implement _Complex is perfectly
valid. I agree, but it must, of course, be done in a way that
conforms to the standard. My objection was purely practical -- it
seems that Jacob has not covered all the bases yet[1, yet again].

[1] I think this is true. I feel out on a limb here because I am not
an expert in complex number support in C99.

 

[jacob navia]

"pop", here I think.


This does not do it for me.

Yes, I did not told you to eliminate
#ifndef __ANSIC_ONLY

To avoid this bugs I sent you the include file
in comp.lang.lcc

Thanks for your help Mr Becarisse

 

[Flash Gordon]

Ben Bacarisse wrote, On 23/03/08 13:14:

It is not quite that simple. A file can use complex numbers and not
include any header files[1], so the overloading, if it is needed for
complex numbers to work, must be there in programs that never see
complex.h[1, again]. It was this thought that made me look to see if
it had been done in the right way.

[1] I think this is true. I feel out on a limb here because I am not
an expert in complex number support in C99.

I'm not an expert on it either (I don't need it for my current work) and
I had not thought of that. Yes, it does sound like more work might be
involved for Jacob.

 

[Nick Keighley]

A refreshing attitude!  (Seriously.)

me too!

 

[Richard]

Chuck,

Consider me told. I have seen your message I have read your links
save the off topic posts that everyone else has to endure. If
you must tell me do so privately. I will arrange for my filters to
ignore the messages and you will get the satisfaction of pointing
out a wrong and the rest of the newgroup will not endure endless
off topic threads whose subject line doesn't fit the message
of top vs bottom vs 4 line signature (yours is 9 btw).

Regards,

w..

Ignore "Chuck". He's considered to be a bit of a joke here. He is wrong
more often he is right and his group policing and net nannying make him
look like the hypocrite and the fool he is when you consider the fact
that he is STILL posting with a double signature.

You are better off killfiling him and be done with it.

 

[ymuntyan]

me too!

If you were really interested, you would read comp.compilers.lcc.
For example, here's a "bug report", reaction to which so surprised
poor Keith:
http://groups.google.com/group/comp...read/thread/4a7bcd24bc1cf0f7/36e1c1a6330af3f8
Read the program text in the "bug report" and then talk
about attitudes (do read it, all of it, and understand
what it's doing, and try to guess why it was written).

In the same newsgroup you can see Jacob reaction to real
bug reports too. You guys are jerks, you won't understand
that some people don't feel like being polite robots when
get insulted or humiliated (it's funny to see how old wise
Keith acts like a child in such a situation, and yet talks
about "attitude" and shit). Temper, temper, huh?

Yevgen