C 99 compiler access

[Niklas Matthies]

On POSIX systems one can use getpagesize() or sysconf(_SC_PAGE_SIZE)
or sysconf(_SC_PAGESIZE). No idea about non-POSIX systems (or if
that concept even make sense on all of them).

Or was that a rhetoric question?

I'm not sure. I guess I wanted to point out that "all you have to
do is ..." introduces a portability problem. And just for reliably
allocating some piece of memory.

-- Niklas Matthies

 

[Dave Hansen]

Considering some of the other oddball languages they list I am surprised
they hadn't listed Forth (which on the same basis of their published
calculation method came above Prolog).

They do. Scroll down a bit. It's number 26 at 0.130%. Which puts it
ahead of Ruby, Tcl/Tk, REXX, SmallTalk and Objective-C, but below
Postscript, RPG, Scheme, and AWK.

Prolog is number 18 at 0.259%.

Regards,

-=Dave

 

[Paul D. Smith]

nm> I'm not sure. I guess I wanted to point out that "all you have
nm> to do is ..." introduces a portability problem. And just for
nm> reliably allocating some piece of memory.

Well, malloc() can't be implemented in portable C anyway of course.

Yes, if you wanted to write a 100% portable, 100% foolproof wrapper for
malloc() you wouldn't be able to make use of this capability. You can
write a reliable POSIX-portable version, though, and/or you can make a
very conservative assumption and write every 256th byte and call it
good. Heck, even if you are ridiculously conservative and write every
5th byte that's still only 20% of the effort it would take to write all
of them.

--

 

[Christian Bau]

nm> I'm not sure. I guess I wanted to point out that "all you have
nm> to do is ..." introduces a portability problem. And just for
nm> reliably allocating some piece of memory.

Well, malloc() can't be implemented in portable C anyway of course.

Yes, if you wanted to write a 100% portable, 100% foolproof wrapper for
malloc() you wouldn't be able to make use of this capability. You can
write a reliable POSIX-portable version, though, and/or you can make a
very conservative assumption and write every 256th byte and call it
good. Heck, even if you are ridiculously conservative and write every
5th byte that's still only 20% of the effort it would take to write all
of them.

Not on a modern CPU, where the number of cache lines counts, that your
code touches.

 

[Stewart Brodie]

nm> I'm not sure. I guess I wanted to point out that "all you have
nm> to do is ..." introduces a portability problem. And just for
nm> reliably allocating some piece of memory.

Well, malloc() can't be implemented in portable C anyway of course.

We're not talking about implementing malloc in portable C - it's part of the
standard library. It's reasonable to assume that the standard library will
be implemented to integrate (efficiently) with the execution environment
which will almost certainly mean an environment-specific implementation. The
concern is that library implementations are not implementing the required
semantics (although I also accept that the C library implementations may in
turn be being stymied by the environment to some extent).

Yes, if you wanted to write a 100% portable, 100% foolproof wrapper for
malloc() you wouldn't be able to make use of this capability. You can
write a reliable POSIX-portable version, though, and/or you can make a
very conservative assumption and write every 256th byte and call it good.

"Reliable on POSIX only", "very conservative". Neither of these equates to
"portable" as far as I'm concerned.

What other standard library routines would you not mind getting lies back
from? Douglas A Gwyn mentioned the file access functions in another
article. What if fopen() returned a valid non-NULL handle but then just
caused a crash when you tried to read data from it. In fact, it is quite
possible that this behaviour can occur if the C library's stdio buffering is
using malloc to allocate the buffer memory. You open the file, get a valid
handle, you're not at the end of the file, the file is buffered, you call
getc() and a crash occurs (in __filbuf or whatever the buffer filling
routine is called) because the buffer was "successfully" allocated yet the
memory wasn't actually available. If it had been told that memory wasn't
available in the first place, __filbuf (or whatever) could have disabled
buffering on the FILE stream or the fopen() could have been failed in the
first place or something.

Heck, even if you are ridiculously conservative and write every 5th byte
that's still only 20% of the effort it would take to write all of them

To be honest, the chances are that memset would be more efficient than that
on many systems (although devious implementations could end up doing
something sneaky with page mapping and copy-on-write that defeats it). But
we're talking about having to take silly, timewasting and
implementation-specific measures just to ensure that the library is
implementing the required semantics.

 

[Paul D. Smith]

sb> We're not talking about implementing malloc in portable C - it's
sb> part of the standard library.

What I'm saying is that if you WANT this behavior you can get it, even
on operating systems which use lazy allocation, by reworking the
standard library somewhat to get a malloc() that behaves as you like.
If you do that then of course your reworking does not need to be
portable.

And, you can even get it for your critical applications while leaving
other, less fortunate applications to muddle along with their unreliable
lazy malloc().

sb> "Reliable on POSIX only", "very conservative". Neither of these
sb> equates to "portable" as far as I'm concerned.

Yes, portability often struggles with practicality and reality.
Everyone draws these lines differently. I don't view "portable" as a
boolean value, although I grant that some (esp. those on comp.std.c)
do.

sb> But we're talking about having to take silly, timewasting and
sb> implementation-specific measures just to ensure that the library
sb> is implementing the required semantics.

Yes, that's what we're talking about. I suppose you'll grant that the
many systems that are designed this way aren't done just to force you to
take silly, timewasting and implementation-specific measures. The
implementation issues surrounding virtual memory are quite complex and
the arguments for and against lazy allocation make for some fascinating
reading.

--

 

[James Kuyper]

I happen to work where I have visibility of the tools people. They work
in C++ mostly. The small OS's are C

What I can't see is where the non-embedded C programs would be.

Do you have reason to believer that your 'seeing' is comprehensive? I
have no idea how much non-embedded C code there is out there. If were
to make the mistake of extrapolating from my own personal experience,
I would conclude that most of the programs in the world are
non-embedded C programs written for batch processing in a strict "C"
locale. Of course, I know that isn't true.

 

[Chris Hills]

Chris Hills wrote:
What C programming isn't embedded?
By which I mean pure C as opposed to the pseudo C people do with
C++ compilers.

When you think that anything with electricity applied to it
has a micro these days.
Autos have 50 odd each, washing machines, microwaves,
radios, mobile phones, smart cards missiles etc. etc.
That is a lot of devices that get programmed in C.

Yes, but they represent only a tiny fraction of all C programs.
Embedded [C] programmers represent
a tiny fraction of all C programmers.

based on what?

There are many thousands of embedded items with C in them. Where are
all these non embedded C programs?

There are about 14,000 packages available in the OS I use. Some of
those packages won't contain programs (but rather a lot of them
contain multiple programs); some of them aren't written in C, but my
experience is that (when I look at the source) the majority are. That
should account for at least several thousand C programs.

I think you have to miss rather a lot to ask "what C programming isn't
embedded": for all I know it might be a small minority but it's
definitely there.

I agree. My point was that virtually anything with electric power (or
batteries) has an MCU these days and 80% of them are programmed in C
(the rest is assembler with about 3% being C++).

Embedded systems are not small with a few lines of code. These days car
radios have about 1,000,000 lines of code in them. (It came as a
surprise to me too), Telecoms systems are vast, medical equipment,
controlsystems, (lifts, production lines robitocs) etc it goes on and
on.

The use of embedded systems (and C) is expanding all the time.

However on desktops and general non-embedded computing C has tended to
be replaced by C++, c# and JAva.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Paul Burke]

Considering some of the other oddball languages they list I am surprised
they hadn't listed Forth (which on the same basis of their published
calculation method came above Prolog).

Whatever happened to Modula-2?

Paul Burke

 

[Chris Hills]

s.demon.co.uk>...
...

People who work too long in one type of environment have a tendency to
forget about the other environments. That doesn't mean that they don't
exist. I work on a project which processes the data coming down from
the MODIS instruments on the Terra and Aqua satellites. We've got
about 88 "Process groups" working on this data, each of which consist
of one or more programs, and the bulk of that code is written in C,
the rest is mostly either Fortran 77 or Fortran 90. It can't be
"pseudo C" beecause we're not allowed to deliver code that needs a C++
compiler to build it.

By the way - if code is written in the common subset of C and C++, in
what sense is it "pseudo C"?

That is fine... as long as you are using all the parts of C++ that are
exactly the same as C. Some parts that are common to both AFAIK behave
differently. I forget which exactly as I have not used C++ for some
while.

A lot of people use c/C++ which is C++ that looks like C but would
behave differenty (if it compiled at all) in a pure C compiler.

I have seen a lot of people who used C/C++ what they used "almost C" in
a C++ compiler.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Paul E. Bennett]

They do. Scroll down a bit. It's number 26 at 0.130%. Which puts it
ahead of Ruby, Tcl/Tk, REXX, SmallTalk and Objective-C, but below
Postscript, RPG, Scheme, and AWK.

Prolog is number 18 at 0.259%.

Amazing how I missed seeing it. I posted to the company as well folowing my
own search with the search parameters as they described and Forth came in
above Prolog (strange).

As they declare that they ignore values that are more than twice the
previous months figures then I am sure the results will occassionally be
less than those you might obtain on a trended plot (which takes into
account at least some of the peak). Might be interesting to take ones own
month by month census. I suppose.

--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

 

[James Kuyper]

That is fine... as long as you are using all the parts of C++ that are
exactly the same as C. Some parts that are common to both AFAIK behave
differently. I forget which exactly as I have not used C++ for some
while.

With a bit of cleverness or bad luck you could write code which is
legal in both languages, but with a different meaning in each.
However, after reviewing the differences (see Annex C of the C++
standard), I think it would be pretty difficult to do so by accident.

A lot of people use c/C++ which is C++ that looks like C but would
behave differenty (if it compiled at all) in a pure C compiler.

I can't imagine why; if you're going to bother writing code that can
only be compiled correctly with C++, why wouldn't you take advantage
of the many neat features that C++ has that are incompatible with C? I
think it's much more common to write C++ that uses only a few minor
features of C++, rather than taking full advantage of the power of the
language. Such code won't compile as C code.

 

[lawrence.jones]

However on desktops and general non-embedded computing C has tended to
be replaced by C++, c# and JAva.

Not really. For new application programming, maybe (although I'd bet
that Visual Basic is far more popular in that arena than any of the
C-ish languages), but there is a *lot* of existing C code that's being
maintained and enhanced and C is still the language of choice by far for
system programming.

-Larry Jones

Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin

 

[lawrence.jones]

Whatever happened to Modula-2?

Being that Modula-2 combines the expressive power of Pascal with the
safety and security of C, do you really need to ask? ;-)

-Larry Jones

I don't think math is a science, I think it's a religion. -- Calvin

 

[Chris Hills]

s.demon.co.uk>...
...

Do you have reason to believer that your 'seeing' is comprehensive?

No but I see a lot of people involved in desktop and PC things . They
use C++ Java and C#.

Also if you look at the stats for job add that are in many computer/IT
magazines C has all but disappeared compared to C#, Jave VB, XML, Oracal
etc

I
have no idea how much non-embedded C code there is out there. If were
to make the mistake of extrapolating from my own personal experience,
I would conclude that most of the programs in the world are
non-embedded C programs written for batch processing in a strict "C"
locale. Of course, I know that isn't true.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Richard Bos]

Microsoft delivered a presentation using examples that
they have already implemented as part of their extended
C library. See
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n997.pdf
for an associated official document.
Some people have claimed that this is a proposal to lock
the C standard into a proprietary vendor product, but
that is patently false, as can be seen by reading the
proposal.

OTOH, that document is not entirely free from gratuitous non-ISOisms
(what's a __cdecl when it's at home, and where _is_ that home?). If they
can pull off a document that neither uses non-ISO constructs as a
starting point nor tries to introduce obvious M$-specific features in
the new suggestions, I'd like to see them do so, but I'm not holding my
breath.

Richard

 

[Douglas A. Gwyn]

OTOH, that document is not entirely free from gratuitous non-ISOisms
(what's a __cdecl when it's at home, and where _is_ that home?). If they
can pull off a document that neither uses non-ISO constructs as a
starting point nor tries to introduce obvious M$-specific features in
the new suggestions, I'd like to see them do so, but I'm not holding my
breath.

? You don't have to worry about WG14 using __cdecl in any
of our specs.
Anyway, our response seems largely to be to encourage the
development of Randy Meyers' proposal, which you should read.