How many levels of pointers can you have?

R

Richard Heathfield

Chris Hills said:

C90 is obsolete.

....but still widely employed.
C99 IS the standard.

....but hardly to be seen in mainstream implementations anywhere, after
almost eight years.
Most compilers do not meet the ISO C standard. Many implementations
deviated from C90 too.

Sure, but mostly in dark corners of little or no consequence.
So in REALITY you have to look at the documents to see what your C
compiler will actually do.

If we're talking REALITY, there's no point in thinking of C99 as being a
de facto standard until it actually becomes one, and there's precious
little sign of that in the REAL world.
 
C

Chris Hills

Richard Heathfield said:
Chris Hills said:



...but still widely employed.

Absolutely. The majority still use it. 9899:1990 + A1 and the two TC's
...but hardly to be seen in mainstream implementations anywhere, after
almost eight years.

Correct. In fact I think only 6 compilers actually claim full C99
implementations. The others (how many other C compilers are there? )
are C90(95) + a bit and - some bits and some extensions.
Sure, but mostly in dark corners of little or no consequence.

"Mostly" which is why you Must look at the implementation notes to
check rather than assume they adhere to C90, C90+A1, C90+A1&TC's or C99
If we're talking REALITY, there's no point in thinking of C99 as being a
de facto standard until it actually becomes one, and there's precious
little sign of that in the REAL world.

Very true. I have said several times it will be the "standard that never
was" because whilst many C compilers are creeping towards C99 by the
time they get there it will be ISO 9899:20** they actually conform to.

That said a couple of fellow members of the C panel have said that they
expect eventually the GNU CC *implementation* (not the compilers
themselves) my well become the de-facto standard.

Many commercial C compilers can also handle the GNU C syntax and
deviations from ISO C

However in the real world if you want to know the maximum depth of
pointers look at the compiler documentation for the targets you need.
The standard is irrelevant.

If you are going to spout the crap that they are not "Conforming
compilers" please restrict your comments to the 6 ( I think ) fully ISO
C compilers there are. None of which are mainstream.
 
C

Charlton Wilbur

MML> I doubt my website would "validate as compliant HTML". That's
MML> because I edit all the files in a plain text editor. It is
MML> too difficult to balance all the tags, for instance, so I
MML> don't bother.

MML> Now actually I would be a poor candidate for junior web
MML> designer, not because I couldn't do it but because I would
MML> want to do something more advanced. However you are not
MML> filtering me out for the right reason, but for an erroneous
MML> one.

Oh, no, I think you're correct in that you'd be a poor candidate for
junior web designer. You'd be filtered out for the right reason, to
wit: "it's too much work to do it correctly."

Especially since, as any seasoned web developer will tell you, if you
don't write standard HTML, it is anybody's guess why it breaks when it
breaks. It's a perfect analogue to undefined behavior in C: it may
work perfectly on your browser, and in every browser you actually test
it in, because the brokenness of your HTML triggers the right behavior
in the compiiler you happen to be using.

And when you start to add in CSS and Javascript, it gets worse.

So no, with an attitude like that you'd be filtered out right off, and
for exactly the right reason.

Charlton
 
K

Keith Thompson

Chris Hills said:
Very true. I have said several times it will be the "standard that
never was" because whilst many C compilers are creeping towards C99 by
the time they get there it will be ISO 9899:20** they actually conform
to.

That said a couple of fellow members of the C panel have said that
they expect eventually the GNU CC *implementation* (not the compilers
themselves) my well become the de-facto standard.

Is "implementation" the word you want here? I think you're saying
that the *language* (or dialect) implemented by gcc may well become
the de-facto standard.

Frankly, I hope that's not entirely true. To take just one example,
arithmetic on void*, particularly the way gcc implements it, is just
ugly (sizeof(void)==1???).
Many commercial C compilers can also handle the GNU C syntax and
deviations from ISO C

However in the real world if you want to know the maximum depth of
pointers look at the compiler documentation for the targets you
need. The standard is irrelevant.

And, as I've mentioned, the standard itself doesn't provide much
guidance here. A conforming compiler must accept 12 levels of
pointers in *some* program, but not necessarily in *your* program.
If you are going to spout the crap that they are not "Conforming
compilers" please restrict your comments to the 6 ( I think ) fully
ISO C compilers there are. None of which are mainstream.

But it is relevant to ask whether a given compiler conforms to the C90
(or C95) standard. ISO says otherwise, but in real life, the C90
standard is still very relevant, and most compilers support a mode in
which they conform to C90, modulo bugs.
 
K

Keith Thompson

Chris Hills said:
No just as pedantic as those on here who get VERY silly about
conformance. You can have it both ways.

You can? Oh good! (I suspect you meant "can't".)
Ie a local US standard.

Right. But I think the context of your statement led a lot of people
(myself included, though I didn't mention it at the time) that you
would also claim that there is no ISO C 1990, i.e., that your
statement was based on the older standard being obsolete, not on the
year being off by one. That's not what you actually wrote, of course,
but it's an understandable misreading, especially given that you
typically aren't as pedantic as some of us are.
There was unfortunately ,in my opinion, a whole section dropped.

Oh? What section was dropped? (I have a copy of the C90 standard,
but not of the official C89 standard.)
 
C

Chris Hills

Keith Thompson said:
You can? Oh good! (I suspect you meant "can't".)
Yes.

Right. But I think the context of your statement led a lot of people
(myself included, though I didn't mention it at the time) that you
would also claim that there is no ISO C 1990, i.e., that your
statement was based on the older standard being obsolete, not on the
year being off by one. That's not what you actually wrote, of course,
but it's an understandable misreading, especially given that you
typically aren't as pedantic as some of us are.

There IS an ISO C90. However it is one *officially* obsolete and
superseded by ISO9899:1999
the document exists and *WAS* the standard until 1999.

There never was an ISO C89 or to be pedantic ISO9899:1989
Oh? What section was dropped? (I have a copy of the C90 standard,
but not of the official C89 standard.)

The rational.
 
C

Chris Hills

Keith Thompson said:
Is "implementation" the word you want here? I think you're saying
that the *language* (or dialect) implemented by gcc may well become
the de-facto standard.

Yes... I though "oh bugger! That is the wrong word" after I read it back
when it had been posted.
Frankly, I hope that's not entirely true. To take just one example,
arithmetic on void*, particularly the way gcc implements it, is just
ugly (sizeof(void)==1???).

The problem is pragmatically speaking the Gcc dialect is very widely
spread. It is far more common than C99. Also there is a lot of freely
available source that uses the gcc dialect.
And, as I've mentioned, the standard itself doesn't provide much
guidance here. A conforming compiler must accept 12 levels of
pointers in *some* program, but not necessarily in *your* program.

However for many compilers they may not implement it. As there is no
legal requirement anywhere to use ISO C (ie C90- C99) compilers and as
very few do a full implementation you have the check what each one does.

For some compilers the level of nesting is difficult to do in the
architecture and as pragmatically many will not want more than 3 or 4
levels of indirection it *may* not be implemented to 12 levels.
But it is relevant to ask whether a given compiler conforms to the C90
(or C95) standard.

Yes and most do in the main but even so you have to check any deviations
from the standard. Getting high and mighty about the letter of the
standard will not save you if you do not read the limits of the compiler
you are using.

Incidentally this is why RULE 1 of MISRA-C is that you must use a fully
conforming C95 compiler. It is designed to get you to have to raise a
deviation for anything not matching the ISO C 95. Thus you have to
document and be aware of the limits (and extensions) of your compiler.

Knowing the limits of the tools you are using is far more important than
knowing chapter and verse on the ISO standard. (Which is a pity)
ISO says otherwise, but in real life, the C90
standard is still very relevant, and most compilers support a mode in
which they conform to C90, modulo bugs.

Absolutely this is why MISRA-C references C90+A1+TC1&2. In the real
world (ie not clc :) where you have to write real safety critical
programs on real hardware from 8 to 128 bit MCU's the level of
conformance, or lack of, of the "C" compiler needs to be understood and
documented.

There were some discussions as to whether MISRA-C3 should reference C99.
Any suggestions?

It really depends on where the majority of embedded compilers will be in
2 years time, If the are still C95 ish that is where MISRA-C3 will
have to be as it is pointless doing a real world standard for tools
which don't exist in the mainstream. However if the majority suddenly
rush to C99 compliance then that is where MISRA-C 3 should be,
 
R

Richard

Keith Thompson said:
Richard said:
Eric Sosman said:

<snip>

I once found myself in a most embarrassing position
as an interviewee for a post I was not qualified for (nor interested
in).
[snip]
There is a third. This is a fabricated story.

Do you intend to imply that Eric Sosman is a liar?

No. maybe a storyteller. And let Eric stick up for himself you pathetic
little man.
 
C

Chris Hills

Keith Thompson said:
Richard said:
Eric Sosman said:

<snip>

I once found myself in a most embarrassing position
as an interviewee for a post I was not qualified for (nor interested
in). [snip]
There is a third. This is a fabricated story.

Do you intend to imply that Eric Sosman is a liar?

No. maybe a storyteller. And let Eric stick up for himself you pathetic
little man.

Keith is not a pathetic little man.
You to the other hand have yet to prove yourself
 
R

Richard Heathfield

Chris Hills said:
Keith Thompson writes

The rational.

Ah, that's a shame. Never mind, though - we still have integers and
floating-point (and even complex, if you're lucky enough to have C99).
 
R

Richard Heathfield

Richard said:
Keith Thompson said:
[...]
There is a third. This is a fabricated story.

Do you intend to imply that Eric Sosman is a liar?

No. maybe a storyteller. And let Eric stick up for himself you
pathetic little man.

Like Eric Sosman, Keith Thompson has earned an excellent reputation here
in clc. Insulting him does you no more credit than does casting doubt
on Eric's honesty. That people are prepared to "stick up for" Eric
Sosman is also indicative of the significant positive contribution he
has made to this group over many years.

I am still waiting, in vain so far, for *you* to start making a
significant positive contribution to this group.
 
J

Joachim Schmitz

Chris Hills said:
Absolutely not.
Bullshit. If I have a compiler that claims to be compliant to (with?) Ansi
C89 or ISO C90, and does not support at least 12 pointers, I'd claim this a
bug in the implementation and insist on getting it fixed.
As I keep pointing out you have to check the compiler docs on each
implementation for this.
Only if I need to konw wether it supports more than the minimum required by
the standard
C90 is obsolete.
The vast majority of compilers out on the street are still only conforming
to this or ANSI C89.
C99 IS the standard.
Agreed. But mute point as there isn't much support from the compiler
vendors, unfortunatly
Most compilers do not meet the ISO C standard. Many implementations
deviated from C90 too.
Then they are not allowed to call themself compliant.
So in REALITY you have to look at the documents to see what your C
compiler will actually do.
As said earlier: only if I need stuff in excess of whatever standard the
vendor claims his compiler to comply with.

Bye, Jojo
 
K

Keith Thompson

Chris Hills said:
Keith Thompson said:
Chris Hills <[email protected]> writes:
[...]
There IS an ISO C90. However it is one *officially* obsolete and
superseded by ISO9899:1999
the document exists and *WAS* the standard until 1999.

There never was an ISO C89 or to be pedantic ISO9899:1989

Yes, I think we all know that.

[...]
The rational.

I didn't think the rationalE was actually part of the standard; I
thought it was a separate document. But in any case the rationale is
still available. (I think I used to have a copy of the C89/C90
rationale; I know I have a copy of the C99 rationale.)
 
K

Keith Thompson

Chris Hills said:
Absolutely not.

As I keep pointing out you have to check the compiler docs on each
implementation for this.

C90 is obsolete.
C99 IS the standard.

Yes, yes, we know.
Most compilers do not meet the ISO C standard. Many implementations
deviated from C90 too.

Most current compilers fail to meet the C99 standard because certain
features are not (yet) implemented. Most current compilers *do* meet
the C90 standard (officially obsolete though it may be); deviations
from C90 are typically bugs, usually minor ones, not features that
have not yet been implemented.

C90 conformance is a useful concept in the real world. If a
compiler's documentation claims that it conforms to C90, I can use my
officially obsolete copy of the C90 standard to find out how the
compiler will behave. If it fails to behave as it claims to, I can
cite the C90 standard in my bug report.

That's what a standard is for, to provide a proposed contract between
implementers and users. The C90 standard, in the current state of
affairs, happens to be more useful as such a contract than the C99
standard. (I hope to see that change someday; if gcc's C99
conformance is ever completed, that might finally provide the impetus
to make it happen.)

But you know all that.
So in REALITY you have to look at the documents to see what your C
compiler will actually do.

He didn't ask what his C compiler will actually do. He asked how many
levels of pointers C89 requires. I answered the question that he
actually asked. He could have had any number of reasons for asking
it; perhaps it was just historical curiosity. Do you object to any
discussion of the C90 standard? If so, you are (uncharacteristically)
attempting to impose a far stricter topicality standard than most of
feel is appropriate.
 
K

Keith Thompson

Joachim Schmitz said:
If I have a compiler that claims to be compliant to (with?) Ansi C89
or ISO C90, and does not support at least 12 pointers, I'd claim
this a bug in the implementation and insist on getting it fixed.

Such a lack of support violates the standard *only* if the vendor
cannot produce one single program that the compiler can successfully
translate and execute that uses 12 levels of pointers (as well as
meeting all the other enumerated limits).

Actually, the requirement is for "12 pointer, array, and function
declarators (in any combinations) modifying an arithmetic, structure,
union, or incomplete type in a declaration". An implementation that
supports no more than 4 of each could still be conforming.

Once again, the translation limits in C99 5.2.4.1 are defined *very*
narrowly. Their effect is to encourage implementations to be
reasonable, not to require them to be reasonable. A perverse
conforming implementation could specifically recognize the chosen
single program required in 5.2.4.1, and generate code equivalent to
"int main(void){}" (if the chosen program performs no I/O), and impose
much stricter limits on all other programs. Such an implementation
would not be very useful, and would likely be no easier to implement
than a more reasonable implementation. But I can imagine a vendor
using something like this technique to claim conformance on a platform
where some of the limits are difficult to satisfy.

Incidentally, this particular requirement did not change between C90
and C99.
 
C

Chris Hills

Keith Thompson said:
Chris Hills said:
Keith Thompson said:
Chris Hills <[email protected]> writes:
[...]
There IS an ISO C90. However it is one *officially* obsolete and
superseded by ISO9899:1999
the document exists and *WAS* the standard until 1999.

There never was an ISO C89 or to be pedantic ISO9899:1989

Yes, I think we all know that.

[...]
The rational.

I didn't think the rationalE was actually part of the standard;

It wasn't AFAIK
I
thought it was a separate document. But in any case the rationale is
still available. (I think I used to have a copy of the C89/C90
rationale;

The Rational was for C89. It was an ANSI working group document AFAIK it
was never an ISO document
 
C

Chris Hills

Joachim Schmitz said:
Bullshit. If I have a compiler that claims to be compliant to (with?) Ansi
C89 or ISO C90, and does not support at least 12 pointers, I'd claim this a
bug in the implementation and insist on getting it fixed.

Then you are a complete idiot who will be ignored.
Only if I need to konw wether it supports more than the minimum required by
the standard

Now that proves you are an idiot. You will never work in safety
critical or high reliability SW development with an attitude like that.
It is unprofessional and dangerous.
The vast majority of compilers out on the street are still only conforming
to this or ANSI C89.

Agreed. But mute point as there isn't much support from the compiler
vendors, unfortunatly

Why unfortunately? They are reacting to the vast majority of their
users.

A lot of the compilers use a C99 compliant front end but see no need to
make the compiler C99 compliant.

Then they are not allowed to call themself compliant.

They don't they just say they are C compilers.
As said earlier: only if I need stuff in excess of whatever standard the
vendor claims his compiler to comply with.
Bye, Jojo

They don't claim compliance. It's that simple.
 
K

Keith Thompson

Chris Hills said:
Knowing the limits of the tools you are using is far more important
than knowing chapter and verse on the ISO standard. (Which is a pity)
[...]

I agree that both are important; I don't agree that either is "far
more important" than the other.

Being familiar with the ISO C standard (not quibbling for the moment
about which one) enables me to write code that will work properly on
any conforming implementation. Finding a conforming implementation,
and verifying that it's (sufficiently) conforming, is another matter.
I can use handy extensions and/or work around deficiencies where
necesary, but the majority of my code's legality and behavior is
determined by the standard.

The standard provides a way to divide the considerable problem of
writing working code into two parts, one of which has to be done only
once.

As for knowing the limits of particular implementations, there are
other newsgroups that discuss such things (gnu.gcc.*,
comp.compilers.lcc, comp.unix.solaris, microsoft.*, etc., etc.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top