So what Standard are we working off?

[Frederick Gotham]

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

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?

--

Frederick Gotham

[Walter Banks]

Is there any reason that the following would not work?

if(!result1 == !result2) DoSomething();
Richard Heathfield wrote:

No, you can do:

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

[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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Richard Heathfield posted:

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.

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

Frederick Gotham

[Richard Heathfield]

Frederick Gotham said:

Richard Heathfield posted:

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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> writes:

Keith Thompson said:
<snip>

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.

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". 8-)}

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.

--
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.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> writes:

Frederick Gotham said:

Richard Heathfield posted:

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.

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.

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.)

--
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.

[Al Balmer]

On Fri, 30 Jun 2006 10:25:08 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:

On 30 Jun 2006 07:28:33 -0700, "lovecreatesbeauty"
<lo***************@gmail.com> 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.

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.

--
Al Balmer
Sun City, AZ

[Richard Heathfield]

Al Balmer said:

On Fri, 30 Jun 2006 10:25:08 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:
<snip>

Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.
Richard wrote (much of) a book on C.

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.

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.

And sometimes they write parts of books.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ben Pfaff]

Al Balmer <al******@att.net> writes:

On Fri, 30 Jun 2006 10:25:08 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:

On 30 Jun 2006 07:28:33 -0700, "lovecreatesbeauty"
<lo***************@gmail.com> 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.

Richard wrote (much of) a book on C.

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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Joe Wright]

Keith Thompson wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

"Peter Nilsson" <ai***@acay.com.au> writes:

It already has. Note that most regulars in clc actually quote
c&v from the C99 standard because their copies of the C90
standard have long since gone and for the most part, the
semantics are unchanged.

The reason that I quote mainly from C99 is because the final
standard is available as a nicely generated PDF (which I have
converted to plain text format). The older standard was only
available in draft form in an easy-to-cut-and-paste format
(although a PDF was available, it was, as I understand it, a
scanned version of the dead trees).

I can't speak for the other regulars, of course.

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?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ben Pfaff]

Joe Wright <jo********@comcast.net> writes:

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?

Yes. Consider the new "inline" and "restrict" keywords, the
dropping of implicit int, and the disallowing of implicit
function declarations.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Mark McIntyre]

On 30 Jun 2006 01:17:50 -0700, in comp.lang.c , "lovecreatesbeauty"
<lo***************@gmail.com> wrote:

Keith Thompson wrote:

Really? I *like* <stdbool.h>; my only complaint is that "bool",
"false", and "true" weren't built into the language in the first
place.
typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

Just wait till you start working with programmers who grew up with
TRUE == -1. Then you;ll know what standardisation brings...
Do you worry if this fails: Char arr[999999];

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

[Frederick Gotham]

Richard Heathfield <in*****@invalid.invalid> writes:

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.

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;
}
--

Frederick Gotham

[Keith Thompson]

Joe Wright <jo********@comcast.net> writes:
[...]

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?

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 */
}

--
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.

[Ian Collins]

Richard Heathfield wrote:

Harald van D?k said:

Richard Heathfield wrote:

Mark F. Haigh said:
Richard Heathfield wrote:

<snip>

>I think the part of the C community that cares about portability wants
>a widely-implemented standard, which it already has. Until C99 becomes
>as widespread as C90, why would anyone use it if they need
>portability?

Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

Not if it stops my program from compiling.

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

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 use restrict as an identifier, you might run into trouble on a
POSIX system.

--
Ian Collins.

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On 30 Jun 2006 01:17:50 -0700, in comp.lang.c , "lovecreatesbeauty"
<lo***************@gmail.com> wrote:

Keith Thompson wrote:

Really? I *like* <stdbool.h>; my only complaint is that "bool",
"false", and "true" weren't built into the language in the first
place.

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

Just wait till you start working with programmers who grew up with
TRUE == -1. Then you;ll know what standardisation brings...

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.)

--
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.

[Frederick Gotham]

Keith Thompson posted:

If you never compare boolean values for equality, it shouldn't matter
what (non-zero) value you use for TRUE.

Indeed. The following should be fine and dandy:

#define TRUE -107
#define TRUE 5

(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;

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;
--

Frederick Gotham

[Al Balmer]

On Fri, 30 Jun 2006 12:58:23 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:

On Fri, 30 Jun 2006 10:25:08 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:

On 30 Jun 2006 07:28:33 -0700, ""
<lo***************@gmail.com> 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.

Richard wrote (much of) a book on C.
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.

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.
But Richard is smart and knowledgeable about C, and I have
nothing against him, of course.
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?)
It's just the search results you
speak of that I find unenlightening. This is off-topic, so I'll
drop it here.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Fri, 30 Jun 2006 19:59:04 +0000, Richard Heathfield
<in*****@invalid.invalid> wrote:

Al Balmer said:

On Fri, 30 Jun 2006 10:25:08 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

Al Balmer <al******@att.net> writes:
<snip>
Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.

Richard wrote (much of) a book on C.
If you try the search,

Um, you're telling this to Ben?!?!?

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.

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.

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.

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.

And sometimes they write parts of books.

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.)

--
Al Balmer
Sun City, AZ

[Richard Heathfield]

Al Balmer said:

<snip>

But perhaps you could enlighten me as to why my
suggestion to lcb should annoy him so much.

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!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.com> writes:

Keith Thompson posted:

If you never compare boolean values for equality, it shouldn't matter
what (non-zero) value you use for TRUE.
Indeed. The following should be fine and dandy:

#define TRUE -107
#define TRUE 5

(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;

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.

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.
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.

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.

--
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.

[Al Balmer]

On Fri, 30 Jun 2006 22:48:08 +0000, Richard Heathfield
<in*****@invalid.invalid> wrote:

Al Balmer said:

<snip>

But perhaps you could enlighten me as to why my
suggestion to lcb should annoy him so much.

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!

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 :-)

--
Al Balmer
Sun City, AZ

[lovecreatesbeauty]

Frederick Gotham wrote:

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?

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

[Richard Heathfield]

lovecreatesbeauty said:

Frederick Gotham wrote:

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?

The standard committee gave out an airy-fairy idea

Not true. They produced a formal international standard.
but can not give a compiler realizing it on time.
That isn't the purpose of the committee.
The coders have no choices and can not
follow an empty dream on time.
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.
Some people will say that making the
compilers comply with the latest standard document is not the duty of
the standard committee.
Correct.
Some powerful people will say, for example,
writing a compiler is rather easy and simple.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Malcolm]

"Richard Heathfield" <in*****@invalid.invalid> wrote

lovecreatesbeauty said:

Some powerful people will say, for example,
writing a compiler is rather easy and simple.

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.

If you can alter the laguage specs to get round little difficulties, and you
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.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[santosh]

Malcolm wrote:

"Richard Heathfield" <in*****@invalid.invalid> wrote

lovecreatesbeauty said:

Some powerful people will say, for example,
writing a compiler is rather easy and simple.

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.

If you can alter the laguage specs to get round little difficulties, and you
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.

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.

[santosh]

lovecreatesbeauty wrote:

Frederick Gotham wrote:

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?

The standard committee gave out an airy-fairy idea...

Not at all. The C standard is a very realistic and pragmatic one; some
say too much so.
but can not give a
compiler realizing it on time.
That's not the job of the Standard commitee, especially considering the
complexity of a C compiler and the number of platforms it supports.
The coders have no choices and can not
follow an empty dream on time.
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.
Some people will say that making the
compilers comply with the latest standard document is not the duty of
the standard committee.
And they are quite right.
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?
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.
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.

The users don't want to follow their footsteps, atleast not completely.

[Mark F. Haigh]

Richard Heathfield wrote:
<snip>

>
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'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
mf*****@sbcglobal.net

[Andrew Poelstra]

On 2006-07-02, Mark F. Haigh <mf*****@sbcglobal.netwrote:

Richard Heathfield wrote:
<snip>

>>
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'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

<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.

--
Andrew Poelstra <http://www.wpsoftware.net/blog>
To email me, use "apoelstra" at the above address.
"You people hate mathematics." -- James Harris

[websnarf]

Frederick Gotham wrote:

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

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.

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.

Well, there are basically no C99 compilers and there is no demand from
users.

Could someone please explain to me why this is so?

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Mark F. Haigh]

we******@gmail.com wrote:
<snip>

>
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), [...]

Practically speaking, this is a non-issue. People just insert the
machine instruction into the code via platform-specific inline assembly
support.

Some machines have a fast population count instruction. Does that mean
C needs simply-expressed support for it? Of course not.

[...] 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.

Long is exactly 32 bits? A couple of the boxes at my desk disagree
with that "de facto standard" (and yet still manage to do crypto).

7.8.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with
width N, no padding bits, and a two's complement representation. Thus,
int8_t denotes a signed integer type with a width of exactly 8 bits.

>
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).

Huh? Any library function which takes multiple pointers __assumes
aliasing__ between types allowed to alias, not the other way around.
What do you think 'restrict' was for?

<snip>

Mark F. Haigh
mf*****@sbcglobal.net

[Keith Thompson]

we******@gmail.com writes:
[...]

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),

I'm not aware of any other languages that support this.

and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement.

I.e., the standard can be implemented on architectures that don't use
2's 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.

Code that assumes long is exactly 32 bits will break on several of the
platforms I use every day.

[...]

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?)

I think you're thinking of flexible array members, not variable length
arrays (they're two different things).

4) arbitrary
positioned variable declarations, which serves no relevant purpose
other than some typing convenience or cosmetic effect.

Allowing declarations and statements to be mixed can make it easier to
declare variables whose initializations depend on previous statements
You can also do that by introducing a new scope, but that can be
awkward.

--
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.

[websnarf]

Keith Thompson wrote:

we******@gmail.com writes:
[...]

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),

I'm not aware of any other languages that support this.

Python and Java both have bignum classes. I don't know how Java's
implementation works, but Python uses GMP as its back-end. That means
that it includes all the assembly paths that have been encoded into
GMP. (It also means Python's back-end will never support
multithreading, since GMP is not multithreading safe.) Bignum classes
are basically a superset of high-word multiplication, and actually is
the primary purpose for having a high-word multiplication capability.

It means that *pure* Python code will outperform pure C code on large
bignum operations. This is not hyperbole. Python in general is at
least 10 times slower than C on nearly any kind of operation -- but on
RSA crypto, or bignum the only chance C has is to use libraries like
GMP which include platform specific assembly, and have various warts
like breaking multi-threading. In the limiting cases, pure Python
versus pure C will be a 4 to 1 speed advantage to Python.

Obviously C would never include a bignum library, but the mere
inclusion of high-word multiplication alone, means the only barrier to
implementing bignum libraries in pure C that are at near-optimal
machine speed is just writing a fairly straightforward library to do
so. So while demanding that C keep up with other languages on variable
length integers might be a bit much to ask for, asking for a single
operation, namely high-word multiply, is not. And it would be more in
keeping with C's minimalist approach. A bignum library might implement
just another fixed size integer type that is larger, or it might be
dynamically resizable, and there are issues with making such a library
go fast *and* be multithreaded (though I believe its possible to do
both, though the GMP people have not yet figured it out) -- so it makes
sense that C programmers be able to make that choice themselves.

and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement.

I.e., the standard can be implemented on architectures that don't use
2's complement.

Right; and there was a time where this might have made sense. It was
certainly long before 1999.

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

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.

Code that assumes long is exactly 32 bits will break on several of the
platforms I use every day.

That's nice. Do you also use C99 compilers on those platforms every
day? For your marginal platforms you already have C89.

4) arbitrary
positioned variable declarations, which serves no relevant purpose
other than some typing convenience or cosmetic effect.

Allowing declarations and statements to be mixed can make it easier to
declare variables whose initializations depend on previous statements
You can also do that by introducing a new scope, but that can be
awkward.

Some people call that "structure". It has some arguable reason to be
like that in C++ because declaration and construction typically happens
at the same time (though I am personally not that impressed with this
compromise in C++, since it doesn't have a way of similarly controlling
points of destruction). There is no comparable argument for this to be
in C. As I said, its purely cosmetic.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

Mark F. Haigh wrote:

we******@gmail.com wrote:
<snip>

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), [...]

Practically speaking, this is a non-issue. People just insert the
machine instruction into the code via platform-specific inline assembly
support.

Uh ... right, that's what they do. But then its not C code anymore --
its assembly. So why doesn't Python and Java simply call out to a
external library that is outside of their language (though native
methods or shell calls or whatever) to do this same thing? Obviously,
these are things for which are naturally covered by those languages
directly (in their embodiment of bignums, of course.)

The case for adding this in C is simple -- it makes efficient bignum
libraries implementable completely in standard C, it *can* be simulated
(though slowly) with all current C implementations, there is very
significant hardware support for it (all modern CPUs, especially if you
exclude UltraSparc from being a modern CPU), and other languages are
basically starting to include it with a view to enticing developers.

Some machines have a fast population count instruction. Does that mean
C needs simply-expressed support for it? Of course not.

Oh! You were so close. You meant to say: "Of course it does". I
personally endorse the inclusion of pop-count operations in the C
standard library as well. Also bit scanning instructions. Following
the impeccable reasoning you just presented.

The standard should be simply that you should demonstrate an
interesting and potentially useful algorithm that can exploit such
functionality to great effect and for which there is at least some
platform/CPU support and which can be easily emulated in pure C on
other platforms. *This* is how you make a "high-level assembler".
This is also a way to stay relevant -- developers will have more of a
"I have to have this" functionality consideration that goes into their
thinking.

[...] 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.

Long is exactly 32 bits? A couple of the boxes at my desk disagree
with that "de facto standard" (and yet still manage to do crypto).

Well they manage to do so with a lot of extra redundant work. Unless
they are an exacly integer multiple of 32 bits, they are also going to
end up being a lot slower because of it.

7.8.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with
width N, no padding bits, and a two's complement representation. Thus,
int8_t denotes a signed integer type with a width of exactly 8 bits.

Hmmm ... this appears to be different from my version of the
documentation (presumably some free older draft). "and a two's
complement representation" isn't there in my version of the
documentation. Obviously this makes a huge difference.

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).

Huh? Any library function which takes multiple pointers __assumes
aliasing__ between types allowed to alias, not the other way around.
What do you think 'restrict' was for?

I was referring to what C89 was. I specifically point out that C99
"fixes" the situation by making it explicit from a syntactical point of
view (adding restrict.) But in real effect, compilers don't behave
differently except for being able to go whole hog on no-alias
optimiation whenever they see "restrict".

Aliasing is also an issue in terms of *correctness*. strcat(p,p) has a
very obvious intuitive meaning that doesn't match up with its actual
meaning (which is nothing, since it performs UB). But even now that we
have this explicit syntax, we don't see any of these compilers
enforcing compile time checking for aliasing anyways. In general it
requires runtime checking to be fully enforced anyhow. Once you do
that, however, it becomes just as easy to go ahead and break out the
aliasing case and make it function in some well defined way.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
(Paul wrote)

> 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.

And then the troll completely misunderstood it and wrote:

>Code that assumes long is exactly 32 bits will break on several of the
platforms I use every day.

It is mind-numbing how dumb of a comment this is.

[Richard Heathfield]

we******@gmail.com said:

<snip>

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

You can do cryptography with unsigned integers. No, really you can. And
people do. There is no need whatsoever to assume two's complement, because
there's no need whatsoever to use negative numbers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

we******@gmail.com writes:

Keith Thompson wrote:

>we******@gmail.com writes:

[...]

and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement.

I.e., the standard can be implemented on architectures that don't use
2's complement.

Right; and there was a time where this might have made sense. It was
certainly long before 1999.

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

There's nothing stopping you from writing pure C code that assumes a
2's-complement representation. Just add something like this:

#include <limits.h>
#if INT_MIN == -INT_MAX
#error "This code only works on two's-complement systems."
#endif

in one of your application's header files. (I can imagine the test
not working properly in some bizarre circumstances, but it seems
unlikely.) Or, if you're really paranoid, do a test at run time that
examines the bits of a negative integer, and abort the program if it
fails (you can also check for padding bits if necessary). You're now
effectively programming in a subset of C that requires 2's-complement,
and there was no need to change the standard to forbid implementations
that use other representations.

(This is assuming you really need 2's-complement; as Richard said,
it's likely you can work just with unsigned integers and avoid the
issue altogether.)

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.

Code that assumes long is exactly 32 bits will break on several of the
platforms I use every day.

That's nice. Do you also use C99 compilers on those platforms every
day? For your marginal platforms you already have C89.

On 64-bit systems, long is typically 64 bits. These are not "marginal
platforms", and they're becoming less marginal all the time. You can
buy an x86-64 system at your local computer store, and you can install
any of a number of mainstream operating systems on it.

And there's no need to assume that long is 32 bits anyway. If I have
C99, I can use int32_t and uint32_t. If I don't have C99, I can use
int32_t and uint32_t.

All the world was never a VAX, and all the world isn't an x86 now.

--
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.

[Keith Thompson]

we******@gmail.com writes:

Mark F. Haigh wrote:

>we******@gmail.com wrote:

[...]

[...] 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.

Long is exactly 32 bits? A couple of the boxes at my desk disagree
with that "de facto standard" (and yet still manage to do crypto).

Well they manage to do so with a lot of extra redundant work. Unless
they are an exacly integer multiple of 32 bits, they are also going to
end up being a lot slower because of it.

On a lot of current platforms, int is exactly 32 bits and long is
exactly 64 bits. If you want 32 bits on such a platform, there is
absolutely no problem; just use int, or some alias of int (such as
int32_t). I can only assume from your comments that you didn't know
this.

I have worked on systems that have no 32-bit integer type, but those
systems are fairly exotic, and they're optimized for floating-point
anyway. I don't know much about cryptography, but I would think that
the algoriths would work at least as well with 64-bit integers as with
32-bit integers, perhaps with some re-coding.

>7.8.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with
width N, no padding bits, and a two's complement representation. Thus,
int8_t denotes a signed integer type with a width of exactly 8 bits.

Hmmm ... this appears to be different from my version of the
documentation (presumably some free older draft). "and a two's
complement representation" isn't there in my version of the
documentation. Obviously this makes a huge difference.

Get a copy of n1124.pdf. It includes the offical C99 standard plus
TC1 and TC2, and it's freely available.

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).

Huh? Any library function which takes multiple pointers __assumes
aliasing__ between types allowed to alias, not the other way around.
What do you think 'restrict' was for?

I was referring to what C89 was. I specifically point out that C99
"fixes" the situation by making it explicit from a syntactical point of
view (adding restrict.) But in real effect, compilers don't behave
differently except for being able to go whole hog on no-alias
optimiation whenever they see "restrict".

The C89/C90 standard does *not* allow the compiler to assume in
general that pointer parameters are not aliased, but it has specific
statements for certain library functions that says they have undefined
behavior for certain arguments (e.g., overlapping strings for
memcpy()).

The addition of "restrict" in C99 allowed some of these restrictions
to be stated directly in the function prototype. It also allows
user-written functions to impose similar restrictions.

Note that adding "restrict" *only* causes some constructs that would
otherwise be legal to invoke undefined behavior. A conforming C99
compiler could legally ignore it altogether (as long as it recognizes
the keyword, of course). Its intent is to give the compiler
permission to perform certain optimizations that it otherwise couldn't
perform. It gives the programmer a mechanism to make certain promises
to the compiler. A compiler may take advantage of those promises, but
it isn't required to.

--
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.

[Frederick Gotham]

Keith Thompson posted:

#include <limits.h>
#if INT_MIN == -INT_MAX
#error "This code only works on two's-complement systems."
#endif

Perhaps the following would be preferable:
#if (-1 & 3) != 3
#error "This code only works on two's-complement systems."
#endif
--

Frederick Gotham

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Keith Thompson posted:

> #include <limits.h>
#if INT_MIN == -INT_MAX
#error "This code only works on two's-complement systems."
#endif

Perhaps the following would be preferable:
#if (-1 & 3) != 3
#error "This code only works on two's-complement systems."
#endif

Yes, that should work. Arithmetic expressions in a "#if" are evaluted
using the same representation as long int and unsigned long int (in
C90), or intmax_t and uintmax_t (in C99), so the expression should be
evaluated as if it were being evaluated at run time.

I'm not sure which one I'd prefer.

--
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.

[websnarf]

Keith Thompson wrote:

we******@gmail.com writes:

Keith Thompson wrote:

we******@gmail.com writes:

[...]

and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement.

I.e., the standard can be implemented on architectures that don't use
2's complement.

Right; and there was a time where this might have made sense. It was
certainly long before 1999.

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

There's nothing stopping you from writing pure C code that assumes a
2's-complement representation. Just add something like this:

#include <limits.h>
#if INT_MIN == -INT_MAX
#error "This code only works on two's-complement systems."
#endif

in one of your application's header files. (I can imagine the test
not working properly in some bizarre circumstances, but it seems
unlikely.)

How do I know this? As I said I don't have a machine where I can test
this.

[...] Or, if you're really paranoid, do a test at run time that
examines the bits of a negative integer, and abort the program if it
fails (you can also check for padding bits if necessary). You're now
effectively programming in a subset of C that requires 2's-complement,
and there was no need to change the standard to forbid implementations
that use other representations.

Right, or I could do nothing and watch nobody complain. BTW, which
test should I use to eliminate all other number representation systems?
Because I have no idea what all the alternatives are.

(This is assuming you really need 2's-complement; as Richard said,
it's likely you can work just with unsigned integers and avoid the
issue altogether.)

How would I know this? I use right shift, wrap around, mix exclusive
or with addition, etc as just a natural way of doing things. I know
that some of these things relies on the representation, but I don't
know what would fail on other systems.

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.

Code that assumes long is exactly 32 bits will break on several of the
platforms I use every day.

That's nice. Do you also use C99 compilers on those platforms every
day? For your marginal platforms you already have C89.

On 64-bit systems, long is typically 64 bits.

Perhaps on marginal older 64-bit systems.

[...] These are not "marginal
platforms", and they're becoming less marginal all the time. You can
buy an x86-64 system at your local computer store, and you can install
any of a number of mainstream operating systems on it.

On x86-64 systems long is *32 bits*. This is because defacto standards
are far more compelling than unadopted ones. I'm pretty sure that
64bit UltraSparc is the same way, and I'd bet that 64bit PPC is also
the same.

And there's no need to assume that long is 32 bits anyway. If I have
C99, I can use int32_t and uint32_t. If I don't have C99, I can use
int32_t and uint32_t.

All the world was never a VAX, and all the world isn't an x86 now.

Tell that to Apple, Sun and DEC.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

Richard Heathfield wrote:

we******@gmail.com said:

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

You can do cryptography with unsigned integers. No, really you can. And
people do. There is no need whatsoever to assume two's complement, because
there's no need whatsoever to use negative numbers.

Even on 32bit rotate operations? Go look up RFC 1321. They have
things like this in their source:

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

and this:

/* ROTATE_LEFT rotates x left n bits. */
#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >(32-(n))))

in there. Its an RFC, and of all the things I've heard complaints
about MD5, portability is not one of them. So certainly you *can* do
cryptography on unsigned int, and people do, and it works because the
defacto standard is that its exactly 32 bits.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

we******@gmail.com said:

Richard Heathfield wrote:

>we******@gmail.com said:

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

You can do cryptography with unsigned integers. No, really you can. And
people do. There is no need whatsoever to assume two's complement,
because there's no need whatsoever to use negative numbers.

Even on 32bit rotate operations?

Yes, there is no need whatsoever to use negative numbers in a 32-bit rotate
operation.

Go look up RFC 1321. They have
things like this in their source:

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

That looks like an unsigned integer to me, so it seems you are arguing my
case for me. Thank you. Incidentally, the comment in the RFC is wrong.
UINT4 does not define a four byte word. It is merely a synonym for unsigned
long int, which is at least *one* byte wide and *at least* 32 bits wide.
But we are not discussing 32-bit issues here; we are discussing your claim
that there is a need to assume two's complement for crypto work.

and this:

/* ROTATE_LEFT rotates x left n bits. */
#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >(32-(n))))

That looks like it would be suicidally unwise to use on anything /except/ an
unsigned integer type.

in there. Its an RFC, and of all the things I've heard complaints
about MD5, portability is not one of them. So certainly you *can* do
cryptography on unsigned int,

....which was the point I was making. You seemed to think that there was some
need to assume two's complement. Am I right in thinking that you now
concede you were incorrect to think so?

and people do, and it works because the
defacto standard is that its exactly 32 bits.

No, you can get crypto to work with unsigned integer types that are not 32
bits in size, too. I've proved you wrong on the need for two's complement,
and I can prove you wrong on the need for exactly-32-bit ints if you like.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ike Naar]

In article <11**********************@a14g2000cwb.googlegroups .com>,
<we******@gmail.comwrote:

>On x86-64 systems long is *32 bits*. This is because defacto standards
are far more compelling than unadopted ones. I'm pretty sure that
64bit UltraSparc is the same way, and I'd bet that 64bit PPC is also
the same.

System Configuration: Sun Microsystems sun4u Sun Ultra 45 Workstation
Solaris 10, Sun Studio 11 C compiler
$ cat a.c
#include <stdio.h>
int main(void)
{
printf("sizeof(long)=%lu\n", (unsigned long)sizeof(long));
return 0;
}
$ /opt/SUNWspro/bin/cc -xarch=generic64 a.c
$ ./a.out
sizeof(long)=8

Kind regards,
Ike

[Chris Hills]

In article <LR*******************@news.indigo.ie>, Frederick Gotham
<fg*******@SPAM.comwrites

>Keith Thompson posted:

>When the 1999 updated standard was issued, there was already an
existing standard that had been nearly universally adopted. It wasn't
perfect, but it did make it possible to write actual portable code.
There wasn't nearly as much demand for C99 as the was for C89; it made
the difference between having one standard and having another
different standard.

Do you think the C99 Standard will ever replace the C90 Standard, or do you
think the C community is content with C90 and does not want to change
anything?

Technically C99 has replaced C90. Most compilers are at C95 that is C90
with Amendment1 and the two TC's

A lot of the compiler front ends are C99 compliant as are some of the
libraries it is just that the majority of working C programmers are not
that interested in C99 or it would have been implimented by now.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Ian Collins]

Ike Naar wrote:

In article <11**********************@a14g2000cwb.googlegroups .com>,
<we******@gmail.comwrote:

>>On x86-64 systems long is *32 bits*. This is because defacto standards
are far more compelling than unadopted ones. I'm pretty sure that
64bit UltraSparc is the same way, and I'd bet that 64bit PPC is also
the same.

System Configuration: Sun Microsystems sun4u Sun Ultra 45 Workstation
Solaris 10, Sun Studio 11 C compiler
$ cat a.c
#include <stdio.h>
int main(void)
{
printf("sizeof(long)=%lu\n", (unsigned long)sizeof(long));
return 0;
}
$ /opt/SUNWspro/bin/cc -xarch=generic64 a.c
$ ./a.out
sizeof(long)=8

Same on AMD64.

--
Ian Collins.

[Chris Hills]

In article <Ra******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

>>

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?

Yes but more of a problem are the places where C will compiler under
either C90 or C99 but the behaviour changed. There area few places where
some "minor" things were changed and it can have an effect. I must dig
out the list.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <NY******************************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites

>
I think the part of the C community that cares about portability wants a
widely-implemented standard, which it already has. Until C99 becomes as
widespread as C90, why would anyone use it if they need portability?

And the part of the C community that couldn't give two hoots about
portability aren't interested in the Standard anyway - they just want
something that works on /their/ compiler, and many such people think the
Standard (if they've even heard of it) takes second place to their compiler
documentation.

A lot of people are interested in the standard but not portability. this
is mainly in the embedded areas where there are extensions to the
language due to architecture of the MCU.

Ie Use standard C except where the hardware requires a deviation for
efficient programming. Embedded systems tend to have restricted memory

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomainwrites

>On 2006-07-02, Mark F. Haigh <mf*****@sbcglobal.netwrote:

>Richard Heathfield wrote:
Granted, you may not ever get C99 support from Microsoft

<OT>
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>

completely incorrect.

>let alone C.

quite possibly. They have moved on a bit from C so it is somewhat
irrelevant.

>
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.

They don't need to they are going the ECMA route and fast track ISO.

>Of course, C89 certainly isn't broken, so C99 conformance isn't too much of
an actual issue.

You mean C95. C99 conformance is a major issue in some areas.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Roland Csaszar]

we******@gmail.com wrote:

Keith Thompson wrote:

>On 64-bit systems, long is typically 64 bits.

Perhaps on marginal older 64-bit systems.

You want to look up the differences between LLP64 (used by MS's compiler)
and LP64 (used by any other Unix compiler on 64-bit Platforms).

On x86-64 systems long is *32 bits*. This is because defacto standards
are far more compelling than unadopted ones. I'm pretty sure that
64bit UltraSparc is the same way, and I'd bet that 64bit PPC is also
the same.

No. MS uses 32bit longs for their compiler on x86-64, Sun (SPARC, x86_64),
SGI (MIPS), IBM (Power), GNU (many ;), HP (HP-UX, Itanium, Alpha),
Pathscale, Portland, ... all use 64bit longs in their compilers.

--
Roland Csaszar ----------- \\\ /// -------------- [phone]
Software Development ------ \\\ /// ----------- http://www.knapp.com
KNAPP Logistics Automation - \\V// - mailto:ro************@knapp.com