Exceptions in C/C++

[CJ]

A conforming implementation is free to allocate a block larger than
requested; most real implementations do so. Some implementations round
upward to the next multiple of a fixed block size. Some implementations
round upward to the next power of 2.

Are you suggesting that the programmer should concern himself with the
internal implementation details of malloc()?

The only conceivable uses I can think of are:
1) the programmer has allocated some memory and needs a bit more, so
does something like

if(actually_allocated(p) >= WHAT_I_NEED_NOW)
/* do nothing! */
else
/* use realloc on p */

but in this case, if enough memory has already secretly been assigned by
malloc then the realloc() call is likely to be of negligible cost
anyway.

2) misguided attempts at bounds checking:

void some_library_function(char * mallocd_pointer, size_t index)
{
if(index >= actually_allocated(mallocd_pointer))
/* go boom */
...
}

This has two problems: a) the function can only accept a pointer
returned by malloc() ; b) if the programmer got lucky and supplied an
index that was beyond the memory he knew he had available, but which
just happened to lie inside the additional memory his particular
malloc() implementation had assigned, this would disguise the bug in his
code and likely make it extremely difficult to find and fix.

 

[Richard Tobin]

Are you suggesting that the programmer should concern himself with the
internal implementation details of malloc()?

There are circumstances where it would be useful to know more about
what is actually being allocated. For example, if you are
implementing a hash table and trying to keep a reasonable spare
capacity to avoid collisons, it might be useful to allocate X*2 bytes
for your table that would fit in in X bytes. But if the malloc()
granularity means that malloc()ing X*2 will actually allocate nearly
X*4, this might degrade rather than improve performance, when
malloc()ing X*1.9 would not.

That's a rather contrived example (and on many systems allocating the
extra space would not cost much if it wasn't accessed), but some
systems do provide a mechanism for determining "good" malloc() sizes.

-- Richard

 

[James Kuyper]

Are you suggesting that the programmer should concern himself with the
internal implementation details of malloc()?

No, I'm not advocating this change, just explaining it. Requiring an
implementation to report the actual size of an allocation is much less
of an imposition than requiring it to report the requested size.
Currently, most implementations where there is a difference between the
requested and actual size, keep no record of any kind about the
requested size. Requiring that they report the requested size would add
to the amount of information they would be required to store.

 

[Keith Thompson]

You confirm my sentence above.


You confuse this newsgroup and the C language.
IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

 

[Richard Heathfield]

Keith Thompson said:

IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between. The suggestion
that the industry has embraced C99 is laughable, and those of us (such as
myself) who have expressed apathy towards C99 have generally done so
because C99 programs cannot be considered to be widely portable, precisely
because C99 is not widely implemented.

It is up to implementors. If they want C programmers to use C99, they must
take the lead by providing implementations. Some have done so, but too
few. Until, at the very least, GNU C (i.e. gcc and glibc together) and
Microsoft C conform to C99, there is no point in using its features in
code where portability is a high priority.

 

[Ian Collins]

Keith Thompson said:

IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between. The suggestion
that the industry has embraced C99 is laughable, and those of us (such as
myself) who have expressed apathy towards C99 have generally done so
because C99 programs cannot be considered to be widely portable, precisely
because C99 is not widely implemented.

The only incentive I've seen to implement parts of C99 is POSIX
requiring them.

 

[CBFalconer]

.... snip ...

It is up to implementors. If they want C programmers to use C99,
they must take the lead by providing implementations. Some have
done so, but too few. Until, at the very least, GNU C (i.e. gcc
and glibc together) and Microsoft C conform to C99, there is no
point in using its features in code where portability is a high
priority.

Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest. Gnu will eventually get there, but the problem
is the large variety of systems to be served. It is not as easy as
revising the compiler. Not only does a customized library have to
be created, it has to be issued, and available on the destination
machine.

 

[Keith Thompson]

Keith Thompson said:

jacob navia <[email protected]> writes:

IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between.

[...]

Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they? And in which compilers?

 

[Richard Heathfield]

Keith Thompson said:

There are some C99-conforming
implementations about, but they are few and far between.

[...]

Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they?

Well, I don't know about Intel, but IBM appear to have gained C99
certification for their XL and VisualAge compilers. Other companies on the
list are Dinkumware (for their library, obviously), Edison, Lund, and Sun.

And in which compilers?

See http://www.peren.com/pages/cvsa_isocvpl.htm

The absence of Microsoft, Borland, and especially GNU from that list is
significant.

 

[santosh]

Keith Thompson said:

IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between. The
suggestion that the industry has embraced C99 is laughable, and those
of us (such as myself) who have expressed apathy towards C99 have
generally done so because C99 programs cannot be considered to be
widely portable, precisely because C99 is not widely implemented.

It is up to implementors. If they want C programmers to use C99, they
must take the lead by providing implementations. Some have done so,
but too few. Until, at the very least, GNU C (i.e. gcc and glibc
together) and Microsoft C conform to C99, there is no point in using
its features in code where portability is a high priority.

Also the fact that C itself is increasingly being used more in embedded
systems than general ones and the changes required by C99 are next to
useless for such uses. It almost as if a group of Fortran aficionados
wrote the C99 document...

 

[Nick Keighley]

Nice snipping.

did Richard heathfield do the snipping?

As usual you sneakily snip to support your own minority
views and try to get one over on Jacob. Where your need to do this comes
from is anybodies guess.

The fact is that there ARE moves to C99.

Whether you like it or not.

http://en.wikipedia.org/wiki/C_(programming_language)#Support_by_majo...

from the page:
***
Support by major compilers
GCC and other C compilers now support many of the new features of C99.
However, there has been less support from vendors such as Microsoft
and
Borland that have mainly focused on C++, since C++ provides similar
functionality improvement.

GCC, despite its extensive C99 support, is still not a completely
compliant implementation; several key features are missing or don't
work correctly
***

no complete support there then


http://www.25hoursaday.com/C99.html
***
Compiler support

After describing all the exciting new features of C99, one would
expect there to be more awareness of the standard by now but there
isn't. The primary reason for the lack of awareness of C99 is the fact
that compiler support at the current time is practically non-existent.
Here is the status of the major compiler vendors for the development
platforms that I'm interested in:
Microsoft: A search on Microsoft's site for C99 draws a total blank.
It looks like Microsoft does not plan to upgrade the C compiler that
ships with Visual C++ to cover the C99 standard.


Borland: A search on Borland's site for C99 also draws a blank. Again
it looks like exclusive C++ development has won over keeping their C
compiler up to date.


Comeau Computing: The most recent version of their compiler (version
4.2.45.1) which is available for online testing claims to support a
large number of features from C99. The compiler has not yet been
released but can be tested online by submitting code snippets in an
HTML form.


SAS Institute: SAS/C version 7.0 supports the "long long" type, inline
functions and a few of the preprocessor directives.


Edison Design Group: The EDG C++ front end supposedly supports both
C89 and C99 as well as Microsoft C++ and ANSI/ISO C++.


GNU: GCC has a status page of C99 compliance which shows that they are
quite close to becoming fully compliant with the C99 standard.

***
this undermines your claim (I'm guessing the page is quite old
(so why quote it?))



http://softwarecommunity.intel.com/articles/eng/2635.htm-
even here they don't explicitly state they are C99 compatible.
Maybe they are. That makes two compilers.

 

[santosh]

did Richard heathfield do the snipping?

this undermines your claim (I'm guessing the page is quite old
(so why quote it?))

<snip>

Here is a webpage that claims to list fully conforming C99 compilers. I
suspect the inclusion of the Intel C++ compiler in that list.

<http://geocities.com/avsharath/c99compilers.htm>

Basically, C started as a systems programming language and is once
again, presently, largely a systems programming language. For many
years it was widely used for end user applications, but C++ and Java
have increasingly encroached this segment. Given the power of modern
systems C is unlikely to be used for writing complete end user
applications for the PC market.

Given this scenario it is not hard to understand why C99 has failed so
remarkably in uptake, as compared with the earlier standard. It offers
little to systems programming and even lesser to end user application
programming. Much of the additions of C99 have to do with numerical
work, but I doubt that it is widely used in this area as well.
Certainly, very few programmers have found C99's extensions to be
indispensable or invaluable. In comparison, many of C89's
standardisations were very useful.

C99 is virtually worthless to implement for Microsoft and Borland, given
that they are advocating the use of C#/.NET, in preference to even C++.
The few compilers that have taken pains to implement the C99 standard
(for example Comeau, IBM XL, gcc etc.), have done so almost as an
altruistic afterthought. Certainly, I doubt that the sales or
popularity of their compilers would have significantly suffered if they
have completely ignored C99.

C99 is largely a failure, as the Committee seems to have not given
sufficient thought to "why" their Standard would actually be
implemented. The best thing they can do now is to not yield to "special
interest groups" and include even more features that will be
disparately implemented, but rather, be very conservative with
additions. They could perhaps consider deprecating or removing the
least implemented parts of C99, but that may be too much, as it would
break backwards compatibility. Also further efforts for compatibility
with C++ would be nice.

I think that C has pretty much evolved as much as it could. Minor
changes are ignored by many significant implementors while major
changes (like thread support or jacob's proposals), lack any consensus
to be standardised and implemented.

 

[Tor Rustad]

Keith Thompson said:

jacob navia <[email protected]> writes:

IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".
[...]

Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).

It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between.

[...]

Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they? And in which compilers?

Yes, PERENNIAL have validated IBM's C99 implementation, as they have for
Dinkum/EDG, Sun, and Lund.

http://www.peren.com/pages/cvsa_set.htm

I have not seen a similar list from Plum Hall, but my guess is that
their list of C99 validated compilers, is non-empty too.

IIRC, Intel do claim C99 conformance with the -Za switch.

 

[Richard Heathfield]

CBFalconer said:

Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest.

I agree. Hence, C99 is de facto dead in the water.

Gnu will eventually get there,

I don't share your confidence. I don't think they care enough. I think
they'll get to the point (if they haven't already) where they say "this
far we will go to accommodate the ISO folks... but NO FURTHER!", because
of conflicts where they genuinely believe that the existing GNU feature is
superior to the C99 equivalent. I suspect this has already happened. For
example, I don't suppose GNU's VLAs will ever be "fixed" to be
C99-conforming.

 

[Richard Bos]

Much of the library has to be system specific.

True, but nothing to do with his point.

You are not capable of ignoring gets() when writing software?

He, you, and I may be, but hordes of newbies are not. Obsoleting it in
C99 might not have forced them to, but it would at least given them a
hint of clue.

You could use <spammity spam>

Yes, jacob, we know. Stop advertising your warez.

Richard

 

[Kenny McCormack]

one will galvenize a few more. Of course, attempts to go off in
un-approved peculiar directions will incompatible extensions do not
help.

Aren't we the authoritrian???

 

[santosh]

True, but nothing to do with his point.


He, you, and I may be, but hordes of newbies are not. Obsoleting it in
C99 might not have forced them to, but it would at least given them a
hint of clue.

I would be surprised if a considerable amount of newbies read the
Standard. Even before gets was declared obsolescent, implementations
with respectable QoI, like gcc for example, routinely diagnosed any use
of gets.

The problem is there still exist widely used local textbooks that use
gets all over the place. Newbies tend to, understandably, put more
faith in their textbooks than obscure standard documents and people on
Usenet.

Yes, jacob, we know. Stop advertising your warez.

That was actually CBFalconer.

 

[santosh]

Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest.

Microsoft do not recommend use of C anymore at all. For system level
work (like device drivers) they recommend C++ and C#/C++/.NET for
applications.

Gnu will eventually get there, but the problem
is the large variety of systems to be served. It is not as easy as
revising the compiler. Not only does a customized library have to
be created, it has to be issued, and available on the destination
machine.

The problem is, C99 standardised several features that were simply not
used widely enough, or felt to be really all that useful, for
implementors to put in the considerable effort needed to implement all
of them. Each class of implementor has implemented a subset of their
choosing that is relevant (or perceived as relevant) to their user
base.

No one has readily accepted the entire standard, like C90 was accepted.
I think, more than anything the relative failure of C99 reflects, more
than anything, changes in the C community. C is simply not as
ubiquitous as it once was. Where it's still used, C90 seems to be
largely enough (with perhaps a vendor chosen subset of C99). In the PC
applications space, it's firmly C++ and higher up in the abstraction
ladder.

 

[pete]

santosh wrote:

I would be surprised if a considerable amount of newbies read the
Standard. Even before gets was declared obsolescent, implementations
with respectable QoI, like gcc for example,
routinely diagnosed any use of gets.

The problem is there still exist widely used local textbooks that use
gets all over the place. Newbies tend to, understandably, put more
faith in their textbooks than obscure standard documents and people on
Usenet.

There was a time when I thought that people on the net
who kept mentioning this "C standard"
(which my 1988 Turbo C Reference Guide never once mentions),
were all netloons.

 

[Chris Dollin]

Aren't we the authoritrian???

Don't you know???