So what Standard are we working off?

K

Keith Thompson

Richard Heathfield said:
I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

If you mean they *had* no business polluting the user namespace, I can
see your point, but the fact is they've already done so, and that bell
can't be unrung. Realistically, it's best to avoid using "restrict"
as an identifier; there's always the possibility that, some day in the
distant future, someone will want to compile your code with a compiler
that doesn't have a C90 mode.

I wouldn't avoid "new" and "class" in C code; C++ is a different
language. But C99 is a new version of the same language, and it just
might catch on.
 
K

Keith Thompson

Frederick Gotham said:
lovecreatesbeauty posted:


That's flawed, and I'll show you why:

int Func1() { return 5; }

int Func2() { return 1; }

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}

The flaw is in the misuse of the bool (or bool_t) type, not in its
definition. A logically true value in C is non-zero, not necessarily 1;
C99's _Bool and <bool.h> doesn't change that.
 
R

Richard Heathfield

Keith Thompson said:

I wouldn't avoid "new" and "class" in C code; C++ is a different
language. But C99 is a new version of the same language, and it just
might catch on.

Yes, it might, and so of course I /do/ avoid clashes in C90 code. I might
/think/ about using restrict as an identifier, but I don't actually do it.

(In fact, a few years ago I discovered that I had done precisely that, in a
program written before I'd ever heard of C99. Although that program has
never encountered a C99 compiler, I changed the code anyway. ISTR that I
used "constrain" instead.

But C0X people should bear in mind that our namespace is already crowded
enough, and should invade it no more.
 
A

Al Balmer

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.

No they don't, not even in C++. The best that many vendors claim even
now is "substantially compliant."
It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard, but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

For the same reasons that conformance to the C++ standard is not
immediate and universal. Take a minute and actually think about the
process.

Most compilers are getting up to the new standard gradually. Some
advertise it, and some don't, but every one of the several compilers I
work with has implemented sizable chunks of the C99 standard.
 
A

Al Balmer

Richard Heathfield wrote:

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.
 
B

Ben Pfaff

Al Balmer said:
Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.

Richard wrote (much of) a book on C. Does that make him an
expert?
 
K

Keith Thompson

lovecreatesbeauty said:
Richard said:
lovecreatesbeauty said:
[snip]
People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

(This was a response to something Richard wrote; see upthread for
context.)

I never said that anything or anyone was "stupid".

If you view VLAs as an alternative to malloc() (the only portable way
in C90 to do the equivalent kind of allocation), VLAs have the
disadvantage that there's no way to detect or handle an allocation
failure. If the system can't allocate enough memory, the behavior is
undefined. malloc() by contrast, safely returns a null pointer on
failure.

Yes, it's true that VLAs are just like ordinary objects in this sense;
there's not much difference between this:
int arr[1000000];
and this:
int len = 1000000;
int vla[len];
(apart from the latter being illegal in C90). The difference is that
a VLA can cause an allocation failure that depends on the value of a
variable at run time, perhaps on user input.

I'm not sure there's any good way to design VLAs that would eliminate
this problem. I suppose an allocation failure could cause &vla to be
NULL, but that's ugly. A generalized exception mechanism in which any
allocation failure of an automatic variable raises an exception that
can be handled by the function's caller would do the trick, but that
would be a major change to the language.

I'm not saying that VLAs shouldn't have been added to the language,
just that you have to be careful using them -- and sometimes being
careful isn't enough.
 
D

Default User

Frederick said:
If we look at a programming language such as C++: When an updated
Standard comes out, everyone adopts it and abandons the previous one.

This is a rather bogus description. C++ had its first standard approved
in 1998. Some years later, a technical corrigendum that mostly cleaned
up some stuff was approved, around 2003. This made no substantive
change to the language. The 1998 standard was in no way "abandoned" by
anyone. There is another in work now that will add some new library
features.

The 1999 C standard was a substantial revision over the 1990 one. The
situations are not comparable.




Brian
 
W

Walter Banks

Is there any reason that the following would not work?

if(!result1 == !result2) DoSomething();
 
R

Richard Heathfield

Walter Banks said:
Is there any reason that the following would not work?

if(!result1 == !result2) DoSomething();

None whatsoever. The !! retains the original Boolean sense of the result,
but what would the computer care about that? Computationally, your version
works just fine.
 
F

Frederick Gotham

Richard Heathfield posted:
Walter Banks said:


None whatsoever. The !! retains the original Boolean sense of the
result, but what would the computer care about that? Computationally,
your version works just fine.


I just hope the compiler wouldn't naively turn a sequence of two
exclamations marks into nothing... ?
 
R

Richard Heathfield

Frederick Gotham said:
Richard Heathfield posted:



I just hope the compiler wouldn't naively turn a sequence of two
exclamations marks into nothing... ?

It's allowed to do that only if the operand is 0 or 1, because !!0 is 0 and
!!1 is 1. If the operand has any other value, a conforming compiler must
honour the semantics.
 
K

Keith Thompson

Richard Heathfield said:
Keith Thompson said:


Yes, it might, and so of course I /do/ avoid clashes in C90 code. I might
/think/ about using restrict as an identifier, but I don't actually do it.

(In fact, a few years ago I discovered that I had done precisely that, in a
program written before I'd ever heard of C99. Although that program has
never encountered a C99 compiler, I changed the code anyway. ISTR that I
used "constrain" instead.

But C0X people should bear in mind that our namespace is already crowded
enough, and should invade it no more.

On the other hand, there's something to be said for a clean language
design. Assuming that the functionality of "restrict" is something
worth having in the language, I can't think of a cleaner way to
specify it than with a new keyword. (It could have been "_Restrict",
I suppose.)

Or they could have invented yet another meaning for "static". :cool:}

There's always a conflict between (a) preserving existing code, and
(b) adding new features using the clean syntax they would have had if
they'd been in the language in the first place. I'm certainly
sympathetic to both needs. In the case of "restrict", I tend to think
that breaking the small amount of code that used it as an identifier
wasn't too high a price to pay.

In the case of "bool", the committee chose to add "_Bool" as a
keyword, and put the "bool", "true", and "false" identifiers in a new
predefined header. Since the new identifiers are already in common
use, I think that was a good choice -- though of course it wouldn't
have been done that way in the first place.
 
K

Keith Thompson

Richard Heathfield said:
Frederick Gotham said:

It's allowed to do that only if the operand is 0 or 1, because !!0 is 0 and
!!1 is 1. If the operand has any other value, a conforming compiler must
honour the semantics.

Specifically, it's allowed to do so only if it can prove at
compilation time that 0 and 1 are the only possible values at run
time. (In proving this, it's allowed to assume that there's no
undefined behavior.)
 
A

Al Balmer

Richard wrote (much of) a book on C.

If you try the search, you'll find sufficient information to answer
"lovecreatesbeauty"s questions.
Does that make him an
expert?

I rather doubt it. I've never seen anyone become an expert by writing
a book, though I'm sure it's a learning experience. Sometimes experts
do write books, though.
 
B

Ben Pfaff

Al Balmer said:
If you try the search, you'll find sufficient information to answer
"lovecreatesbeauty"s questions.

I did do the search. I found out that Richard wrote C Unleashed
and has written software for various companies. Nothing on the
first page of results led me to the kind of "enlightenment" you
speak of.

But Richard is smart and knowledgeable about C, and I have
nothing against him, of course. It's just the search results you
speak of that I find unenlightening. This is off-topic, so I'll
drop it here.
 
R

Richard Heathfield

Al Balmer said:
If you try the search,

Um, you're telling this to Ben?!?!?
you'll find sufficient information to answer
"lovecreatesbeauty"s questions.

And if you try Googling for "ben pfaff" "richard heathfield" you might find
some enlightenment of your own.
I rather doubt it. I've never seen anyone become an expert by writing
a book, though I'm sure it's a learning experience. Sometimes experts
do write books, though.

And sometimes they write parts of books.
 
J

Joe Wright

Keith said:
I have a PDF copy of the final C90 standard, and yes, it appears to be
scanned from dead trees, and it has no PDF bookmarks. I can
copy-and-paste from it, but the result looks like this:

4 Compliance

A srr-icr!\ corlfornri~~ PWJXI?U~~ shall use only those features
of the language and library specified in this International
Standard It shall not produce output dependent on any unspecitied.
undefined. or implementation-detined behavior. and shall not
exceed any minimum implementation limit

Actually it's not usually that bad (there seems to be a problem with
italics), but I do get a lot of errors involving characters that look
similar (',' vs. ',', 't' vs 'f', etc.). I usually clean things up
when I post them here. (Actually, I usually copy-and-paste from n1124
instead.)
Is there a case where a correct C90 program cannot be successfully
compiled by a C99 compiler? Actually this is not a compiler question but
a language one. Is there anything in C90 that C99 must reject or handle
differently?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,188
Messages
2,571,002
Members
47,591
Latest member
WoodrowBut

Latest Threads

Top