Does your C compiler support "//"? (was Re: using structures)

[Richard Kettlewell]

Richard Kettlewell wrote:

Strange. On mine (IRIX64 usrco 6.5 01100601 IP27), same t.c and same
cc command, no diagnostic. Besides, the man page mentions the switch
-Xcpluscomm

So it does. I wonder how I managed to miss that; I thought I'd
searched the man page for 'comment'.

 

[Greg Comeau]

I already did specify my criteria. The slowness of adoption, a virtual
standstill, shows that the criteria will never be met.

I'm going to sidestep whether the word failure is the right
word or not. Yes, C99 has had problem. And yes, up until
this point it has been in slow motion. This time last year
is certainly looked hopeful from in front of the curtain.
But it *has* changed. Look at the list I posted yesterday.
And there is more going on behind the curtain. Fine to me
if the action is still not earth shattering, but for whatever
problem exist, it's not a virtual standstill.

 

[Greg Comeau]

None of these are complete C99 implementations,

I listed the various stages of some compilers yesterday,
including some I believe have at least full core language.

and only the
GNU developers claim to be working towards making a complete C99
implementation (though I find this claim to be a bit hollow).

I don't know where you're getting your info from.

And Dinkuware and Comeau can't be defined as "major", anyways.

Don't define it as major then. It still does not remove
the combo.

As neither is a complete implementation, they aren't even
seriously competing in the market.

Again, I don't know where you're getting your info from.

 

[Ross Ridge]

Depends upon how you define major. Certainly neither MS nor
Borland offers C99 yet if that is what you mean. But discarding
implementations such as Dinkumware, Comeau, gcc, Intel, etc,
doesn't seem appropriate.

None of these are complete C99 implementations,

I listed the various stages of some compilers yesterday,
including some I believe have at least full core language.

Non sequitur.

I don't know where you're getting your info from.

Publically available information.

Don't define it as major then. It still does not remove
the combo.

The Dinkumware/Comeau "combo" isn't a complete implementation either.

Again, I don't know where you're getting your info from.

Again publically available information. Are you trying to claim that
Dinkumware or Comeau are in fact offer complete implementations, despite
what you and they claim publically?

Ross Ridge

 

[Nick Maclaren]

|> In article <[email protected]>, Chris Hills
|>
|> >Not at all. They were VERY clear and explicit about it. This has been
|> >amplified by some of the more experienced members at other meetings
|> >where you were not present. They were not IST/5/-14 meetings.
|>
|> In that case you are not quoting from the UK C panel but appealing to
|> anonymous sources holding private, unofficial and presumably unrecorded
|> discussions. I think that the convenor of the BSI C Standards Panel
|> implying in a public forum that this was the official position of
|> IST/5/-14 is cause for serious concern.

I am not going to go into details here, but wish to say that I have
made statements at BSI C Panel meetings where you were present that
justify Chris Hills position, and received agreement from several
other members of the panel.


Regards,
Nick Maclaren.

 

[Francis Glassborow]

There is. But it is not true. I made my objections explicit, and
stated what I wanted for me to change my vote. As the document has
not addressed them, I see no reason to consider the details of a
new draft. As I have stated at meetings where you were present,
and others, I shall continue to vote against this until they ARE
addressed.

Yet none of your objections have been included in the BSI's 'no' vote.
The issue is not that the BSI voted 'no' but that it's only stated
reason was that another document (the C99 standard) should be fixed in
unspecified ways.

 

[Nick Maclaren]

|> In article <[email protected]>, Nick Maclaren
|> >There is. But it is not true. I made my objections explicit, and
|> >stated what I wanted for me to change my vote. As the document has
|> >not addressed them, I see no reason to consider the details of a
|> >new draft. As I have stated at meetings where you were present,
|> >and others, I shall continue to vote against this until they ARE
|> >addressed.
|>
|> Yet none of your objections have been included in the BSI's 'no' vote.
|> The issue is not that the BSI voted 'no' but that it's only stated
|> reason was that another document (the C99 standard) should be fixed in
|> unspecified ways.

Then please do not make statements like:

There is an alternative explanation, ...
They apparently voted 'no' not on the basis of the document in
question but because they dislike another document but see no reason to
actually do any work detailing their objections to that document let
alone making proposals as to how it might be fixed.

I have detailed my objections and I have proposed how it might be
fixed, repeatedly and over many years. I also said that I was
prepared to put the effort in to help if a project to specify such
areas precisely was started.


Regards,
Nick Maclaren.

 

[Francis Glassborow]

I have detailed my objections and I have proposed how it might be
fixed, repeatedly and over many years. I also said that I was
prepared to put the effort in to help if a project to specify such
areas precisely was started.

The way to do that is through a NB (BSI in your case) through which you
can channel defect reports on existing standards and papers making
proposals for inclusion new standards. Sadly during the 1990s many
people who could have contributed to what was to become C99 did not do
so. I am sure that C99 would have been a much better document had you
had the time to become more actively involved in its creation.

However Standards are not academic treatises but commercial documents
that are influenced by the availability of resources. For example the
whole of the numerics areas in both C and C++ was adversely affected by
the withdrawal of expertise that had been provided by companies involved
in development of and for 'number crunchers' Hindsight suggests that it
might have been better to have pulled the work on that area but being
human those involved always hoped that things would get better and they
could fully deliver on their objectives.

 

[Ross Ridge]

and only the
GNU developers claim to be working towards making a complete C99
implementation (though I find this claim to be a bit hollow).

I don't know where you're getting your info from.

Publically available information.

I think he was looking for an answer that was a bit more specific. I
certainly am. Looking at the Comeau web site, I didn't find anything
explicitly claiming full C99 compliance, just support for various C99
features. Nor could I find anything suggesting that full C99 compiance
was one of their current objectives. However, absence of evidence is not
proof of absence.

I wasn't offering proof of absence, that's impossible. However my
statement is easily proved false if I'm wrong.

I remember coming to the conclusion a couple of years ago that Comeau
requires an existing C compiler and library, which it piggybacks off of.
I presume that's what you're referring to? However, I can't remember how
I reached that conclusion, and I couldn't find anything which says so
explicitly on their web site. That may just mean that I didn't look in
the right place.

From http://www.comeaucomputing.com:

What Is Comeau C/C++ 4.3.0?

Comeau C/C++ is a command line driven C and C++ compiler that
generates platform specific and C compiler specific C as its
object code (the generated C code won't work on another platform,
as it is CPU, OS and C compiler specific, and furthermore, it is
not standalone). It then transparently invokes a particular C
compiler that we've specifically ported it to ...

... The C compiler provided by your UNIX manufacturer (or
those we mention for non-UNIX ports) will work with the Comeau
C/C++ front-end on the respective platform you have purchased
Comeau C/C++ for, as only those have been tested and integrated
together. A list of which C compilers are required is provided
above. ...

As it's dependent on another compiler for doing the work of optimization,
code generation and linking, it's not a serious player in the market.

The WWW page makes it much less of obvious that Comeau is dependent on
a third party C library:

Comeau C/C++ does not formally come with any other library,
therefore, iostreams, STL, and other parts of the C++
Standard Library and of the C Standard Library must be gotten
elsewhere. Here's some choices:

- Dinkumware, Ltd. has ported their C++ and C libraries
for use with Comeau C/C++ on specific platforms. ...

- libcomo, a separate Standard C++ Library product from
Comeau Computing ...

- Since Comeau C/C++ requires a C compiler, many
customers just use the Standard C library from their C
compiler. In most cases, this works transparently right
out of the box. The Dinkumware libraries can also be used,
especially if you need C99 library support. Note that
the C++ libraries provided by the underlying compiler
(for instance, with MSVC++ or gcc/g++) will not be usable
out of the box, so as the previous bullet notes, you will
need to obtain another C++ Standard Library elsewhere,
whether libcomo, Dinkumware, or some other one.

Comeau's libcomo provides a Standard C++ library, so apparently a Standard
C library would still be needed if it was used.

Ross Ridge

 

[Douglas A. Gwyn]

What other reason or reasons were given?

Here is the *entire* UK comment from the embedded systems PDTR ballot:

Generally that we should not build on the maths of C99
until the current problems in the standard are fixed.

Note that the majority who were against this PDTR work
in the embedded field.

 

[Francis Glassborow]

That is an incorrect statement.

As far as I know this is the total comment that accompanied the UK 'No'
vote. I fail to see where any of Nick's specific comments have been
included.
<quote>
Comment UK-1:
Generally that we should not build on the maths of C99 until the
current problems in the standard are fixed.

Note that the majority who were against this PDTR work in the embedded
field.
</quote>

If Chris knows better than those who have the task of addressing NB
comments perhaps he would share it with us.

 

[Douglas A. Gwyn]

I doubt it. Firstly, you have made it clear that you are not prepared
to accept evidence - witness your persistent claims that no programs
are broken by the breach of promise (in C90) that long is the longest
integer, despite clear, clean, examples of broken codes.

No existing code *was* broken for any domain in which it
worked before, but only when applied in some new domain
where it would not have worked correctly anyway. What C99
provided was a previously unavailable standard facility that
can now be used to solve that problem for once and for all.
It would have been negligent for C99 to not have addressed
the need for *standard* support for a wider variety of
integer types, which had already been resulting in various
nonstandard extensions.

But, secondly, I was not referring to incompatibilities in the standard
but to ones between the older compilers and those that attempt to
support some of C99. The latest example was a major vendor getting
confused about the status of Annex F as it affects the rest of the
standard, and breaking existing code.

I could have sworn that you were claiming incompatibilities
between the standards. It's hard to see the logic in
blaming the standard for a vendor not maintaining compatibility
in his compiler releases. The compiler vendors I encounter
have gone to great lengths to ensure compatibility; their
customers reasonably expect it.

Nonsense. Firstly, there is the "long long" issue. Secondly,
there are some rather nasty and subtle incompatibilities that were
raised on the reflector - NOT by me.

"long long" is an extension, actually not invented by the
C standards committee but already in widespread use by the
time we were working on C9x. Any program that uses at most
long int and properly casts arguments to match printf formats
is unaffected by long-long support. Programs that were too
sloppy in the first place might not port well to platforms
where system headers make use of typedefs to any extended
type.

I am still waiting to see a list of those claimed "nasty
and subtle" incompatibilities.

But, as has been repeatedly stated, the category of "strictly
conforming" programs is completely useless, as it permits neither
floating-point use nor I/O.

That mischaracterization has been refuted several times
previously. The category of "strictly conforming program"
is *crucial* to application of the C standard, and many
instances of s.c. programs do exist and serve useful
functions.

 

[Paul Eggert]

Any program that uses at most
long int and properly casts arguments to match printf formats
is unaffected by long-long support.

C89 programs can print arbitrary size_t values by casting them to
unsigned long and then printing them with %lu. This is guaranteed to
work in C89, and many portable programs use this technique. However,
it isn't guaranteed to work in C99. You can talk about such code
being "broken in domains" all you like, but the code was portable in
C89, it's not portable in C99, and it's not portable now precisely
because C99 made an imcompatible change to the standard.

Luckily, POSIX 1003.1-2001 requires support for "unsigned long" being
wide enough to store size_t (and this requirement was put into POSIX
precisely because so many people were appalled at this incompatible
change to the C standard), so I have another ISO standard that I can
wave in implementors' faces if any of them are foolish enough to think
about breaking that particular C89 guarantee.

 

[Jarno A Wuolijoki]

Luckily, POSIX 1003.1-2001 requires support for "unsigned long" being
wide enough to store size_t (and this requirement was put into POSIX
precisely because so many people were appalled at this incompatible
change to the C standard), so I have another ISO standard that I can
wave in implementors' faces if any of them are foolish enough to think
about breaking that particular C89 guarantee.

I need the fastest type that can hold at least 32 bits. What
should I use?
long.
Is it really the fastest type that can hold at least 32 bits?
No, long is 64 bits and int is 32 bits. int is the fastest type.

 

[Douglas A. Gwyn]

C89 programs can print arbitrary size_t values by casting them to
unsigned long and then printing them with %lu. This is guaranteed to
work in C89, and many portable programs use this technique. However,
it isn't guaranteed to work in C99. You can talk about such code
being "broken in domains" all you like, but the code was portable in
C89, it's not portable in C99, and it's not portable now precisely
because C99 made an imcompatible change to the standard.

It's every bit as portable as if C99 had never been published!
Many platforms were encountering object (e.g. file) sizes that
simply could not be represented in the 32 bits that they were
using for unsigned long. Vendors were looking for solutions,
and some tried using their own extended integer types for file
sizes etc., because they had too many customers whose code was
dependent on long being 32 bits and no greater. There just
wasn't any C89 standard integer type suitable for the purpose.
When pressed to determine whether e.g. off_t could be defined
as one of these extended integer types, the C standards
committee was obliged to interpret the existing C89 wording as
sufficiently explicitly indicating that that would make the
implementation not conforming. This put implementors in the
position of having to choose between conforming to the
standard or doing what was needed to accommodate the growing
environment. Once implementations start intentionally not
conforming to the standard, it tends to go downhill to the
point that major portability problems become portable. As a
remedy for that situation, during work on C9x a lot of time
was spent in determining the best way to accommodate not only
the widespread "long long int" type (with 64 bits guaranteed
minimum width) but also other implementation-specific
extended integer types that were not ripe for standardization.
C99 reflects the outcome of these considerations and does not
require any implementation to start using types wider than
long for size_t etc. if they weren't already doing so. But
it does provide a standard method for programs to be portable
to platforms where wider types *are* used for such purposes,
something that was unavailable to programmers previously.

I am sorry that you would prefer to hamper programs and
implementations in the face of ever-increasing dataset sizes.
The C standards committee didn't think that would be wise.

 

[Douglas A. Gwyn]

#if __STDC_VERSION__ < 199901L
...
#else
#include <stdint.h>
...
#endif

I suggest just
#include "stdint.h"
You can always provide your own implementation of stdint.h
if the platform doesn't already have one. You may recall
that I even made one available on the Lysator C site many
years ago.

 

[Douglas A. Gwyn]

Twaddle.

Respond what you like. I am unsubscribing, ...

Thank goodness.

 

[Douglas A. Gwyn]

For the example I provide below, the "new domain" consists of a
third-party library's typedef that can, only because of C99, be an alias
for a type longer than 'long'. Within a pure C90 context, the code would
never have broken, no matter which integer type was chosen for the
typedef.

In fact many such typedefs in interfaces on large platforms
were already using extended integer types wider than long.
While in a C90 DR response the committee was forced to say,
by a strict reading of the rules, that none of the typedefs
in the C standard could use an extended integer type, this
didn't apply to other typedefs. Obviously there could be
problems in that regard, *which is why we addressed this in
C99*. To characterize this as a flaw in C99 is wrong; it
was actually a deficiency in C90.

PGSt_integer value = PGS_function(arguments);
printf("%ld\n", (long) value);

Works the same everywhere under the same conditions, namely
those under which the function would return a value that can
be represented in type long int. Wouldn't work anywhere
under conditions where that wasn't true.

Under C99, I can write code using uintmax_t that will also correctly
print any value PGS_function() returns, regardless of platform, across
different releases of that library. However, it's not the same code, and
it won't work on a C90 compiler.

Sure it will, since it's not dependent on any changes to the
language itself. (Contrast to "long long".) All you need to
do is to provide the missing standard header. Use the one I
put in the public domain years ago if you wish.

You failed to come up with even one example the last time you were
challenged to do so.

Wrong. I provided the very first program I laid my hands on,
which turned out to have one *bug* in that it didn't check for
argc==0, easily fixed and irrelevant to the issue of whether a
s.c. program could be a useful one.

 

[Douglas A. Gwyn]

... Once implementations start intentionally not
conforming to the standard, it tends to go downhill to the
point that major portability problems become portable.

Of course that was meant to say "become prevalent".

 

[Paul Eggert]

I am sorry that you would prefer to hamper programs and
implementations in the face of ever-increasing dataset sizes.

Apparently you misunderstood my point. Your post talked at length
about off_t, but I was referring to size_t, not off_t.

Every implementation that went through the introduction of "long long"
in the late 1980s and early 1990s -- and this was done precisely to
support "ever-increasing dataset sizes" with 64-bit architectures --
came up with a C89-compatible solution, i.e., a solution where size_t
was no wider than unsigned long. "Ever-increasing dataset sizes" thus
provided no practical justification for making such an incompatible
change to the C language.