B
Ben Pfaff
Joe Wright said:
Yes. Consider the new "inline" and "restrict" keywords, the
dropping of implicit int, and the disallowing of implicit
function declarations.
Yes. Consider the new "inline" and "restrict" keywords, the
dropping of implicit int, and the disallowing of implicit
function declarations.
M
Mark McIntyre
Just wait till you start working with programmers who grew up with
TRUE == -1. Then you;ll know what standardisation brings...
I should imagine anyone programming for PICs worries about this quite
a lot.
--
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
F
Frederick Gotham
I would have expressed it in terms of compile-constants. For instance:
#define MACRO !!(5 * 3 + 2 * (4 + 6) - 7)
becomes:
#define MACRO !!(5 * 3 + 2 * 10 - 7)
becomes:
#define MACRO !!(15 + 2 * 10 - 7)
becomes:
#define MACRO !!(15 + 20 - 7)
becomes:
#define MACRO !!(35 - 7)
becomes:
#define MACRO !!(28)
becomes:
#define MACRO !0
becomes:
#define MACRO 1
Therefore the following code should set a pointer to null:
#define MACRO !!(5 * 3 + 2 * (4 + 6) - 7)
int main(void)
{
char *p = ! MACRO;
}
#define MACRO !!(5 * 3 + 2 * (4 + 6) - 7)
becomes:
#define MACRO !!(5 * 3 + 2 * 10 - 7)
becomes:
#define MACRO !!(15 + 2 * 10 - 7)
becomes:
#define MACRO !!(15 + 20 - 7)
becomes:
#define MACRO !!(35 - 7)
becomes:
#define MACRO !!(28)
becomes:
#define MACRO !0
becomes:
#define MACRO 1
Therefore the following code should set a pointer to null:
#define MACRO !!(5 * 3 + 2 * (4 + 6) - 7)
int main(void)
{
char *p = ! MACRO;
}
K
Keith Thompson
Joe Wright said:
Certainly.
#include <stdio.h>
main(void) /* C99 removes implicit int */
{
int restrict = 5; /* restrict and inline are new keywords */
int inline = 10 //*
/* subtle effect of "//" comments */
restrict;
printf("inline = %d\n", inline);
return; /* C99 requires return <expr> for a non-void function */
}
I
Ian Collins
If you use restrict as an identifier, you might run into trouble on aRichard said:
POSIX system.
K
Keith Thompson
Mark McIntyre said:
That raises an interesting idea. If changing the definition of true
or TRUE from 1 to -1 makes your code behave differently, then your
code is probably broken.
If you never compare boolean values for equality, it shouldn't matter
what (non-zero) value you use for TRUE.
(It's acceptable to assume that relational, equality, "!", "&&", and
"||" operators always yield either 0 or 1, since the language
guarantees it, but I wouldn't necessarily want to write code that
depends on it; it could be taken as an invitation for the next
maintainer to assume that isdigit() always returns either 0 or 1.)
F
Frederick Gotham
Keith Thompson posted:
Indeed. The following should be fine and dandy:
#define TRUE -107
#define TRUE 5
Depends on the fact that "!", "&&" and "||" always yield 0 or 1.
or:
Depends on the fact that a particular function will always return 0
or 1.
If you're talking about the latter, then we're agreed.
If you're talking about the former, then I disagree, because I think it's
perfectly rational (heartwarming even) to rely on "!", "&&" and "||" to
either yield 0 or 1.
Even in C++, there's a guarantee that when a value of type "bool" is
converted to an integer type, that it either yields 0 or 1. This can be
exploited by changing code such as:
if (boolean_condition) ++counter;
into:
counter += boolean_condition;
Indeed. The following should be fine and dandy:
#define TRUE -107
#define TRUE 5
Depends on the fact that "!", "&&" and "||" always yield 0 or 1.
or:
Depends on the fact that a particular function will always return 0
or 1.
If you're talking about the latter, then we're agreed.
If you're talking about the former, then I disagree, because I think it's
perfectly rational (heartwarming even) to rely on "!", "&&" and "||" to
either yield 0 or 1.
Even in C++, there's a guarantee that when a value of type "bool" is
converted to an integer type, that it either yields 0 or 1. This can be
exploited by changing code such as:
if (boolean_condition) ++counter;
into:
counter += boolean_condition;
A
Al Balmer
You're allowed to look at some of the other 23 pages, as well ;-) You
would find that there are examples of his "softwares." And I think
sufficient indication that c.l.c readers have used some of them. Those
were the two questions asked. Nothing about writing books, or who he
has worked for, although the latter presumably indicates that someone
is using his "smart softwares."
In general, restricting your research to the first page of a Google
search is more likely to yield advertisements than enlightenment.
Of course. It's me that you seem to be annoyed with, for some reason.
Actually, I didn't even think you needed any enlightenment - but
"lovecreatesbeauty" might. (That's an awkward name. Do you suppose
he'd mind if I just call him lcb?)
A
Al Balmer
Why not? I had no indication that he had done that, and since I knew
the answers to lcb's questions were there, I had to assume that he had
not.
Why should I need enlightenment about Ben Pfaff? I have no doubt of
his ability to write "smart softwares", and no doubt that other people
have used them. But perhaps you could enlighten me as to why my
suggestion to lcb should annoy him so much.
Of course. I don't know why Ben brought up the subject of books, or
why he pointed out that writing (much of) a book did not make one an
expert. (Yes, I know that he contributed to the same book.)
R
Richard Heathfield
Al Balmer said:
I must be reading a different clc to you. I didn't read annoyance into Ben's
reply to you. Not even his second reply. I think you might be mistaken to
think Ben is annoyed at your suggestion.
No, on seconds thoughts, there is no question about it. I think you ARE
mistaken, and I was just trying to find a gentle way to phrase it!
I must be reading a different clc to you. I didn't read annoyance into Ben's
reply to you. Not even his second reply. I think you might be mistaken to
think Ben is annoyed at your suggestion.
No, on seconds thoughts, there is no question about it. I think you ARE
mistaken, and I was just trying to find a gentle way to phrase it!
K
Keith Thompson
Frederick Gotham said:
I wasn't talking about the latter; since I specifically mentioned the
relational, equality, "!", "&&", and "||" operators, I'm not sure why
you might think I was.
It's certainly allowed, and it's guaranteed by the standard to work
correctly. And I might actually do it myself if it were sufficiently
convenient.
But avoiding that kind of assumption makes for a simpler mental model
of how Boolean expressions work in C. Consistently using a model that
simply says "zero is false, non-zero is true" can make for simple and
reliable code. Extending that model to "zero is false, non-zero is
true, and for these specific operators true is always 1" can be either
useful or obfuscating; which it is will depend on both the author and
the reader.
Note that I didn't say above that I would *never* write code that
depends on those operators always yielding 0 or 1, merely that I
wouldn't necessarily do so. All else being equal, I prefer to stick
with the simpler (but incomplete) model -- but all else isn't always
equal.
A
Al Balmer
OK, maybe it's just too close to a 4-day holiday <g>. Sorry if I
ruffled anyone. Actually, I'm quite pleased to be in the same
communication space with both of you
L
lovecreatesbeauty
Frederick said:
The standard committee gave out an airy-fairy idea but can not give a
compiler realizing it on time. The coders have no choices and can not
follow an empty dream on time. Some people will say that making the
compilers comply with the latest standard document is not the duty of
the standard committee. Some powerful people will say, for example,
writing a compiler is rather easy and simple. Just ask yourself the
questions. Have you written a C99 compiler? Are you using a C99
compiler now? Is all of your code compliant with C99 standard? The C
standard committee comes up to maintain / control the language. Now
their users can not follow their footsteps.
lovecreatesbeauty
R
Richard Heathfield
lovecreatesbeauty said:
Not true. They produced a formal international standard.
That isn't the purpose of the committee.
The coders do have a choice. They can demand C99 from their vendors, or not
demand it. So far, they haven't demanded it, so not surprisingly the
vendors haven't supplied it.
I doubt it. The kind of people who can write a compiler know just how hard
it is to do so. And anyone else's opinion on the matter is of no
consequence.
Not true. They produced a formal international standard.
That isn't the purpose of the committee.
The coders do have a choice. They can demand C99 from their vendors, or not
demand it. So far, they haven't demanded it, so not surprisingly the
vendors haven't supplied it.
I doubt it. The kind of people who can write a compiler know just how hard
it is to do so. And anyone else's opinion on the matter is of no
consequence.
M
Malcolm
If you can alter the laguage specs to get round little difficulties, and youRichard Heathfield said:
don't worry too much about optimisation, writing a compiler is non-trivial,
but not an especially difficult project.
When you must adhere to a complex standard it becomes a lot harder, and it
is harder still to generate efficient code. I wouldn't willingly undertake
to write a C99 compliant compiler, even if I was paid for it, unless it was
a choice between that job or McDonald's.
S
santosh
Malcolm said:
I would think writing a C compiler is rather more difficult than more
"restricted" languages like Pascal, C# etc.
The complex expressions that can be constructed in C should probably
make the compiler's job quite complex.
On the other hand, I've heard, (though I don't to what extent it's
true), that the C++ compiler is an order of a magnitude more complex
than the one for C.
S
santosh
lovecreatesbeauty said:
Not at all. The C standard is a very realistic and pragmatic one; some
say too much so.
That's not the job of the Standard commitee, especially considering the
complexity of a C compiler and the number of platforms it supports.
No. C90 is completely implemented and even C99 is well supported on
many popular compilers. C is one of the most widely implemented
langauges, not an empty dream by any means.
And they are quite right.
Not everyone is competent enough to write their own compilers. It's
impossible for any one programmer. Besides excellent compilers for the
vast majority of the platforms are already available.
The users don't want to follow their footsteps, atleast not completely.
M
Mark F. Haigh
Richard Heathfield wrote:
I'm going to have to disagree again. I think the situation has become
much better in the last several years:
* GCC / Linux has much of C99 implemented, and is gradually improving.
* Sun Studio / Solaris 10 has C99 support.
* IBM VisualAge / AIX 5.3 has C99 support.
* HP compiler / HPUX 11 has C99 support.
* Portland Group / Win32/64 has C99 support.
* Comeau compiler / Dinkum C99 libs have C99 support.
* Intel C compiler has smatterings of C99.
Granted, you may not ever get C99 support from Microsoft or for C
compilers for smaller micros, but you can purchase a C99 development
environment for most current (non-embedded, non-RTOS,
non-microcontroller) platforms.
As of only 2 years ago the choices were much more stark. I think in 5
more years C99 will be much more available in the embedded space.
Mark F. Haigh
(e-mail address removed)
I'm going to have to disagree again. I think the situation has become
much better in the last several years:
* GCC / Linux has much of C99 implemented, and is gradually improving.
* Sun Studio / Solaris 10 has C99 support.
* IBM VisualAge / AIX 5.3 has C99 support.
* HP compiler / HPUX 11 has C99 support.
* Portland Group / Win32/64 has C99 support.
* Comeau compiler / Dinkum C99 libs have C99 support.
* Intel C compiler has smatterings of C99.
Granted, you may not ever get C99 support from Microsoft or for C
compilers for smaller micros, but you can purchase a C99 development
environment for most current (non-embedded, non-RTOS,
non-microcontroller) platforms.
As of only 2 years ago the choices were much more stark. I think in 5
more years C99 will be much more available in the embedded space.
Mark F. Haigh
(e-mail address removed)
A
Andrew Poelstra
<OT>
No one expects proper HTML, XHTML, or Javascript from Microsoft anymore;
neither does anyone expect a new operating system. (People expect XP with
a new GUI sometime around 2007, but other than that, Vista doesn't have a
lot of new features anymore). My point is that people are going to just
give up on Microsoft sooner than they'll get a conforming implementation of
/anything/,
</OT>
let alone C.
On the other hand, by 2010 GNU will likely have near-perfect C99 support, as
will plenty of other major compilers. At that point, Microsoft might wake up
and fix themselves. But maybe not.
The future isn't as grim as some make it out to be; all of the C99 features
that I personally would enjoy appear already to be in gcc, and from what I
hear, there are only one or two major vendors who won't compile code with
those features.
Of course, C89 certainly isn't broken, so C99 conformance isn't too much of
an actual issue.
W
websnarf
Frederick said:
Right, because C++ is a language in which there is active interest in
continuing to improve the language. From what I've read of the new C++
standard, the addition of "auto" alone seems to make the standard
update worth it.
Well, there are basically no C99 compilers and there is no demand from
users.
The value of the difference between C99 and C89 is basically
uncommunicatable to programmers. That's because the value of the
difference itself is so minor, and because programmers are more willing
to move in the direction of other languages than to invest more time in
learning subtle differences in the new standard.
C is a language whose problems are paramount and staring everyone in
the face. But C99 basically addresses none of these problems over C89.
The rise of the importance of cryptography as a field points out two
problems with the C language: 1) No simple way to express a high-word
multiply operation (even though the vast majority of CPU architectures
do support this with direct, and often highly accelerated hardware
support), and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement. The crypto community responds simply by
ignoring the standard and instead uses de facto standards (long is
exactly 32 bits, all integers are 2s complement, right shift retains
the sign of signed integers, etc.) C99 did not address this problem.
Java and Python do.
But the big elephant in the room is the extreme fragility of the C
language with respect to erroneous behaviour. The language is littered
with undefined behavior, and basically embodies buffer overflows as
practically standard usage. The standard library includes functions
that are not practically implementable in re-enterable ways (many of
these have been addressed in TR 24731 (and also in the latest
Bstrlib)). Any library function which takes multiple pointers assumes
no aliasing, otherwise leading to UB (which C99 did nothing but
reaffirm more explicitely through syntax). In very large programs with
standard programmer error rates, heap corruption is often undetected
and generally leads to anomolous behaviour that is hard to trace back
to its source. This leads to a standard condition called "bit rot"
(long running and large programs eventually just crash for "unknown
reasons"). Even simple things like a heap memory usage count for
detection of memory leaks are unavailable except via expensive and
platform specific tools.
C99 doesn't address these problems, though they are addressed by other
languages. As a counter to this point, it is commonly claimed that you
*NEED* to go to another language if you want these features. This is
ridiculous on its face, as it is very common to see these problems
solved in the C language in platform specific ways. Keep in mind that
the standard committee has significant representation by compiler
vendors. This is an important point, because we can see that the
standard was updated more with the needs of the compiler vendor in
mind, than users of those compilers.
C99 did add 1) complex numbers, but you can scan this newsgroup to give
you a rough idea of how relevant that is, 2) restrict, which is very
useful for some performance scenarios, except where the compiler can
internally deduce the attribute (which is actually quite common,
especially for compilers that support constant propagation) but more
commonly is just used as an unenforcable rubber stamp for the
assumption of no-aliasing in standard library functions, 3) variable
length arrays, which is just redundant with the common practice of
using the struct hack (why not just expand the standard to say that the
struct hack is not a violation of the standard?) 4) arbitrary
positioned variable declarations, which serves no relevant purpose
other than some typing convenience or cosmetic effect. Big changes to
the compilers that do not correspond to any real user need.
C99 also added curious neutral features: // comments and stdbool.h, for
example which you can take or not. I don't see the big deal either way
-- they are entirely cosmetic.
And then that are the actually useful things that were added: 1) More
precise floating point, 2) stdint.h (its not determinstic like Java,
but at least programmer can have some idea of what kind of integers
they can use), 3) va_copy, which was just an obvious missing function
which is the only possible way to iterate through a va_list in multiple
passes. Unfortunately, all these are generally addressed simply with
platform specific usage. I.e., you can just assume you have IEEE-754
FP (which most platforms support), you can just know what the integer
properties of your platform are, and on many systems, copying va_lists
can be done just with a direct = operation.
So as we can see, C99 just doesn't add enough useful stuff that people
need, whereas other programming languages do. So C99 just isn't
compelling to users.
Many compiler developers *started* moving towards C99 incorrectly
thinking that users would flock to C99 just as they did to C89. When
it became clear to them that users just couldn't possibly care less,
they simply stopped. The result is we have a number of compilers with
"half-way" support for C99 (technically meaning that they are actually
not compliant with *any* standard) but which will never be completely
compliant.
The most explicit demonstration of this is when Microsoft, aware of the
fierce competition for developer mindshare with gcc which seemed to be
moving in the direction of complete C99 support, openly declared they
would not support C99 due to non-existent developer demand. This had
all the earmarks of yet another MS PR fiasco -- gcc would get complete
C99 support, MS developers would balk and complain about the lack of
C99 support, and MS would be forced to backtrack and throw resources
into supporting C99. Of course none of this came to pass, and it
obviously never will (keep in mind that a very similar fiasco happened
to them regarding proper C++ support, and MS *was* forced to support
the correct their compiler to support the C++ standards.) In fact, MS
has so much contempt for C99, they are proposing changes to the next
standard (via TR 24731) without any commitment to supporting C99, even
though you would imagine it would be a technical prerequisite for
supporting their own proposals.