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

[Richard Heathfield]

Chris Hills said:

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

<snip>

>

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

I think he meant that, because we already have an implemented C Standard,
the existence of an *un*implemented standard is of little consequence from
the perspective of people whose goal is to be able to port their programs
with little or no rewriting. For such people, to use the Standard that is
already implemented across the board is a very easy decision to make.

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

[Mark F. Haigh]

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

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.

Spare me the theatrics. The code is simply platform-specific C. The
inclusion of assembly fragments into a C codebase does not make it
suddenly all assembly code. That's a rather ridiculous thing to say.

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

I'm not sure what you're asking. If you want to definitively know why
Python and Java do what they do, you're going to have to ask the
authors about it. Python and Java are both built upon on hundreds of
thousands of lines of C and C++ code, some of it very platform
specific. It's really a testament to the understated portability,
efficiency, and ubiquity of the C language family that somebody whould
accuse C itself of being so inferior to languages implemented with it!

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.

WG14 is certainly smart enough to know that this type of approach is
fools' gold. Use additional libraries.

<snip>

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.

Am I reading that right? You're claiming my systems with a 64-bit long
do "a lot of redundant work"? Or am I magically exempt because they're
"an exactly integer multiple of 32 bits"? I'd like to hear your
reasoning on that.

<snip>

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

No. C99 enables __further__ optimization. It does not fix the
situation, unless the situation is "Hey! r8 doesn't need to be spilled
and later reloaded because the access through the pointer at r9 can't
possibly change it. But how can we tell the compiler that..."

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

That's the thing with C. There's no such thing as "intuitive meaning".
Actual meaning is the only relevant meaning.

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.

You mean other than these types of warnings?

foo.c:11: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Mark F. Haigh
mf*****@sbcglobal.net

[Chris Hills]

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

>Chris Hills said:

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

<snip>

>>

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

I think he meant that, because we already have an implemented C Standard,
the existence of an *un*implemented standard is of little consequence from
the perspective of people whose goal is to be able to port their programs
with little or no rewriting. For such people, to use the Standard that is
already implemented across the board is a very easy decision to make.

I agree.

The problem is in some safety critical areas there a requirement to use
a "conforming compiler". Legally the C standard is C99. This is where
the problem is caused. It is for this reason AFAIK some of the few C99
compilers are C99 compliant. Not for any other [technical] reason.

BTW you keep going on about portability. There are some areas where this
is useful Libraries, RTOS, graphics libraries etc but not for the
majority.

Portable across several parts in the same MCU family is one thing but
not from architecture to architecture.

That said you do want the non architecture specific code to behave in a
consistent manner.

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

[Keith Thompson]

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

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.

Neither do I, but I know enough about integer representations to be
reasonably sure of it.

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

In C99, the alternatives are 2's-complement, 1s'-complement, and
signed magnitude. The C90 standard isn't as specific, but I've never
heard of a C implementation that used any other representation. In my
opinion, it's safe to assume that those are the only possibilites.
It's *almost* safe to assume 2's-complement, but making the assumption
explicit is easy and doesn't hurt anything.

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

It depends on what you're doing, I suppose.

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.

No.

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

No. On an x86-64 system running Red Hat Linux and gcc 3.2.3, long is
64 bits. On a SPARC Solaris 9 system, using either "gcc -m64" or
"cc -xtarget=ultra -xarch=v9", long is 64 bits. On a 64-bit IBM PPC
AIX system using "xlc -q64", long is 64 bits.

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

I don't currently have access to an Apple system. Sun, as you can
see, already knows this. DEC no longer exists; they were absorbed by
Compaq, which was then absorbed by HP.

Assuming that long is exactly 32 bits is neither safe, nor correct,
nor necessary.

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

[Richard Heathfield]

Chris Hills said:

<snip>

BTW you keep going on about portability. There are some areas where this
is useful Libraries, RTOS, graphics libraries etc but not for the
majority.

If portability doesn't matter, why bother using C? I can write a Win32
program a darn sight quicker using C++ Builder than I can using C. Super
Mario clicks the mouse to select the button to rescue the princess, then
double-clicks the button to write the code to find the treasure. Lots of
fun. :-)

But if I want my program to run on *your* computer, without knowing who
*you* are, I have to make sure it's portable. It has to work on Win32,
MS-DOS, Linux, BSD, VM/CMS, MVS, MacOS, AmigaDOS, TOS... in short, any
hosted environment at all.

Portable across several parts in the same MCU family is one thing but
not from architecture to architecture.

I would guess you haven't worked much in a mainframe environment? In the
Lost World, so to speak, it is very common for C code to be written and
tested on the PC, and then moved up to the mainframe right at the last
minute (or "fortnight" as they are sometimes called) for integration
testing. So the code has to be portable between two very, very different
architectures, even though it will only be /used/ in one of them.

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

[Joe Wright]

Keith Thompson wrote:

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?

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 <exprfor a non-void function */
}

In C90 I wouldn't be using restrict nor inline. Neither variable-length
arrays. Long habit has me using explicit int as type for those functions
that want it and always returning neatly.

I should probably get the latest gcc and turn on the c99 flag and see if
any of my current code has any problems with it.

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

[santosh]

Joe Wright wrote:

Keith Thompson wrote:

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?

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 <exprfor a non-void function */
}

In C90 I wouldn't be using restrict nor inline. Neither variable-length
arrays.

Variable length arrays are not a part of C90/C95.

[santosh]

Richard Heathfield wrote:

Chris Hills said:
<snip>

BTW you keep going on about portability. There are some areas where this
is useful Libraries, RTOS, graphics libraries etc but not for the
majority.

.... snip ...

Portable across several parts in the same MCU family is one thing but
not from architecture to architecture.

I would guess you haven't worked much in a mainframe environment? In the
Lost World, so to speak, it is very common for C code to be written and
tested on the PC, and then moved up to the mainframe right at the last
minute (or "fortnight" as they are sometimes called) for integration
testing. So the code has to be portable between two very, very different
architectures, even though it will only be /used/ in one of them.

But I suppose, practically speaking, most serious programs don't
contain hundred percent portable code. They'll probably have some
"interface" code, specific to the platform, while the rest of the
program, (as much as this is feasible), would be in standard C.

I guess, currently, programs using C99 features are in some ways like
that.

If I want to do more than what is capable with standard C, I'll have to
use implementation specific code. At this point the tendency arises to
go ahead and make most of the program use compiler/OS extensions, to
get most bang for line of code. Resisting this temptation, however, and
retaining as much standard C code as possible and using non-standard
code in a decoupled manner and in the 'correct' places, takes some
thinking and practise.

The more the program depends on compiler/platform specific functions,
the more the temptation to forget about standards and portability and
just throw your money behind a specific platform. :)

[Chris Hills]

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

>Chris Hills said:

<snip>

>BTW you keep going on about portability. There are some areas where this
is useful Libraries, RTOS, graphics libraries etc but not for the
majority.

If portability doesn't matter, why bother using C? I can write a Win32
program a darn sight quicker using C++ Builder than I can using C.

Then use C++ builder. I would.

Super
Mario clicks the mouse to select the button to rescue the princess, then
double-clicks the button to write the code to find the treasure. Lots of
fun. :-)

But if I want my program to run on *your* computer, without knowing who
*you* are, I have to make sure it's portable.

but how many apps need to do this? Most seem to be WIn2K and XP these
days or ME, 2K & XP, they don't even cover win9* anymore let alone any
of the other OS you mention. Most of the SW I have is PC or PC. Only a
few are PC or Mac

>It has to work on Win32,
MS-DOS, Linux, BSD, VM/CMS, MVS, MacOS, AmigaDOS, TOS... in short, any
hosted environment at all.

Maybe.

>

>Portable across several parts in the same MCU family is one thing but
not from architecture to architecture.

I would guess you haven't worked much in a mainframe environment?

A couple of times but most is embedded.

>In the
Lost World, so to speak, it is very common for C code to be written and
tested on the PC, and then moved up to the mainframe right at the last
minute (or "fortnight" as they are sometimes called) for integration
testing. So the code has to be portable between two very, very different
architectures, even though it will only be /used/ in one of them.

Fair enough but I bet it won't run on an 8051? :-)

There is portability and there is portability....

I can write code that is completely portable but most of the stuff I
write is not because it is for embedded micros where portable code is
large and slower. If you have code that is large and slower it can
cost a fortune if it needs a slightly larger memory.... adds 1 USD to a
unit..... 50,000 units a year.
As I keep saying though code which is not machine specific should be
portable and behave in the same way on similar machines...

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

[Frederick Gotham]

Richard Heathfield posted:

In the Lost World, so to speak, it is very common for C code to be
written and tested on the PC, and then moved up to the mainframe right
at the last minute (or "fortnight" as they are sometimes called) for
integration testing.

A "fortnight" is exactly two weeks where I'm from.
--

Frederick Gotham

[Richard Heathfield]

Chris Hills said:

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

<snip>

>>
If portability doesn't matter, why bother using C? I can write a Win32
program a darn sight quicker using C++ Builder than I can using C.

Then use C++ builder. I would.

If I'm writing a Win32 program, then most of the time that's /precisely/
what I do. But I'm not always writing Win32 programs. In fact, hardly ever.

>>But if I want my program to run on *your* computer, without knowing who
*you* are, I have to make sure it's portable.

but how many apps need to do this?

Few *applications*, it's true - if you are using that in the sense of "big
program", so to speak. Mostly, application writers know their target
platform. Even then, if it's a good application, one day it'll have to be
ported. If it is written with portability planned-in, that task will be
easier.

And then there are libraries. I'd far rather use /one/ library, regardless
of which platform I'm using, than have to learn a separate library for each
platform. So if libraries can be written portably, obviously that benefits
platform-specific software development on /all/ platforms, which is good,
right?

Most seem to be WIn2K and XP these
days or ME, 2K & XP, they don't even cover win9* anymore let alone any
of the other OS you mention. Most of the SW I have is PC or PC.

Sorry, I thought this was comp.lang.c - I didn't realise it was
comp.lang.softwarethatChrisbuys :-)

I have four different OSs running right here, only one of which is in the
Win2K/XP category. I doubt very much whether I'm the only one who runs
several OSs, either. If I want my computers to be able to do <foo>, I think
it makes sense to write *one* program to do <foo>, rather than write a
WinXPFoo, a LinuxFoo, and so on.

>>It has to work on Win32,
MS-DOS, Linux, BSD, VM/CMS, MVS, MacOS, AmigaDOS, TOS... in short, any
hosted environment at all.

Maybe.

Well, that's precisely why the code posted by clc regs is portable - we
don't know, don't ask, and don't care what platform the OP is using. Such
minor details are left for other newsgroups to deal with.

And the same goes for exegetic programs (of which I write far too many). How
would the Unix world have reacted if K&R had begun their book on C by
writing an 80-line "Hello world" with a WinMain entry point?

<snip>

>>In the
Lost World, so to speak, it is very common for C code to be written and
tested on the PC, and then moved up to the mainframe right at the last
minute (or "fortnight" as they are sometimes called) for integration
testing. So the code has to be portable between two very, very different
architectures, even though it will only be /used/ in one of them.

Fair enough but I bet it won't run on an 8051? :-)

Depends. Is it a hosted environment? If so, probably the code would work
just fine.

There is portability and there is portability....

Agreed.

I can write code that is completely portable

....and that's what we do here in comp.lang.c ...

but most of the stuff I write is not

....and that's what we do in other newsgroups.

because it is for embedded micros where portable code is
large and slower. If you have code that is large and slower it can
cost a fortune if it needs a slightly larger memory.... adds 1 USD to a
unit..... 50,000 units a year.

50,000 bucks is nothing compared to the money you save by being able to port
your half-million-line browser/mailclient to a new platform in four
person-weeks rather than a year or so, over and over again as more STB
suppliers become interested in your product. One of my former clients made
precisely this investment, and for precisely this reason, and it paid off
in hard cash savings.

As I keep saying though code which is not machine specific should be
portable and behave in the same way on similar machines...

Precisely so. And code that /is/ machine-specific can be isolated into
self-contained modules.

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

Richard Heathfield posted:

>In the Lost World, so to speak, it is very common for C code to be
written and tested on the PC, and then moved up to the mainframe right
at the last minute (or "fortnight" as they are sometimes called) for
integration testing.

A "fortnight" is exactly two weeks where I'm from.

I'm pretty sure Richard knows that.

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

Joe Wright <jo********@comcast.netwrites:

Keith Thompson wrote:

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

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 <exprfor a non-void function */
}

In C90 I wouldn't be using restrict nor inline.

[...]

Do you mean you wouldn't be using those identifiers (which are
perfectly valid in C90), or that you wouldn't be using those features
(which are new in C99)?

You asked about correct C90 code that can't be compiled with a C99
compiler.

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

[santosh]

Richard Heathfield wrote:

Chris Hills said:

<snip>

BTW you keep going on about portability. There are some areas where this
is useful Libraries, RTOS, graphics libraries etc but not for the
majority.

If portability doesn't matter, why bother using C?

[snip]

This paper seems to be a good summary of C99 and it's availability:
<http://www-128.ibm.com/developerworks/linux/library/l-c99.html>

It appears to vindicate what Richard has said: Stick to C90 if
portability is to be ensured, or if partial portability is acceptable,
then C99 can be considered.

Personally I like the integer types and snprintf() as well as flexible
structure members.

[Stephen Sprunk]

"santosh" <sa*********@gmail.comwrote in message
news:11*********************@b68g2000cwa.googlegro ups.com...

But I suppose, practically speaking, most serious programs don't
contain hundred percent portable code. They'll probably have some
"interface" code, specific to the platform, while the rest of the
program, (as much as this is feasible), would be in standard C.

Correct. Most programs intended to be portable have the application logic
written in 100% portable C that calls into implementation-specific wrappers
which are disgustingly non-portable. It's probably 90% former and 10%
latter on any given platform, but _all_ of the wrappers probably constitute
30-50% of the project given how many of them you need (consider a GUI
program that's supposed to work on Win32, Motif, OS/X, etc).

I guess, currently, programs using C99 features are in some ways like
that.

What I've seen in OSS projects is that someone will submit code that is
subtly non-portable, and a few weeks later one of the port maintainers for
"uncommon" platforms will complain that the code no longer works,
investigate things, and cleverly rewrite the code to be portable without
losing performance on "common" systems.

C99 is pretty much rejected in the "portable" sections because there's
always someone, somewhere who is still using a C90 compiler. I learned that
the hard way; I use a lot of C99isms and GNUisms in my own code for
convenience, and before I learned what they were, I found when I'd submit
patches to OSS projects, what actually got committed by the maintainers was
rather different because they'd rewrite sections to make them C90.

Some projects are explicitly only supported on GCC, e.g. the Linux kernel,
so GNUisms and many C99isms are allowed. This is similar to the large
number of projects that explicitly require POSIX, though many of those still
require C90 since not all compilers on POSIX systems support C99 yet.

That said, I'm not aware of any project that would allow "new" or "restrict"
as a variable/function name. Code breaking when compiled as C99 or C++ is
just as bad as code breaking when compiled as C90.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[Stephen Sprunk]

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:DK********************@bt.com...

Chris Hills said:

>because it is for embedded micros where portable code is
large and slower. If you have code that is large and slower it can
cost a fortune if it needs a slightly larger memory.... adds 1 USD to a
unit..... 50,000 units a year.

50,000 bucks is nothing compared to the money you save by being
able to port your half-million-line browser/mailclient to a new platform
in four person-weeks rather than a year or so, over and over again as
more STB suppliers become interested in your product. One of my
former clients made precisely this investment, and for precisely this
reason, and it paid off in hard cash savings.

Exactly. I've worked for several companies that develop embedded products,
and the CPU tends to change every few years but we need the same code to
work on all of them so we can keep the feature set consistent and
maintenance manageable.

My present employer spent nearly a year getting their code to work on the
_second_ CPU they used. When it came time for the third CPU, they just
recompiled, ran it through QA, and called it done -- and profit margins are
up because that third CPU costs less than the first two plus requires no
other chips on the board. Without portable code, we'd be a year late to
market (which did happen with products using the second CPU); with portable
code, we have 50 man-years of programmer time available to write cool new
features that will sell more widgets.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

"Stephen Sprunk" <st*****@sprunk.orgwrites:
[...]

Some projects are explicitly only supported on GCC, e.g. the Linux
kernel, so GNUisms and many C99isms are allowed. This is similar to
the large number of projects that explicitly require POSIX, though
many of those still require C90 since not all compilers on POSIX
systems support C99 yet.

That said, I'm not aware of any project that would allow "new" or
"restrict" as a variable/function name. Code breaking when compiled
as C99 or C++ is just as bad as code breaking when compiled as C90.

I can certainly understand avoiding "restrict" (and "inline"), but
"new"? Much well-written C code *should* break when compiled as C++.
In particular, good C code should not cast the result of malloc(),
something that C++ requires.

Would an OSS project really reject C code that contains this?

int *ptr;
...
ptr = malloc(COUNT * sizeof *ptr);

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

[Ben Pfaff]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

That said, I'm not aware of any project that would allow "new" or "restrict"
as a variable/function name. Code breaking when compiled as C99 or C++ is
just as bad as code breaking when compiled as C90.

A fair amount of GNU code uses "new" as a variable name, with no
reported fallout.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[Stephen Sprunk]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Stephen Sprunk" <st*****@sprunk.orgwrites:
[...]

>Some projects are explicitly only supported on GCC, e.g. the Linux
kernel, so GNUisms and many C99isms are allowed. This is similar to
the large number of projects that explicitly require POSIX, though
many of those still require C90 since not all compilers on POSIX
systems support C99 yet.

That said, I'm not aware of any project that would allow "new" or
"restrict" as a variable/function name. Code breaking when compiled
as C99 or C++ is just as bad as code breaking when compiled as C90.

I can certainly understand avoiding "restrict" (and "inline"), but
"new"? Much well-written C code *should* break when compiled as C++.
In particular, good C code should not cast the result of malloc(),
something that C++ requires.

At a minimum, C headers should be digestible by a C++ compiler (with extern
"C" {...} wrapped around them) so that C++ programs can link with C
libraries. This greatly expands the number of people that can use your code
and costs virtually nothing.

As far as the internals in the .c file, I wouldn't say anyone goes to pains
to make the code into the common subset of C and C++, but one shouldn't go
out of their way to make code uncompilable as C++ (e.g. using new or class
as identifiers). This is one reason you see a lot of casts in "C" code that
aren't needed -- someone put them in so they could compile as C++ too.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[Al Balmer]

On Mon, 03 Jul 2006 18:57:28 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>Few *applications*, it's true - if you are using that in the sense of "big
program", so to speak. Mostly, application writers know their target
platform. Even then, if it's a good application, one day it'll have to be
ported. If it is written with portability planned-in, that task will be
easier.

Often code must be "ported" to a later version of the same system. I'm
currently maintaining a huge system which still has lots of
pre-standard code, and the compilers available for current hardware
won't compile it. To make it even more interesting, we may have to go
from a 32-bit to a 64-bit environment. Of course, the original
programmer "knew" how big an integer is, and that pointers and
integers were pretty much interchangeable ...

One bright side - when making an old program ISO compatible, the
improved compile-time checking often finds subtle bugs that customers
have been occasionally running into for years.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Mon, 03 Jul 2006 18:24:46 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:

>Richard Heathfield posted:

>In the Lost World, so to speak, it is very common for C code to be
written and tested on the PC, and then moved up to the mainframe right
at the last minute (or "fortnight" as they are sometimes called) for
integration testing.

A "fortnight" is exactly two weeks where I'm from.

Yes, but how long is the "last minute"?

--
Al Balmer
Sun City, AZ

[Al Balmer]

On 2 Jul 2006 05:00:13 -0700, we******@gmail.com wrote:

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

So, in the end, you'd have assembly language. Hasn't that already been
done?

--
Al Balmer
Sun City, AZ

[Morris Dovey]

Stephen Sprunk (in 44**********************@free.teranews.com) said:

| As far as the internals in the .c file, I wouldn't say anyone goes
| to pains to make the code into the common subset of C and C++, but
| one shouldn't go out of their way to make code uncompilable as C++
| (e.g. using new or class as identifiers). This is one reason you
| see a lot of casts in "C" code that aren't needed -- someone put
| them in so they could compile as C++ too.

The bulk of the casts I've seen in C code (for which I've been able to
ask the authors) has been to "shut the compiler up" so as to be able
to claim that the program compiled "clean".

I've horrified more than few clients by going through source modules
and removing /all/ of the casts, doing a bit of clean up, andthen
recompiling in the compiler's most twitchy mode. They're amazed to see
that the compiler was making legitimate complaints and to recognize
how (normally) trivial it is to clean the code up - and that it then
compils without warnings or errors.

I'm not out to make life difficult for C++ programmers; but neither am
I willing to allow C problems to be masked with casts. YMMV.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[Keith Thompson]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

[...]

>I can certainly understand avoiding "restrict" (and "inline"), but
"new"? Much well-written C code *should* break when compiled as C++.
In particular, good C code should not cast the result of malloc(),
something that C++ requires.

At a minimum, C headers should be digestible by a C++ compiler (with
extern "C" {...} wrapped around them) so that C++ programs can link
with C libraries. This greatly expands the number of people that can
use your code and costs virtually nothing.

Ok, I can see that.

As far as the internals in the .c file, I wouldn't say anyone goes to
pains to make the code into the common subset of C and C++, but one
shouldn't go out of their way to make code uncompilable as C++
(e.g. using new or class as identifiers). This is one reason you see
a lot of casts in "C" code that aren't needed -- someone put them in
so they could compile as C++ too.

I suspect a lot of casts in C code are there because the author didn't
know they were unnecessary.

I might be tempted to use new or class as an identifier deliberately.
If nothing else, it would serve as a flag to indicate that the code
has never been tested as C++, and if you feel the need to compile it
as C++ for some reason it's going to take a bit of work. And of
course *any* C code I write using malloc() will almost certainly not
be valid C++ ("almost" because I might happent to assign the result to
a void*).

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

[lawrence.jones]

pete <pf*****@mindspring.comwrote:

>
But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin

[Keith Thompson]

la************@ugs.com writes:

pete <pf*****@mindspring.comwrote:

>But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

Perhaps the C99 standard uses larger print because we were all 10
years older in 1999 than in 1989. 8-)}

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

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
[e-mail]

>la************@ugs.com writes:

>pete <pf*****@mindspring.comwrote:

>>But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

Perhaps the C99 standard uses larger print because we were all 10
years older in 1999 than in 1989. 8-)}

C09 will be in 16 point with and audio book version also available :-)

This also explains why I have gone from a 14inch CRT screen to a 19 inch
LCD screen (effectively the same as a 21inch CRT) and only seem to have
the same amount of information on it :-)

Never mind, I recall the programming magazines of 20 years ago
predicting that "in 20 years time" we would be speaking at the computer
and it would take spoken descriptions and turn them in to working (bug
free) programs.....

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

[Stephen Sprunk]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Stephen Sprunk" <st*****@sprunk.orgwrites:

>As far as the internals in the .c file, I wouldn't say anyone goes to
pains to make the code into the common subset of C and C++, but one
shouldn't go out of their way to make code uncompilable as C++
(e.g. using new or class as identifiers). This is one reason you see
a lot of casts in "C" code that aren't needed -- someone put them in
so they could compile as C++ too.

I suspect a lot of casts in C code are there because the author didn't
know they were unnecessary.

Perhaps I'm giving some folks more credit than they deserve, but I think
it's at worst an even split. I personally never bothered to learn C's rules
for what pointers can be assigned to what other pointers, so I just write
everything without casts and then go back and insert them where the compiler
complains. And when I submit warning-free code, I often see patches with
new casts added by other folks that only seem to make sense if they were
compiling my code as C++.

I might be tempted to use new or class as an identifier deliberately.
If nothing else, it would serve as a flag to indicate that the code
has never been tested as C++, and if you feel the need to compile it
as C++ for some reason it's going to take a bit of work. And of
course *any* C code I write using malloc() will almost certainly not
be valid C++ ("almost" because I might happent to assign the result to
a void*).

Other than the need for more casts, I fail to see why code using malloc()
would be less viable under C++. malloc() et al work just fine in C++ as
long as you don't try to mix in use of new/delete or try to malloc() a class
with {con,de}structors.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

[...]

>I might be tempted to use new or class as an identifier deliberately.
If nothing else, it would serve as a flag to indicate that the code
has never been tested as C++, and if you feel the need to compile it
as C++ for some reason it's going to take a bit of work. And of
course *any* C code I write using malloc() will almost certainly not
be valid C++ ("almost" because I might happent to assign the result to
a void*).

Other than the need for more casts, I fail to see why code using
malloc() would be less viable under C++. malloc() et al work just
fine in C++ as long as you don't try to mix in use of new/delete or
try to malloc() a class with {con,de}structors.

Any code *I* write that uses malloc() will not cast the result; it
will assign it directly to the target pointer object, taking advantage
of C's implicit conversion of void* to a pointer-to-object type. It
will therefore not compile as C++.

It is, of course, possible to use malloc() in C++ -- but I don't.

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

[ena8t8si]

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

As you say, INT_MIN == -INT_MAX can hold even on
a two's complement implementation.

[ena8t8si]

la************@ugs.com wrote:

pete <pf*****@mindspring.comwrote:

But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

If you're taking votes, my vote is to keep the C99 fonts.
A 10 point font is too small for any extended reading
(at least for anyone with eyes past a certain age).

The formatting and layout choices in C99 were quite good.

[Al Balmer]

On 18 Jul 2006 01:59:27 -0700, en******@yahoo.com wrote:

>
la************@ugs.com wrote:

>pete <pf*****@mindspring.comwrote:

>
But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

If you're taking votes, my vote is to keep the C99 fonts.
A 10 point font is too small for any extended reading
(at least for anyone with eyes past a certain age).

The formatting and layout choices in C99 were quite good.

Your contributions are welcome, but it may not be obvious, since
you're posting from Google Groups, that the messages you're replying
to are old - only a week for this one, but a month for the other I
just read.

No big deal - just a heads up.

--
Al Balmer
Sun City, AZ

[ena8t8si]

Al Balmer wrote:

On 18 Jul 2006 01:59:27 -0700, en******@yahoo.com wrote:

la************@ugs.com wrote:

pete <pf*****@mindspring.comwrote:

But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

If you're taking votes, my vote is to keep the C99 fonts.
A 10 point font is too small for any extended reading
(at least for anyone with eyes past a certain age).

The formatting and layout choices in C99 were quite good.

Your contributions are welcome, but it may not be obvious, since
you're posting from Google Groups, that the messages you're replying
to are old - only a week for this one, but a month for the other I
just read.

THEY ARE? Darn it, that means I'm going to
have to take the time machine into the shop
again.