C 99 compiler access

[Dan Pop]

You mean overcomittment of virtual memory, then? The behaviour in that
case is not entirely undefined; most platforms that overcommit virtual
memory will start killing processes, but will not cause them to have
otherwise undefined behaviour.

This is no different from the behaviour of a program exceeding its
stack limit (e.g. due to using VLAs). In either case, the program gets
killed.

Dan

 

[Richard Tobin]

You mean overcomittment of virtual memory, then?
Yes.

The behaviour in that
case is not entirely undefined; most platforms that overcommit virtual
memory will start killing processes, but will not cause them to have
otherwise undefined behaviour.

True, but (on the platforms I use) the undefined behaviour resulting
from stack overflow turns out to be to kill the process (or maybe some
other process: I suspect that stack space is overcomitted in the same
way as heap space), so the practical result is that malloc is no safer
than stack-allocation.

-- Richard

 

[Dan Pop]

This may be the wrong venue in which to ask, but how many
programmers really use the GNU extensions?

Once you define the language of your project as being GNU C, you have no
good reason not to use them. Two well known such projects are the Linux
kernel and glibc v2.

To some people and projects, performance is more important than being
able to compile with a different compiler and gcc has plenty of obscure
extensions that are aimed at improving the performance of the generated
code in ways not possible in standard C.

The GNU C extensions are important enough in the Linux world that the
Intel C compiler *attempts* to be front-end compatible with gcc (i.e.
implement the same extensions with identical semantics). This
compatibility is not good enough for projects pushing the envelope as
far as possible (e.g. the Linux kernel doesn't compile out of the box
with the Intel compiler; then again it doesn't compile with *any* gcc
version, either) but it works for most software using the extensions
specified in the "Extensions to the C Language Family" chapter of the
gcc documentation.

The same chapter that should have served as a source of inspiration
to the people who elaborated the C99 standard, especially considering
that it was describing *existing practice*, which C99 was supposed
to actually standardise.

Dan

 

[Richard Tobin]

For me, the behaviour of malloc() is not the only consideration in
choosing a platform.

What, reliable execution of carefully written programs
is not important?[/QUOTE]

I assume you can see the disparity between what I said and how you
replied, but to be explicit: the behaviour of malloc() is not the only
consideration in the reliable behaviour of carefully written programs,
nor is the reliable behaviour of carefully written programs the only
consideration in choosing a platform.

-- Richard

 

[Dan Pop]

If the standard is freely available, I wasted $18. Are you referring
to the draft versions?

A Google search will reveal the availability of pirate copies of the
official standard. Whether this counts as "freely available" or not is
another issue...

Dan

 

[CBFalconer]

Once you define the language of your project as being GNU C, you
have no good reason not to use them. Two well known such projects
are the Linux kernel and glibc v2.

To some people and projects, performance is more important than
being able to compile with a different compiler and gcc has plenty
of obscure extensions that are aimed at improving the performance
of the generated code in ways not possible in standard C.

The GNU C extensions are important enough in the Linux world that
the Intel C compiler *attempts* to be front-end compatible with
gcc (i.e. implement the same extensions with identical semantics).
This compatibility is not good enough for projects pushing the
envelope as far as possible (e.g. the Linux kernel doesn't compile
out of the box with the Intel compiler; then again it doesn't
compile with *any* gcc version, either) but it works for most
software using the extensions specified in the "Extensions to the
C Language Family" chapter of the gcc documentation.

Looking at that chapters menu heading very little appears (to me)
to apply to such 'efficiency' cases. The exceptions are: * Nested
Functions:: ; * Constructing Calls:: ; * Typeof:: ; and * Return
Address::, where Nested Functions would primarily apply to
compiling Pascal and Ada, and the others seem applicable to OS
building.

Have you some specific examples where they make a measurable
difference? Such a place (in the OS) would probably have to do
with rescheduling or handling interrupts (latency). Gdb has to
come in there somewhere.

 

[Douglas A. Gwyn]

I'd use C99 language features like designated initializers at work if
all the compilers we build with supported them; but only if they *all*
did, since otherwise I'd have to come up with a workaround for
everything else and there'd be no point using the new feature in the
first place. So there is a bootstrapping problem.

Exactly. Even though there was a relative rush to
bring out C89-conforming compilers, for many years
we still had to create source code that could be
compiled on platforms that only had Reiser cpp/PCC
compilers. Thus we heavily relied on macros to
implement "impedance transformers" for function
declarations etc. and had to avoid depending too
much on features available only in C89.

Library features are easier to start using before the implementors
have all caught up as sometimes you can do your own version for
obsolete platforms.

Yes, or find somebody who has done it as open source,
for example http://www.lysator.liu.se/c/q8/

 

[Hallvard B Furuseth]

Looking at that chapters menu heading very little appears (to me)
to apply to such 'efficiency' cases. The exceptions are: * Nested
Functions:: ; * Constructing Calls:: ; * Typeof:: ; and * Return
Address::, (...)

Some others - though I have no measurements for any of them:

Labels as values looks like they could be more efficient than if or
switch statements in some cases.

'inline' is certainly useful for optimization. (That's is older than
C99, remember. Unless I've missed a part of this thread which says you
are only talking about gcc vs C99.) So are typeof & statement
expressions, which let you write macros that would otherwise be
cumbersome to deal with.

Compound literals and designated initializers make it easier to write
code which initializes things statically instead of at run-time.

Some function attributes let you inform the compiler of optimizations it
can do - like 'pure', 'const', 'malloc', maybe 'noreturn'.

More machine-specific hacking: Explicit register variables, including
global register variables, and asm statements.

The vector extension, whatever that is.

Under 'Other builtins:' At least __builtin_choose_expr,
__builtin_constant_p, __builtin_expect, __builtin_prefetch. Some are
compiler hints, others are for the programmer to provide a fast version
of some piece of code which the compiler can use in some cases.

 

[CBFalconer]

Some others - though I have no measurements for any of them:

Labels as values looks like they could be more efficient than if
or switch statements in some cases.

'inline' is certainly useful for optimization. (That's is older
than C99, remember. Unless I've missed a part of this thread
which says you are only talking about gcc vs C99.) So are typeof
& statement expressions, which let you write macros that would
otherwise be cumbersome to deal with.

Compound literals and designated initializers make it easier to
write code which initializes things statically instead of at
run-time.

I wasn't thinking about usefulness, just about things that allow
creation of more efficient code in some environment. If there is
another way to express something that allows the efficient code,
and remains standard, I see no point in the extension.

 

[Richard Bos]

Some others - though I have no measurements for any of them:

Labels as values looks like they could be more efficient than if or
switch statements in some cases.

Labels as values are a maintenance nightmare, and probably not very
optimisable, either - poof goes efficiency. I'm glad C99 doesn't include
this misfeature. C is not Sinclair Basic, after all.

'inline' is certainly useful for optimization. (That's is older than
C99, remember. Unless I've missed a part of this thread which says you
are only talking about gcc vs C99.)

And inline _is_ in C99, so what's the problem?

So are typeof & statement
expressions, which let you write macros that would otherwise be
cumbersome to deal with.

This is the only feature mentioned in this thread which C99 doesn't
have, and which I think could be useful.

Some function attributes let you inform the compiler of optimizations it
can do - like 'pure', 'const', 'malloc', maybe 'noreturn'.

And they're generally very unportable.

More machine-specific hacking: Explicit register variables, including
global register variables, and asm statements.

Machine-specific. Exactly. Nice for a compiler, _not_ good for a
Standard.

Richard

 

[Richard Kettlewell]

And inline _is_ in C99, so what's the problem?

C99 inline isn't the same as GNU C inline; IIRC they only coincide in
the 'static inline' case. So there are limits on what you can do if
you want to support both GNU C and C99.

 

[Dan Pop]

Looking at that chapters menu heading very little appears (to me)
to apply to such 'efficiency' cases.

I was mostly referring to stuff named with the __builtin prefix, some of
it not even documented in that chapter. Other features like asm() and
certain function attributes also have a significant impact on code
performance.

Dan

 

[Emlyn Corrin]

Surely this is putting the chicken before the horse.

Surely you mean the cart before the egg?

 

[Michael Wojcik]

Which makes this reply so confusing. Why are you going back and making a new
thread on this old topic.

I'm afraid you're confused, not my reply. I didn't start a new thread
(just double-checked the threading in Google Groups, and it's correct).
My reply was posted all of two days after your message, so it's hardly
old. This reply is a bit later, due to the long weekend, but still well
within the normal range for Usenet.

I responded to your last thread, but now we're getting circular here.

I fail to see this circularity. I commented on your message; you
replied and claimed you were simply being contradicted; I pointed out
that you were wrong about that as well. Neither of us returned to
arguments previously offered.

But what I'm opbjecting to is the AUTOMATIC "troll alert". Every statement
was being followed by a no-content misive (sounds like missile, get it)
"warning".

This isn't true, as Falconer already noted: he does *not* post his
"troll alert" responses to every post by Tisdale. Sometimes
Tisdale's posts are correct, and he leaves those unmolested. The
same appears to be true for anyone else posting "troll alert"
messages. There's nothing "automatic" about it.

And slightly insulting to readers;
who are "you" (not you personally, but the troll alert posters) to tell me
who's a troll. Will you tell me which books and magazines to read next?!

Now you're getting circular; this is the same argument I addressed
in my first reply to you in this thread.

Huh? I just don't want the warnings.

Try reading this again.

You wrote: "Just killfile him".

I responded: "I don't know why your think I don't want to read ERT's
posts". In other words, I don't wish to killfile him. Your assumption
that I do is invalid.

You also wrote: "the rest of us can go on listening to whomever we
choose".

I pointed out that someone else's actions have no effect on whom you
choose to read. Simple as that.

Frankly, it sounds to me like you're trying to defend a position when
your initial arguments have proven unconvincing to your audience, and
you don't have any new ones to introduce. That doesn't mean you've
"lost" (since the argument has no consequences, that's a meaningless
evaluation) or that you must change your mind, but complaining when
people reply to answer your questions or respond to your statements
is not a productive rhetorical maneuver.

Shall we summarize the situation as: you don't want to read these
"troll alerts", but you've failed to show a convincing argument why
they shouldn't be written? If that agrees with your understanding,
then we can drop this subthread.

 

[Michael Wojcik]

I know that such an implementation is badly broken.

Oh good, the lazy-allocation religious war has broken out again.

If no implementation is allowed to fail under the conditions "malloc
returns non-null and later the program tries to use the returned
memory", then no real implementations are not broken. Memory access
can fail for reasons beyond the implementation's control.

Lazy allocation has its proponents and opponents, and both have
reasonable arguments at their disposal, but this "lazy allocation
breaks conformance" one is not among them. Even if it's true (and no
one has presented a convincing proof of that, IMO), it's pointless,
since many of us have to use implementations on platforms which use
lazy allocation. If those implementations conform except in using
lazy allocation, that will have to be good enough, since there is no
alternative.

Hell, I'd like it if all the platforms I had to support were completely
free of bugs. Barring that, I can't guarantee "reliable execution of
carefully written programs" anyway. They aren't. Shall I hold off on
further development until I can "get a better platform"?

--
Michael Wojcik (e-mail address removed)

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster

 

[Richard Bos]

True, but (on the platforms I use) the undefined behaviour resulting
from stack overflow turns out to be to kill the process (or maybe some
other process: I suspect that stack space is overcomitted in the same
way as heap space), so the practical result is that malloc is no safer
than stack-allocation.

Even so, malloc() is safer, but only because you can sometimes turn
memory overcommitting off; it would be hard do that with stack
overflows.

Richard

 

[Dave Vandervies]

I believe the Dinkum effort is a library, not
a compiler. Comeau uses it.

My understading is that the Dinkum library claims conformance to the
C99 library description, the Comeau compiler claims conformance to the
C99 language description, and they play nicely together. This means
that neither is (or claims to be) a complete C99 implementation, but
the combination is.


dave

 

[Ben Pfaff]

Practical Solution #1: Kill the programmer in question. This is
also the most satisfying solution, because it ensures that the
problem will not recur. --Ben Pfaff in comp.lang.c

I really said that? Wow, I must have been having a bad day.

 

[Chris Hills]

If the standard is freely available, I wasted $18. Are you referring
to the draft versions?

It is freely available from many places.. I did not say it was free.
PC's are freely available and they are not free.

What is this obsession with having the ISO-C standard free?
DO you expect all your tools to be free?

PLEASE can we not go round this loop again!
The C standard costs a small amount of money.
An insignificant amount for any professional.
The world is not a charity.

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

 

[Chris Hills]

A Google search will reveal the availability of pirate copies of the
official standard. Whether this counts as "freely available" or not is
another issue...

Dan

No the word is Illegal.

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