How many levels of pointers can you have?
madhawi
Joachim Schmitz
news:1181148059....@z28g2000prd.googlegroups.com...
> This question is occur in interview. Please help me.
Ahh, in the Subject... don't hide it there.
>How many levels of pointers can you have?
no chapter and verse, but I believe that is implementatiion defined.
Ben Pfaff
> Subject: How many levels of pointers can you have?
>
> This question is occur in interview. Please help me.
Twelve:
5.2.4.1 Translation limits
1 The implementation shall be able to translate and execute at
least one program that contains at least one instance of
every one of the following limits:13)
[...]
- 12 pointer, array, and function declarators (in any
combinations) modifying an arithmetic, structure, union,
or incomplete type in a declaration
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008
Richard Tobin
At least 12. (See the section "Declarators" in the standard.)
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
siju
> This question is occur in interview. Please help me.
answer of course is implementation specific. if my memory is correct i
think it is 71 levels of indirection in borland turbo c++ version 3.0
compiler.
Kenneth Brody
>
> madhawi <madh...@gmail.com> writes:
>
> > Subject: How many levels of pointers can you have?
> >
> > This question is occur in interview. Please help me.
>
> Twelve:
"At least 12."
> 5.2.4.1 Translation limits
> 1 The implementation shall be able to translate and execute at
> least one program that contains at least one instance of
> every one of the following limits:13)
> [...]
> - 12 pointer, array, and function declarators (in any
> combinations) modifying an arithmetic, structure, union,
> or incomplete type in a declaration
Now _there's_ a question for the standards committee... Where did
they pick the number 12 from?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA...@gmail.com>
Ben Pfaff
> Now _there's_ a question for the standards committee... Where did
> they pick the number 12 from?
One member wanted 8, another wanted 16, they compromised on 12?
--
Ben Pfaff
http://benpfaff.org
Richard Heathfield
> Kenneth Brody <kenb...@spamcop.net> writes:
>
>> Now _there's_ a question for the standards committee... Where did
>> they pick the number 12 from?
>
> One member wanted 8, another wanted 16, they compromised on 12?
No no no. It's a committee! One member wanted 16, another wanted 16,
another wanted 16, and quite a few more wanted 16, and everybody else
also wanted 16, so they compromised on 12.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Kira
news:4667123D...@spamcop.net...
> Ben Pfaff wrote:
>>
>> madhawi <madh...@gmail.com> writes:
>>
>> > Subject: How many levels of pointers can you have?
>> >
>> > This question is occur in interview. Please help me.
>>
>> Twelve:
>
> "At least 12."
So yeah, 12 is safe everything above that is implementation defined.
I wonder if anybody ever made a non toy program with 12 levels of pointers.
Eric Sosman
> This question is occur in interview. Please help me.
One: a pointer points to its target, and that's that.
--
Eric Sosman
eso...@acm-dot-org.invalid
Chris Dollin
> Ben Pfaff wrote:
>>
>> madhawi <madh...@gmail.com> writes:
>>
>> > Subject: How many levels of pointers can you have?
>> >
>> > This question is occur in interview. Please help me.
>>
>> Twelve:
>
> "At least 12."
>
>> 5.2.4.1 Translation limits
>> 1 The implementation shall be able to translate and execute at
>> least one program that contains at least one instance of
>> every one of the following limits:13)
>> [...]
>> - 12 pointer, array, and function declarators (in any
>> combinations) modifying an arithmetic, structure, union,
>> or incomplete type in a declaration
>
> Now _there's_ a question for the standards committee... Where did
> they pick the number 12 from?
Maybe all the compilers allowed "as many as you like (until we
run out of store)", except one that had a 4-bit field for
"number of indirections" in a type with the top three values
reserved for "struct", "union", or "function pointer".
--
Speculative Faction Hedgehog
Otherface: Jena RDF/Owl toolkit http://jena.sourceforge.net/
Tor Rustad
> Now _there's_ a question for the standards committee... Where did
> they pick the number 12 from?
from C89
--
Tor <torust [at] online [dot] no>
pete
>
> madhawi <madh...@gmail.com> writes:
>
> > Subject: How many levels of pointers can you have?
> >
> > This question is occur in interview. Please help me.
>
> Twelve:
/* BEGIN new.c */
#include <stdio.h>
int main(void)
{
(************puts)("Cool!!!");
return 0;
}
/* END new.c */
--
pete
John Cochran
I have a vague memory from many years back about what I believe was a
Honeywell mainframe (36 bit words, 18 bit addressing). One of the features
of this beast was indirect addressing where if a bit was set in a word
when it was accessed, it indicated that the word should be used as an
address pointing to where the actual parameter was. And if *that* had that
magic bit set, then it was also an address pointing to where the actual
parameter was. This indirection could in theory go quite a distance. However
the computer would throw an exception if too many levels of indirection
were being used. I don't remember how many levels this was.
But given that the above feature could be used to implement pointer to pointer
to ..... in a fairly efficient C implementation. I can see a "must be able
to do at least X levels of indirection" requirement based upon the limits
of the computers with this capability.
Now this is pure speculation, but I wouldn't be surprised if there exists
a modern computer that has this indirect capability and has a limit on
how many levels of indirection it's willing to perform without causing
an exception.
Richard Tobin
John Cochran <j...@smof.fiawol.org> wrote:
>I have a vague memory from many years back about what I believe was a
>Honeywell mainframe (36 bit words, 18 bit addressing). One of the features
>of this beast was indirect addressing where if a bit was set in a word
>when it was accessed, it indicated that the word should be used as an
>address pointing to where the actual parameter was. And if *that* had that
>magic bit set, then it was also an address pointing to where the actual
>parameter was. This indirection could in theory go quite a distance. However
>the computer would throw an exception if too many levels of indirection
>were being used. I don't remember how many levels this was.
>
>But given that the above feature could be used to implement pointer to pointer
>to ..... in a fairly efficient C implementation. I can see a "must be able
>to do at least X levels of indirection" requirement based upon the limits
>of the computers with this capability.
I doubt C has ever been implemented on that architecture by setting
the relevant bit in pointers. If we have char *****p, then both **p
and ****p are legal expressions: the number of dereferences is
controlled by the program, not the data. C doesn't have a
"dereference as much as you can" operator.
>Now this is pure speculation, but I wouldn't be surprised if there exists
>a modern computer that has this indirect capability and has a limit on
>how many levels of indirection it's willing to perform without causing
>an exception.
I *would* be surprised if there was such a modern computer.
In any case, the limit in C89 - which is a limit on types, not
dereferencing of objects - most likely just reflects how some common
existing implementation handled declarations.
Keith Thompson
> madhawi <madh...@gmail.com> writes:
>
>> Subject: How many levels of pointers can you have?
>>
>> This question is occur in interview. Please help me.
>
> Twelve:
>
> 5.2.4.1 Translation limits
> 1 The implementation shall be able to translate and execute at
> least one program that contains at least one instance of
> every one of the following limits:13)
> [...]
> - 12 pointer, array, and function declarators (in any
> combinations) modifying an arithmetic, structure, union,
> or incomplete type in a declaration
Yes, but like all the limits in 5.2.4.1, it doesn't necessarily mean
very much. A conforming implementation is merely required to
translate and execute *one* program that hits all the listed limits.
Another program with 12 levels of pointers might fail to compile.
The point of the requirement, I think, is that the easiest way to
satisify it is not to have any fixed limits at all, by making the
relevant data structures within the compiler dynamic. A typical
compiler most likely won't complain about 13, or 20, or 99 levels of
pointers (unless it issues a warning).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Old Wolf
> I wonder if anybody ever made a non toy program with 12 levels of pointers.
Does this count? :)
http://groups.google.co.nz/group/alt.comp.lang.learn.c-c++/msg/6a167ce376b99b14
Richard Heathfield
That was a pretty fun thread from top to bottom.
CBFalconer
> Ben Pfaff wrote:
>> madhawi <madh...@gmail.com> writes:
>>
>>> Subject: How many levels of pointers can you have?
>>>
>>> This question is occur in interview. Please help me.
>>
>> Twelve:
>
> "At least 12."
>
>> 5.2.4.1 Translation limits
>> 1 The implementation shall be able to translate and execute at
>> least one program that contains at least one instance of
>> every one of the following limits:13)
>> [...]
>> - 12 pointer, array, and function declarators (in any
>> combinations) modifying an arithmetic, structure, union,
>> or incomplete type in a declaration
>
> Now _there's_ a question for the standards committee... Where did
> they pick the number 12 from?
I suspect a vote, about 20 years ago, long forgotten.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com
George Neuner
<kenb...@spamcop.net> wrote:
>Now _there's_ a question for the standards committee... Where did
>they pick the number 12 from?
I think they just doubled the 6 guaranteed by K&R. Studies showed
that some complicated code used 6 or more indirections but that
virtually no code used more than 10.
George
--
for email reply remove "/" from address
Malcolm McLean
"madhawi" <madh...@gmail.com> wrote in message
news:1181148059....@z28g2000prd.googlegroups.com...
> This question is occur in interview. Please help me.
>
The point is that the standard imposes some limit which is way above the
number of dereferences any paractical programmer would ever need. All
computers will eventually run out of memory if you try to impose a stupidly
large number, even if it is 4 billion.
As it stands it is rather a bad question. It tells you who knows every
irrelevant detail of the stnadard, but that only has a slight correlation to
broader abilities. However remember that the interviewer isn't really
interested in technical ability - he knows that from your CV - he wants to
find out what sort of person you are. So given that you don't know, how do
you handle that? If you can do it in a graceful and relaxed manner, but not
too arrogant - they are looking for teamworking skills, aka obedience, after
all - then you should do well.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
James Dow Allen
> I wonder if anybody ever made a non toy program
> with 12 levels of pointers.
Here's a program that uses 11 levels of pointers.
(It would have 12 but avoided the last level with
a "micro-optimization.")
http://james.fabpedigree.com/wnim.htm
Since the program was written in response
to a "non-life threatening" query in rec.puzzles,
I suppose it could be considered a "toy",
but the webpage poses a challenge: If this is
not the best way to solve the stated problem,
what is?
jamesdowallen at gmail
Richard Bos
I'd have devised a way to encode the board, perhaps in a string, perhaps
in an unsigned long long if possible, and then used a one-dimensional
table of those. That's easier to extend to larger boards, for one thing.
Richard
CBFalconer
>
> You might know you might not. The point is that the standard
> imposes some limit which is way above the number of dereferences
> any paractical programmer would ever need. All computers will
> eventually run out of memory if you try to impose a stupidly
> large number, even if it is 4 billion.
Why? All the dereference requires is to replace the pointer with
what it points to. Repeat as each '*' appears in the input. At
most this requires games with the input stream, such as counting
'*'s while advancing to the base pointer.
lawrenc...@ugs.com
>
> Now _there's_ a question for the standards committee... Where did
> they pick the number 12 from?
As I recall, that was the limit in Ritchie's original compiler and no
one ever complained that it was too small, so the committee went with
it.
-Larry Jones
Even though we're both talking english, we're not speaking the same language.
-- Calvin
Keith Thompson
> Kenneth Brody <kenb...@spamcop.net> wrote:
>> Now _there's_ a question for the standards committee... Where did
>> they pick the number 12 from?
>
> As I recall, that was the limit in Ritchie's original compiler and no
> one ever complained that it was too small, so the committee went with
> it.
>
> -Larry Jones
Somebody here said that K&R (presumably the first edition) guarantees
6 levels. I don't have my copy handy to check this, but presumably
that would match what Ritchie's original compiler supported.
Charlton Wilbur
MML> However remember that the interviewer isn't really interested
MML> in technical ability - he knows that from your CV -
Er, you haven't seen some of the resumes I've seen, then, and
subsequently interviewed the candidates with the same name at the top
of the resume. The technical ability described on the resume may have
nothing at all to do with the technical ability possessed by the
candidate, and it is an irresponsible interviewer who does not
evaluate the candidate in front of him separately from what the resume
claims.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Eric Sosman
Seconded. I once found myself in a most embarrassing position
as an interviewee for a post I was not qualified for (nor interested
in). About five minutes into the interview, after I had answered
the Nth question in a row with "I dunno," the interviewer asked me
why in the world my resume claimed expertise in this area I was so
obviously unfamiliar with. I asked to see the resume, and to my
horror discovered that my headhunter had transformed my original
into a complete fabrication: He'd left my name intact, but just
invented most of the rest. I disavowed the fiction and promptly
on the next morning fired the headhunter -- but the damage was done;
even if the firm in question had a job for which I *was* suited, I
doubt they'd have hired me after that fiasco.
There are diligent and capable headhunters out there, but there
are also some utter sleazebags. "Trust, but verify."
--
Eric Sosman
eso...@acm-dot-org.invalid
Richard Heathfield
<snip>
> I once found myself in a most embarrassing position
> as an interviewee for a post I was not qualified for (nor interested
> in). About five minutes into the interview, after I had answered
> the Nth question in a row with "I dunno," the interviewer asked me
> why in the world my resume claimed expertise in this area I was so
> obviously unfamiliar with. I asked to see the resume, and to my
> horror discovered that my headhunter had transformed my original
> into a complete fabrication: He'd left my name intact, but just
> invented most of the rest. I disavowed the fiction and promptly
> on the next morning fired the headhunter -- but the damage was done;
> even if the firm in question had a job for which I *was* suited, I
> doubt they'd have hired me after that fiasco.
One possible defence is to take your own copy of your CV to the
interview, so that you can show it to the interviewer during your
apology (which apology, by rights, the *headhunter* should be making).
I am, however, a little surprised that you got as far as the interview
stage without you yourself having found out about their requirements.
Two possibilities spring to mind - (a) a work-cultural difference
between your country and mine; (b) the headhunter was lying to *you*,
too. One cannot help but wonder what his motivation was, though. Trying
to bang Eric-shaped pegs into non-Eric-shaped holes must surely be a
losing proposition for all concerned.
For the record, if I'd been the interviewer I'd have said, "what, THE
Eric Sosman? Okay, never mind, we have THIS job for you instead..."
Eric Sosman
> [...]
> For the record, if I'd been the interviewer I'd have said, "what, THE
> Eric Sosman? Okay, never mind, we have THIS job for you instead..."
A thousand thanks, but in that long-past time I was
not yet THE Eric Sosman; I was just Eric Sosman, young and
dumb. Nowadays I'm THE Eric Sosman, senile but cunning.
--
Eric Sosman
eso...@acm-dot-org.invalid
CBFalconer
> Richard Heathfield wrote:
>
>> [...]
>> For the record, if I'd been the interviewer I'd have said, "what, THE
>> Eric Sosman? Okay, never mind, we have THIS job for you instead..."
>
> A thousand thanks, but in that long-past time I was
> not yet THE Eric Sosman; I was just Eric Sosman, young and
> dumb. Nowadays I'm THE Eric Sosman, senile but cunning.
Now, there's a sig. line!!!!
Malcolm McLean
"Charlton Wilbur" <cwi...@chromatico.net> wrote in message
news:87wsyev...@mithril.chromatico.net...
particularly true of computers. Put someone in front of an unfamiliar system
and he won't even know how to log on. That doesn't mean that within a few
days he won't be perfectly competent and productive.
Questions like "how many levels of indirection does C allow?" tell you a
little bit, but not much. Some programmers don't even use the term
"indirection", though they know what the concept means. An experienced
programmer might say "I don't know", because it is just a bit of trivia of
no real interest to anyone not actually implementing a compiler.
If people are coming to you claiming two years' experience as a C programmer
developing desktop apps with Blogg's corps, or possessing a degree in
computer studies, and seemingly now knowing basic things, then you really
need to look at what is going on. Whilst the candidate is trying to sell
himself and put a good gloss on his achievements, outright lying is
relatively rare, and in Britain at least is illegal. It could be that people
are elevating trivial exposure to something into wide experience, but then
you might be making the mistake of saying "we need someone who knows how to
log on to Unix".
James Dow Allen
> James Dow Allen <jdallen2...@yahoo.com> wrote:
> > but the webpage poses a challenge: If this is
> > not the best way to solve the stated problem,
> > what is?
>
> I'd have devised a way to encode the board, perhaps in a string, perhaps
> in an unsigned long long if possible, and then used a one-dimensional
> table of those. That's easier to extend to larger boards, for one thing.
Yes, the one-dimensional table would be a hash table.
Readability is partly in beholder's eyes, but I'll
admit my choice gave high priority to whimsy, and
speed of *writing* (this was a program I never intended
to modify further, and "better" approaches would have
taken slightly longer to write, if less time to read).
Nevertheless, many-dimension sparse arrays would seem
an obvious case where "many levels of pointers"
could get used up quickly.
I'm sure there are many examples of
foo->bar->baz
in the Unix kernel.
Since an 'indent | grep' script would be easy to
write, it might be fun to look for any examples
of
foo->bar->baz->garf->grook
in real code.
James
Johan Bengtsson
>
> Nevertheless, many-dimension sparse arrays would seem
> an obvious case where "many levels of pointers"
> could get used up quickly.
>
> I'm sure there are many examples of
> foo->bar->baz
> in the Unix kernel.
> Since an 'indent | grep' script would be easy to
> write, it might be fun to look for any examples
> of
> foo->bar->baz->garf->grook
> in real code.
>
> James
>
Ooops, do you say that there might be a compiler dependent limits to the
number of a->b->c... levels i might use in a statement? I am probably
not using 12 or more, but probably not that far off at some places...
(I have a program where I have implemented object oriented programming
in C, (I didn't use C++ because it is also at the same time a plugin
structure using windows DLL:s, and those are a real pain i C++ BTDT)
using between two and four different structs for each hierarchy level,
and reaching a function pointer in the base "class" requires one -> for
each level plus two)
Chris Hills
writes
>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>news:4667123D...@spamcop.net...
>> Ben Pfaff wrote:
>>>
>>> madhawi <madh...@gmail.com> writes:
>>>
>>> > Subject: How many levels of pointers can you have?
>>> >
>>>
>>
>> "At least 12."
>
>So yeah, 12 is safe everything above that is implementation defined.
Actually it is implementation defined anyway. Just because the standard
says 12 it does not mean there are 12. Some common architectures may not
support it.
>I wonder if anybody ever made a non toy program with 12 levels of pointers.
There will always be at least one. The world is a nanny state in many
places and it has perverted the rule of Darwin. :-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Flash Gordon
>
> "Charlton Wilbur" <cwi...@chromatico.net> wrote in message
> news:87wsyev...@mithril.chromatico.net...
>>>>>>> "MML" == Malcolm McLean <regn...@btinternet.com> writes:
>>
>> MML> However remember that the interviewer isn't really interested
>> MML> in technical ability - he knows that from your CV -
>>
>> Er, you haven't seen some of the resumes I've seen, then, and
>> subsequently interviewed the candidates with the same name at the top
>> of the resume. The technical ability described on the resume may have
>> nothing at all to do with the technical ability possessed by the
>> candidate, and it is an irresponsible interviewer who does not
>> evaluate the candidate in front of him separately from what the resume
>> claims.
>>
> Maybe that says more about the interview process than the candidate.
> That is particularly true of computers. Put someone in front of an
> unfamiliar system and he won't even know how to log on. That doesn't
> mean that within a few days he won't be perfectly competent and productive.
>
> Questions like "how many levels of indirection does C allow?" tell you a
> little bit, but not much. Some programmers don't even use the term
> "indirection", though they know what the concept means. An experienced
> programmer might say "I don't know", because it is just a bit of trivia
> of no real interest to anyone not actually implementing a compiler.
It is not a question I would ask, but I would never just answer "I don't
know."
> If people are coming to you claiming two years' experience as a C
Actually *having* X years experience does not mean that someone is any good.
> programmer developing desktop apps with Blogg's corps, or possessing a
> degree in computer studies, and seemingly now knowing basic things, then
> you really need to look at what is going on.
Whatever the candidate you need to evaluate whether they have the
ability to do the job. This includes their problem solving abilities,
learning abilities, how much they already know about appropriate
subjects and whether they will fit in as a person.
> Whilst the candidate is
> trying to sell himself and put a good gloss on his achievements,
> outright lying is relatively rare, and in Britain at least is illegal.
It has cost the company I work for money. The company I used to work for
has also let someone go within a few months. In some other countries
(no, I won't say which) it seems to be far more common and/or more
extreme based on my real world experience.
> It could be that people are elevating trivial exposure to something into
> wide experience, but then you might be making the mistake of saying "we
> need someone who knows how to log on to Unix".
My experience is that most companies are not making that mistake. I once
failed to get a job because I was "too good" despite 90% of my answers
being of the form, "well, I've not done that sort of thing before but I
would check in this sort of book and approach the problem like this",
and other interviews where the company has had my *real* CV and I've
come close to getting the job despite obviously not having some of what
they wanted.
I am in Britain.
--
Flash Gordon
Joachim Schmitz
news:V+U$jkEhMo...@phaedsys.demon.co.uk...
> In article <f476ki$ep3$1...@news1.zwoll1.ov.home.nl>, Kira <as...@n.tk> writes
>>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>>news:4667123D...@spamcop.net...
>>> Ben Pfaff wrote:
>>>>
>>>> madhawi <madh...@gmail.com> writes:
>>>>
>>>> > Subject: How many levels of pointers can you have?
>>>> >
>>>> > This question is occur in interview. Please help me.
>>>>
>>>> Twelve:
>>>
>>> "At least 12."
>>
>>So yeah, 12 is safe everything above that is implementation defined.
>
> Actually it is implementation defined anyway. Just because the standard
> says 12 it does not mean there are 12. Some common architectures may not
> support it.
it?
Bye, Jojo
Chris Hills
<nospa...@schmitz-digital.de> writes
That is what I said.
95% of the C compilers aren't fully C99 conforming anyway.
AFAIK there are only about 6 compilers in the world that are fully C99
conforming. The other 100 odd are not to a greater or lesser extent.
The practical and realistic answer is to the question it that it is
implementation dependant but that the standard says 12.
Unless and until there is a legal requirement to use a fully conforming
C compiler (to the latest ISO C standard) you with find that the ISO C
standard is a theoretical standard for compilers to aspire to but that
few actually conform to.
So you can give a theoretically accurate answer that is practically
speaking pointless.
I have never seen any "C" compiler advertised as "C-Like" or "nearly
conforming" They are just C-compilers. You have to read the docs to
check the actual spec.
Chris Dollin
> In article <f476ki$ep3$1...@news1.zwoll1.ov.home.nl>, Kira <as...@n.tk>
> writes
>>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>>news:4667123D...@spamcop.net...
>>> Ben Pfaff wrote:
>>>>
>>>> madhawi <madh...@gmail.com> writes:
>>>>
>>>> > Subject: How many levels of pointers can you have?
>>>> >
>>>> > This question is occur in interview. Please help me.
>>>>
>>>> Twelve:
>>>
>>> "At least 12."
>>
>>So yeah, 12 is safe everything above that is implementation defined.
>
> Actually it is implementation defined anyway. Just because the standard
> says 12 it does not mean there are 12.
If there are not, the implementation isn't conformant. Nothing stops
you from using a non-conforming system, just as nothing stops you
from using Fortran or Spitbol; it's just not a conforming C
implementation. That's OK as long as its not advertised as
conforming and as long as you don't expect to port conforming
code to it.
> Some common architectures may not support it.
I'm not sure what this "it" is. What do you mean here by "architecture"?
The compiler design? Sure, I can imagine writing a compiler that
wilfully limited how many levels of pointer I could have in a
declaration; but I can also imagine eating wallpaper or swimming
in vinegar.
--
Chips! Hedgehog
Notmuchhere: http://www.electrichedgehog.net/
Joachim Schmitz
> In article <f4e4mt$7sb$1...@online.de>, Joachim Schmitz
> <nospa...@schmitz-digital.de> writes
>>"Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>news:V+U$jkEhMo...@phaedsys.demon.co.uk...
>>> In article <f476ki$ep3$1...@news1.zwoll1.ov.home.nl>, Kira <as...@n.tk>
>>> writes
>>>>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>>>>news:4667123D...@spamcop.net...
>>>>> Ben Pfaff wrote:
>>>>>>
>>>>>> madhawi <madh...@gmail.com> writes:
>>>>>>
>>>>>> > Subject: How many levels of pointers can you have?
>>>>>> >
>>>>>> > This question is occur in interview. Please help me.
>>>>>>
>>>>>> Twelve:
>>>>>
>>>>> "At least 12."
>>>>
>>>>So yeah, 12 is safe everything above that is implementation defined.
>>>
>>> Actually it is implementation defined anyway. Just because the standard
>>> says 12 it does not mean there are 12. Some common architectures may not
>>> support it.
>>Less then 12? But that wouldn't be a conforming implementation then, would
>>it?
>>Bye, Jojo
>
> That is what I said.
> 95% of the C compilers aren't fully C99 conforming anyway.
Bye, Jojo
Richard Tobin
Johan Bengtsson <qwer...@hotmail.com> wrote:
>Ooops, do you say that there might be a compiler dependent limits to the
>number of a->b->c... levels i might use in a statement? I am probably
>not using 12 or more, but probably not that far off at some places...
The "12" came from the minimum limit on * in a declaration such as
int ***a;
The case of a->b->c->... is a separate question of expression complexity.
Incidentally, if we have
int ************a; /* 12 stars */
then &a has a type with 13 levels of indirection, so an implementation
has to be able to support the type of
int *************a; /* 13 stars */
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Johan Bengtsson
> The "12" came from the minimum limit on * in a declaration such as
>
> int ***a;
>
> The case of a->b->c->... is a separate question of expression complexity.
>
Chris Hills
Dollin <e...@electrichedgehog.net> writes
>Chris Hills wrote:
>
>> In article <f476ki$ep3$1...@news1.zwoll1.ov.home.nl>, Kira <as...@n.tk>
>> writes
>>>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>>>news:4667123D...@spamcop.net...
>>>> Ben Pfaff wrote:
>>>>>
>>>>> madhawi <madh...@gmail.com> writes:
>>>>>
>>>>> > Subject: How many levels of pointers can you have?
>>>>> >
>>>>> > This question is occur in interview. Please help me.
>>>>>
>>>>> Twelve:
>>>>
>>>> "At least 12."
>>>
>>>So yeah, 12 is safe everything above that is implementation defined.
>>
>> Actually it is implementation defined anyway. Just because the standard
>> says 12 it does not mean there are 12.
>
>If there are not, the implementation isn't conformant. Nothing stops
>you from using a non-conforming system,
That's good as none of them (bar a few) are fully conforming. In most
fields of C programming there are no C compilers.
>just as nothing stops you
>from using Fortran or Spitbol; it's just not a conforming C
>implementation. That's OK as long as its not advertised as
>conforming and as long as you don't expect to port conforming
>code to it.
They are just advertised as "C compilers" not ISO 989:1999 conforming C
compilers.
Chris Hills
That's irrelevant the C standard is ISO 9899:1999 all other ISO C
standards are technically obsolete.
There is no ISO C 1989.
Joachim Schmitz
Bye, Jojo
CBFalconer
>>
>> That's irrelevant the C standard is ISO 9899:1999 all other ISO
>> C standards are technically obsolete.
>>
>> There is no ISO C 1989.
>
> I doubt that, but anyway: what did ISO C 1989 require back than?
Chris is being somewhat doltish here. There never was an ISO C89
because that version was an ANSI standard. ISO took it over, did
some paragraph renumbering, and issued it otherwise unchanged as
C90.
Keith Thompson
> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
> news:Wvkvn4Ig...@phaedsys.demon.co.uk...
>> In article <f4e4mt$7sb$1...@online.de>, Joachim Schmitz
>> <nospa...@schmitz-digital.de> writes
>>>"Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>>news:V+U$jkEhMo...@phaedsys.demon.co.uk...
>>>> In article <f476ki$ep3$1...@news1.zwoll1.ov.home.nl>, Kira <as...@n.tk>
>>>> writes
>>>>>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>>>>>news:4667123D...@spamcop.net...
>>>>>> Ben Pfaff wrote:
>>>>>>>
>>>>>>> madhawi <madh...@gmail.com> writes:
>>>>>>>
>>>>>>> > Subject: How many levels of pointers can you have?
>>>>>>> >
>>>>>>> > This question is occur in interview. Please help me.
>>>>>>>
>>>>>>> Twelve:
>>>>>>
>>>>>> "At least 12."
>>>>>
>>>>>So yeah, 12 is safe everything above that is implementation defined.
>>>>
>>>> Actually it is implementation defined anyway. Just because the standard
>>>> says 12 it does not mean there are 12. Some common architectures may not
>>>> support it.
>>>Less then 12? But that wouldn't be a conforming implementation then, would
>>>it?
>>
>> 95% of the C compilers aren't fully C99 conforming anyway.
> So what does C89 require as the minmum?
12.
C90 5.2.4.1:
12 pointer, array, and function declarators (in any combinations)
modifying an arithmetic, a structure, a union, or an incomplete
type in a declaration
As in C99, an implementation is merely required to translate and
execute a single program that hits all the enumerated limits; there's
no guarantee that it can handle 12 levels in *your* program.
Richard Heathfield
> Joachim Schmitz wrote:
>> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>> In article <f4ea1s$f03$1...@online.de>, Joachim Schmitz
>>
> ... snip ...
>>>
>>> That's irrelevant the C standard is ISO 9899:1999 all other ISO
>>> C standards are technically obsolete.
>>>
>>> There is no ISO C 1989.
>>
>> I doubt that, but anyway: what did ISO C 1989 require back than?
>
> Chris is being somewhat doltish here.
That's something I never really understood - what is so doltish about
being *right*.
> There never was an ISO C89
> because that version was an ANSI standard.
So you're agreeing with Chris. Does that mean you're being doltish too?
Come on, Chuck, please don't insult people for being right.
Chris Dollin
> That's irrelevant the C standard is ISO 9899:1999 all other ISO C
> standards are
> technically
Indeed.
> obsolete.
> There is no ISO C 1989.
Historical revisionism at its finest.
--
Amused Hedgehog
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/
Richard Heathfield
> Chris Hills wrote:
>
>> That's irrelevant the C standard is ISO 9899:1999 all other ISO C
>> standards are
>
>> technically
>
> Indeed.
>
>> obsolete.
>
>> There is no ISO C 1989.
>
> Historical revisionism at its finest.
Read what he said again, more carefully. There is not now, and nor has
there ever been, an ISO C 1989. This is not historical revisionism, but
historical fact.
Richard Heathfield
<snip>
> They are just advertised as "C compilers" not ISO 989:1999 conforming
> C compilers.
The same limit applies to C90 compilers, so I don't see the point of the
distinction.
Charlton Wilbur
RH> I am, however, a little surprised that you got as far as the
RH> interview stage without you yourself having found out about
RH> their requirements. Two possibilities spring to mind - (a) a
RH> work-cultural difference between your country and mine; (b)
RH> the headhunter was lying to *you*, too. One cannot help but
RH> wonder what his motivation was, though.
I'd vote for (b). I've had some miserable experiences with
recruiters; in one case, the employer was willing to offer $20,000 a
year less than the salary that the recruiter had offered me. I
discovered this in the interview, and in the end it turned out I would
have been almost comically overqualified for the job.
I've also had similar experiences to Eric Sosman; this is why I insist
on sending out my resume *only* as a PDF, and why I insist on emailing
a copy to the company myself before any interview.
I've found, too, that recruiters have a really tenuous grasp on
geography; I had one pursuing me about a year ago for a job coding web
services in Java on Windows, approximately 200 miles from where I
live. When I explained that (a) I had no programming experience with
Java; (b) my last experience with programming on the Windows platform
was in approximately 1993; and (c) I intended neither to relocate nor
commute 200 miles a day, she insisted repeatedly that this was the
opportunity of a lifetime for me. Someone else's lifetime, perhaps!
Charlton Wilbur
>>> I doubt that, but anyway: what did ISO C 1989 require back
>>> than?
>> Chris is being somewhat doltish here.
RH> That's something I never really understood - what is so
RH> doltish about being *right*.
The doltishness is not in being right; the doltishness is in
recognizing that the question is about what C89 requires, and instead
of saying "ISO C was standardized in 1990, so it's ISO C90," and then
answering the question, pretending that the querent is an idiot for
not realizing that he should have asked about ANSI C 1989 or ISO C
1990.
Charlton Wilbur
MMcL> If people are coming to you claiming two years' experience
MMcL> as a C programmer developing desktop apps with Blogg's
MMcL> corps, or possessing a degree in computer studies, and
MMcL> seemingly now knowing basic things, then you really need to
MMcL> look at what is going on. Whilst the candidate is trying to
MMcL> sell himself and put a good gloss on his achievements,
MMcL> outright lying is relatively rare, and in Britain at least
MMcL> is illegal. It could be that people are elevating trivial
MMcL> exposure to something into wide experience, but then you
MMcL> might be making the mistake of saying "we need someone who
MMcL> knows how to log on to Unix".
Most of the time, it's been people who overestimate their level of
ability. They know a few buzzwords and think they're experts.
The last position I interviewed candidates for was that of a junior
web designer. The idea was to find someone who understood HTML, CSS,
and a little bit of design, and could take a design and turn it into a
webpage. We got around 30 resumes.
My favorite interview question with that lot was "Why doesn't <site
from your portfolio> validate as compliant HTML?" Now, the correct
answers are "Huh? What's that?" and "We had a constraint that made it
prohibitively expensive." Only two candidates answered correctly; one
the former, one the latter. The rest tried to explain to me that
standards compliance didn't matter, or that because Dreamweaver spit
out the HTML and it worked in Internet Explorer *of course* it was
valid, and the W3C validator was just Wrong. And this was for a job
posting that talked about standards-compliant web design explicitly.
(We hired the one who answered "huh? what's that?" -- on the theory
that it would be easier to train someone who was honest about what he
didn't know than someone who was prepared to cover up his ignorance
with a line of bafflegab.)
Morris Dovey
| (We hired the one who answered "huh? what's that?" -- on the theory
| that it would be easier to train someone who was honest about what
| he didn't know than someone who was prepared to cover up his
| ignorance with a line of bafflegab.)
Interesting story! Coincidentally, some of my most interesting
projects have been those I made honest efforts to back away from - on
the basis of insufficient knowledge - and ended up being hired by
people who had determined that the lack would not be a serious
obstacle. To my considerable surprise, they were all correct.
(Probably worth mentioning that they were first-level project managers
and not HR types.)
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/
Joachim Schmitz
news:lnlketr...@nuthaus.mib.org...
Bye, Jojo
Malcolm McLean
>>>>>> "MMcL" == Malcolm McLean <regn...@btinternet.com> writes:
>
> MMcL> If people are coming to you claiming two years' experience
> MMcL> as a C programmer developing desktop apps with Blogg's
> MMcL> corps, or possessing a degree in computer studies, and
> MMcL> seemingly now knowing basic things, then you really need to
> MMcL> look at what is going on. Whilst the candidate is trying to
> MMcL> sell himself and put a good gloss on his achievements,
> MMcL> outright lying is relatively rare, and in Britain at least
> MMcL> is illegal. It could be that people are elevating trivial
> MMcL> exposure to something into wide experience, but then you
> MMcL> might be making the mistake of saying "we need someone who
> MMcL> knows how to log on to Unix".
>
> Most of the time, it's been people who overestimate their level of
> ability. They know a few buzzwords and think they're experts.
>
> The last position I interviewed candidates for was that of a junior
> web designer. The idea was to find someone who understood HTML, CSS,
> and a little bit of design, and could take a design and turn it into a
> webpage. We got around 30 resumes.
>
> My favorite interview question with that lot was "Why doesn't <site
> from your portfolio> validate as compliant HTML?" Now, the correct
> answers are "Huh? What's that?" and "We had a constraint that made it
> prohibitively expensive."
>
all the files in a plain text editor. It is too difficult to balance all the
tags, for instance, so I don't bother.
Since I use a very conservative subset of HTML, it is unlikely to break on
any browser, and it seems OK in all I've used. If it does break in someone's
wonderful new whizzy effort that's a pity, but it will only be one or two
people.
So the correct answer in my case is "the standards don't matter [enough]".
If it was a departmental rather than a personal site, this wouldn't be
acceptable. They have to use CSS and the like. However for a personal site,
the priority is that I can put pages up easily and edit them easily. And it
works, I've got the fifth most popular site at Leeds University.
Now actually I would be a poor candidate for junior web designer, not
because I couldn't do it but because I would want to do something more
advanced. However you are not filtering me out for the right reason, but for
an erroneous one.
Chris Dollin
> Chris Dollin said:
>
>> Chris Hills wrote:
>>
>>> That's irrelevant the C standard is ISO 9899:1999 all other ISO C
>>> standards are
>>
>>> technically
>>
>> Indeed.
>>
>>> obsolete.
>>
>>> There is no ISO C 1989.
>>
>> Historical revisionism at its finest.
>
> Read what he said again, more carefully. There is not now, and nor has
> there ever been, an ISO C 1989. This is not historical revisionism, but
> historical fact.
Oops.
--
Egged Hedgehog
Meaning precedes definition.
BiGYaN
> Ben Pfaff <b...@cs.stanford.edu> writes:
> > madhawi <madhaw...@gmail.com> writes:
>
> >> Subject: How many levels of pointers can you have?
>
> >> This question is occur in interview. Please help me.
>
> > Twelve:
>
> > 1 The implementation shall be able to translate and execute at
> > least one program that contains at least one instance of
> > every one of the following limits:13)
> > [...]
> > - 12 pointer, array, and function declarators (in any
> > combinations) modifying an arithmetic, structure, union,
> > or incomplete type in a declaration
>
> Yes, but like all the limits in 5.2.4.1, it doesn't necessarily mean
> very much. A conforming implementation is merely required to
> translate and execute *one* program that hits all the listed limits.
> Another program with 12 levels of pointers might fail to compile.
>
> The point of the requirement, I think, is that the easiest way to
> satisify it is not to have any fixed limits at all, by making the
> relevant data structures within the compiler dynamic. A typical
> compiler most likely won't complain about 13, or 20, or 99 levels of
> pointers (unless it issues a warning).
>
> --
> Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
Thanks for the info Keith .... I did not know all these.
Chris Hills
Dollin <e...@electrichedgehog.net> writes
There are many pedants on here trying to be holier than thou about C
conformance but play fast and loose with what standard C is. They
include K&R, ANSI, ISO and CD's
I made a comment that due to implementation there many not be 12 levels
of pointers. Getting stupid and saying "it is not C" is pointless. As I
pointed out 95% of the worlds C compilers do not conform the standard.
Being a pedant to the theoretical standards is pointless. Reality is
different.
Chris Hills
There is no ISO C89
The first one was ISO 9899:1990
>but anyway: what did ISO C 1989 require back than?
Nothing there saw no ISO C89
Please get the basics right before you post.
Chris Hills
<cbfal...@yahoo.com> writes
>Joachim Schmitz wrote:
>> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>> In article <f4ea1s$f03$1...@online.de>, Joachim Schmitz
>>
>... snip ...
>>>
>>> That's irrelevant the C standard is ISO 9899:1999 all other ISO
>>> C standards are technically obsolete.
>>>
>>> There is no ISO C 1989.
>>
>> I doubt that, but anyway: what did ISO C 1989 require back than?
>
>Chris is being somewhat doltish here.
No just as pedantic as those on here who get VERY silly about
conformance. You can have it both ways.
> There never was an ISO C89
>because that version was an ANSI standard.
Ie a local US standard.
>ISO took it over, did
>some paragraph renumbering, and issued it otherwise unchanged as
>C90.
There was unfortunately ,in my opinion, a whole section dropped.
Chris Hills
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.
Most compilers do not meet the ISO C standard. Many implementations
deviated from C90 too.
So in REALITY you have to look at the documents to see what your C
compiler will actually do.
Richard
> 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). About five minutes into the interview, after I had answered
>> the Nth question in a row with "I dunno," the interviewer asked me
>> why in the world my resume claimed expertise in this area I was so
>> obviously unfamiliar with. I asked to see the resume, and to my
>> horror discovered that my headhunter had transformed my original
>> into a complete fabrication: He'd left my name intact, but just
>> invented most of the rest. I disavowed the fiction and promptly
>> on the next morning fired the headhunter -- but the damage was done;
>> even if the firm in question had a job for which I *was* suited, I
>> doubt they'd have hired me after that fiasco.
>
> One possible defence is to take your own copy of your CV to the
> interview, so that you can show it to the interviewer during your
> apology (which apology, by rights, the *headhunter* should be making).
>
> I am, however, a little surprised that you got as far as the interview
> stage without you yourself having found out about their requirements.
> Two possibilities spring to mind - (a) a work-cultural difference
> between your country and mine; (b) the headhunter was lying to *you*,
> too. One cannot help but wonder what his motivation was, though. Trying
> to bang Eric-shaped pegs into non-Eric-shaped holes must surely be a
> losing proposition for all concerned.
There is a third. This is a fabricated story.
You don't "fire headhunters".
Headhunters come and find you. It's why they are called Head Hunters.
No competent "Headhunter" who is looking for a specialist would do this
CV manipulation.
1) They lose all credibility
2) They would inform the candidate about the companies needs
If "headhunter" is bigging up the name for a placing agent then fair
enough - those rats would do anything for a quick placement.
>
> For the record, if I'd been the interviewer I'd have said, "what, THE
> Eric Sosman? Okay, never mind, we have THIS job for you instead..."
--
Richard Heathfield
<snip>
> 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.
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> 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>
>> I am, however, a little surprised that you got as far as the
>> interview stage without you yourself having found out about their
>> requirements. Two possibilities spring to mind
<snip>
> There is a third. This is a fabricated story.
I see no reason to doubt Eric Sosman's word. *He* has earned a solid
reputation here.
Chris Hills
<r...@see.sig.invalid> writes
>Chris Hills said:
>
><snip>
>
>> C90 is obsolete.
>
>...but still widely employed.
Absolutely. The majority still use it. 9899:1990 + A1 and the two TC's
>> C99 IS the standard.
>
>...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.
>> 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.
"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
>> 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.
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.
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.
CBFalconer
> Keith Thompson <k...@mib.org> wrote:
>
... snip ...
>>
>>* --
>>* Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
>>* San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
>>* "We must do something. This is something. Therefore, we must do this."
>>* -- Antony Jay and Jonathan Lynn, "Yes Minister"
>
> Thanks for the info Keith .... I did not know all these.
PLEASE at least snip sigs. That is the part following the "-- "
marker, and delineated above with '*'s. After that you hopefully
will learn to snip more.
Keith Thompson
[...]
> 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.
Keith Thompson
> In article <466AE4DE...@yahoo.com>, CBFalconer
> <cbfal...@yahoo.com> writes
>>Joachim Schmitz wrote:
>>> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>>> In article <f4ea1s$f03$1...@online.de>, Joachim Schmitz
>>>
>>... snip ...
>>>>
>>>> That's irrelevant the C standard is ISO 9899:1999 all other ISO
>>>> C standards are technically obsolete.
>>>>
>>>> There is no ISO C 1989.
>>>
>>> I doubt that, but anyway: what did ISO C 1989 require back than?
>>
>>Chris is being somewhat doltish here.
>
> 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".)
>> There never was an ISO C89
>>because that version was an ANSI standard.
>
> 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.
>>ISO took it over, did some paragraph renumbering, and issued it
>>otherwise unchanged as C90.
>
> 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.)
Keith Thompson
[...]
>> 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).
> There is a third. This is a fabricated story.
Do you intend to imply that Eric Sosman is a liar?
Chris Hills
<ks...@mib.org> writes
>Chris Hills <ch...@phaedsys.org> writes:
>> In article <466AE4DE...@yahoo.com>, CBFalconer
>> <cbfal...@yahoo.com> writes
>>>Joachim Schmitz wrote:
>>>> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
>>>>> In article <f4ea1s$f03$1...@online.de>, Joachim Schmitz
>>>>
>>>... snip ...
>>>>>
>>>>> That's irrelevant the C standard is ISO 9899:1999 all other ISO
>>>>> C standards are technically obsolete.
>>>>>
>>>>> There is no ISO C 1989.
>>>>
>>>> I doubt that, but anyway: what did ISO C 1989 require back than?
>>>
>>>Chris is being somewhat doltish here.
>>
>> 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".)
Yes.
>>> There never was an ISO C89
>>>because that version was an ANSI standard.
>>
>> 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 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
>>>ISO took it over, did some paragraph renumbering, and issued it
>>>otherwise unchanged as C90.
>>
>> 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.)
The rational.
Chris Hills
<ks...@mib.org> writes
>Chris Hills <ch...@phaedsys.org> writes:
>[...]
>> 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.
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.
>> 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.
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.
>> 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.
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,
Richard
> Richard <rgr...@gmail.com> writes:
> [...]
>>> 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.
Richard Heathfield
> Keith Thompson writes
>>Chris Hills writes:
>>> CBFalconer writes
<snip>
>>>>otherwise unchanged as C90.
>>>
>>> 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.)
>
> 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).
Chris Hills
Keith is not a pathetic little man.
You to the other hand have yet to prove yourself
Richard Heathfield
> Keith Thompson <ks...@mib.org> writes:
>
>> Richard <rgr...@gmail.com> writes:
>> [...]
<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.
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.
Joachim Schmitz
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
Keith Thompson
> In article <lnwsybq...@nuthaus.mib.org>, Keith Thompson
> <ks...@mib.org> writes
>>Chris Hills <ch...@phaedsys.org> 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.
[...]
>>> 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.)
>
> 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.)
Keith Thompson
> In article <f4g63e$k6n$1...@online.de>, Joachim Schmitz
> <nospa...@schmitz-digital.de> writes
>>"Keith Thompson" <ks...@mib.org> schrieb im Newsbeitrag
>>news:lnlketr...@nuthaus.mib.org...
>>> "Joachim Schmitz" <nospa...@schmitz-digital.de> writes:
>>>> So what does C89 require as the minmum?
>>>
>>> 12.
>>>
>>> C90 5.2.4.1:
>>>
>>> 12 pointer, array, and function declarators (in any combinations)
>>> modifying an arithmetic, a structure, a union, or an incomplete
>>> type in a declaration
>>Thanks! Finaly a useful answer to what I meant to ask...
>
>
> 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.
Keith Thompson
> 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.
Keith Thompson
> 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.)
Chris Hills
>Chris Hills <ch...@phaedsys.org> writes:
>> In article <lnwsybq...@nuthaus.mib.org>, Keith Thompson
>> <ks...@mib.org> writes
>>>Chris Hills <ch...@phaedsys.org> 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.
>
>[...]
>
>>>> 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.)
>>
>> 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
Chris Hills
Then you are a complete idiot who will be ignored.
>> 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
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.
>> 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
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.
>> Most compilers do not meet the ISO C standard. Many implementations
>> deviated from C90 too.
>Then they are not allowed to call themself compliant.
They don't they just say they are C compilers.
>> 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
They don't claim compliance. It's that simple.
Chris Hills
<ks...@mib.org> writes
Generally true. However many 8 bit compilers do not always have the full
feature set for C90.
>C90 conformance is a useful concept in the real world.
I agree totally. It is the practical C standard in use.
>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.
However the documentation for the compiler will usually tell you where
the compiler differs from the standard. If they have stated that in the
manual when you send in your "bug report" they will refer you back to
the page in the manual and close the report.
If it were a certified Ada compiler you would have a point. There is no
such thing as a Certified C compiler in the same way.
There are validation reports for C compilers but these document the
differences between the compiler and the C standard (usually C90) and
how the compilers fair on various test suites including things like
Paranoia. (Which is floating point and nothing to do with the C
standard.
>That's what a standard is for, to provide a proposed contract between
>implementers and users.
Sort of correct.. A "proposed" language spec. NOT a contract. The
contractual spec is the one in the compiler spec. the spec you need to
read to see the actual compiler limits.
> The C90 standard, in the current state of
>affairs, happens to be more useful as such a contract than the C99
>standard.
I agree.
> (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.)
I doubt it. Besides by the time the majority get close to C99 compliance
it will be C20** I expect.
Many commercial compilers use C99 complaint front ends. It is just that
the seen no need to rush to make the whole compiler c99 compliant.
>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.
NO he did NOT. What he asked was :- "How many levels of pointers can you
have?"
No reference was made to ANY c standard or any compiler or environment.
The ONLY answer is:
"12 in the standard but you have to check your compiler to see what they
have actually implemented."
> He could have had any number of reasons for asking
>it; perhaps it was just historical curiosity.
No he stated that it was
"This question is occur in interview. Please help me. "
You have no idea if they were discussing C in general, Standard C (which
standard) , a particular compiler or environment.
If the discussion was PIC12 the answer probably will not be 12
> Do you object to any
>discussion of the C90 standard?
Not at all. It is the most widely used standard
>If so, you are (uncharacteristically)
>attempting to impose a far stricter topicality standard than most of
>feel is appropriate.
No. I said you have to check the compiler docs.
Default User
> "Chris Hills" <ch...@phaedsys.org> schrieb im Newsbeitrag
> news:0dIHrfES...@phaedsys.demon.co.uk... >
Why don't you two learn how to trim your damn quotes?
Brian
Chris Hills
<ks...@mib.org> writes
>Chris Hills <ch...@phaedsys.org> writes:
>[...]
>> 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.
I would always put knowing the tools above the standard. But then I do a
lot with safety critical Sw so I have to know exactly how the compiler
and other tools will behave.
>Being familiar with the ISO C standard (not quibbling for the moment
>about which one)
Fair enough
> 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.
Agreed. Also much Sw does not need to be portable. In fact more I know
of is not. .
>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.
Then there will be quiet a few areas where you can't work. Also not all
departures from the standard are deficiencies Many architecture
specific extensions.
>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.
I take your point. This can work in some area.
>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.)
Yes. However the question was "I was asked in an interview who many
levels of indirection can you have." Without context the answer is
undefined in reality.
Drop into comp.arch.embedded or comp.realtime some time
Richard Heathfield
<snip>
> 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)
It is not always possible, when writing a C program or library, to know
which tools will be used to compile it, let alone the limits of those
tools. I often find myself in this position. In such circumstances, the
limits of the tools are more or less irrelevant from the C programmer's
perspective, since they are unknowable.
>> 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.
I don't know what makes you think clc isn't part of the real world.
>
> There were some discussions as to whether MISRA-C3 should reference
> C99. Any suggestions?
Why bother? Almost nobody uses it. Why reference an almost unused
standard? I can see why you might want to refer to C99 in, say, a
tutorial - just to make people aware that it exists and broadly what
its features are - but otherwise it seems pretty pointless.
> 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.
You make my point nicely.
> However if the majority
> suddenly rush to C99 compliance then that is where MISRA-C 3 should
> be,
...but how likely is that?
Dave Vandervies
Keith Thompson <ks...@mib.org> wrote:
>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.
Exercise for the language lawyers:
If this script, on a system where it was able to execute successfully,
had its implementation-defined behavior defined and had a documented
program exercising all of the minimum translation requirements for which
the "translation" is correct, would it be a conforming C implementation?
Why or why not?
--------
#!/bin/sh
if [ -z "$1" ]; then
echo Usage: $0 filename
exit 0
fi
echo This program may contain a syntax error or constraint violation.
cp /bin/true a.out
--------
(V guvax, ohg unira'g irevsvrq, gung nyy V/B (vapyhqvat reebe ercbegvat)
vf nyybjrq gb snvy; vs na vzcyrzragngvba xabjf guvf jvyy unccra, gur nf-vs
ehyr fubhyq nyybj vg gb bcgvzvmr nyy fvqr-rssrpgf njnl, qvfpneq gur erghea
inyhr sebz znva, naq yrnir gur hfre jvgu n cebtenz erqhprq gb n ab-bc.
V oryvrir vg snvyf gb unaqyr #reebe qverpgvirf pbeerpgyl, gubhtu.)
dave
(it would obviously fail on every QoI measure except possibly speed, but...)
--
Dave Vandervies dj3v...@csclub.uwaterloo.ca
Surprise your compiler. Write better code than it asks you to.
--Keith Thompson in comp.lang.c
Keith Thompson
> In article <ln1wgjp...@nuthaus.mib.org>, Keith Thompson
> <ks...@mib.org> writes
>>Chris Hills <ch...@phaedsys.org> writes:
>>> In article <lnwsybq...@nuthaus.mib.org>, Keith Thompson
>>> <ks...@mib.org> writes
>>>>Chris Hills <ch...@phaedsys.org> writes:
[...]
>>>>
>>>>Oh? What section was dropped? (I have a copy of the C90 standard,
>>>>but not of the official C89 standard.)
>>>
>>> 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
If it was a working group document, then it was't an ANSI standard
either, and it wasn't actually "dropped". And, as i said, it was
available; since it's non-normative, it doesn't matter much whether
it's published by ISO or not.
Richard Tobin
Malcolm McLean <regn...@btinternet.com> wrote:
>I doubt my website would "validate as compliant HTML". That's because I edit
>all the files in a plain text editor. It is too difficult to balance all the
>tags, for instance, so I don't bother.
If by "not balancing all the tags" you mean omitting some start and
end tags, that may be perfectly valid. Unlike XML, SGML (of which
HTML is supposed to be an example) allows many shortcuts in that
respect for the benefit of human authors.
On the other hand, if you mean things like badly-nested elements such as
<x>some<y>random</x>stuff</y>
then it's not valid.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Keith Thompson
> In article <lnwsybo...@nuthaus.mib.org>, Keith Thompson
> <ks...@mib.org> writes
>>Chris Hills <ch...@phaedsys.org> writes:
>>> In article <f4g63e$k6n$1...@online.de>, Joachim Schmitz
>>> <nospa...@schmitz-digital.de> writes
>>>>"Keith Thompson" <ks...@mib.org> schrieb im Newsbeitrag
>>>>news:lnlketr...@nuthaus.mib.org...
>>>>> "Joachim Schmitz" <nospa...@schmitz-digital.de> writes:
>>[...]
>>>>>> So what does C89 require as the minmum?
>>>>> 12.
>>>>> C90 5.2.4.1:
>>>>> 12 pointer, array, and function declarators (in any combinations)
>>>>> modifying an arithmetic, a structure, a union, or an incomplete
>>>>> type in a declaration
>>>>Thanks! Finaly a useful answer to what I meant to ask...
>>> Absolutely not.
[snip]
>>> 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.
>
> NO he did NOT. What he asked was :- "How many levels of pointers can
> you have?"
Please pay attention; you even quoted the question that I answered.
The *original poster* asked "How many levels of pointers can you
have?". (I didn't attempt to answer that question.)
Later in the thread, Joachim Schmitz (who is not the OP) asked:
So what does C89 require as the minmum?
That's the question I answered. The answer is 12.
Old Wolf
> Er, you haven't seen some of the resumes I've seen, then, and
> subsequently interviewed the candidates with the same name at the top
> of the resume. The technical ability described on the resume may have
> nothing at all to do with the technical ability possessed by the
> candidate
I've been told that this is endemic in American
culture, and someone even tried to argue once
that if you did NOT lie on your resumé then you
were behaving irrationally.
Flash Gordon
> Chris Hills said (in a reply to Keith Thompson):
<snip>
>> There were some discussions as to whether MISRA-C3 should reference
>> C99. Any suggestions?
>
> Why bother? Almost nobody uses it. Why reference an almost unused
> standard? I can see why you might want to refer to C99 in, say, a
> tutorial - just to make people aware that it exists and broadly what
> its features are - but otherwise it seems pretty pointless.
<snip>
I my opinion it depends on how much clout the MISRA group has. If they
can effectively force the compiler writers for the chips used in their
domain to conform to C99 then them doing so would be a good thing in my
opinion. However, if the compiler vendors will just ignore it then MISRA
should stick to C95. After all, I don't want my car failing because the
code used a C99 feature that was not properly implemented by the compiler!
--
Flash Gordon
CBFalconer
> Keith Thompson wrote:
>
... snip ...
>
>> 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.
But you are not stuck with it. "-W -Wall -ansi -pedantic" converts
gcc into a standard C compiler. As I suspect you know.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer
> Keith Thompson <ks...@mib.org> writes
>
... snip ...
>
>> (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.)
>
> I doubt it. Besides by the time the majority get close to C99
> compliance it will be C20** I expect.
>
> Many commercial compilers use C99 complaint front ends. It is
> just that the seen no need to rush to make the whole compiler
> c99 compliant.
I believe the major problem is updating all those libraries.
Charlton Wilbur
OW> I've been told that [resume padding] is endemic in American
OW> culture, and someone even tried to argue once that if you did
OW> NOT lie on your resumé then you were behaving irrationally.
There are so many people inflating their resumes that the resume of
someone who has not done the same will look anemic by comparison.
On the other hand, my resume is entirely truthful and includes
information on where I'm willing to work, and I can count on one or
two emails a week from recruiters who want me to work jobs I'm not
qualified for in geographically infeasible areas. I suspect the
resume-padding has gotten to such a point that nobody is reading them
at all any longer, and it has become some sort of ritual signalling
like peacock tail feathers.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Dave Vandervies
Charlton Wilbur <cwi...@chromatico.net> wrote:
>>>>>> "OW" == Old Wolf <old...@inspire.net.nz> writes:
>
> OW> I've been told that [resume padding] is endemic in American
> OW> culture, and someone even tried to argue once that if you did
> OW> NOT lie on your resumé then you were behaving irrationally.
>
>There are so many people inflating their resumes that the resume of
>someone who has not done the same will look anemic by comparison.
I have a significantly higher ratio of job offers to job interviews than
most people I know.
This is mostly because I have trouble getting interviews when looking for
a job; most places where I've been interviewed have seemed to be impressed
with me. I have, on more than one occasion, been discussing this and
said something like "Maybe I need to lie more on my resume", and I've
found it disturbing how many people treat that as a serious suggestion.
(For the curious, a lightly edited version of the resume that got
me my current job is at <http://www.eskimo.com/~dj3vande/resume/>.
Compare with <http://www.seebs.net/res-p.html>.)
dave
--
Dave Vandervies dj3v...@csclub.uwaterloo.ca
Well, let's be fair to the lusers here. The human brain was invented at least
a couple of tens of millenia ago, and they haven't mastered that yet, either.
Telephones are way beyond their league. --Richard Bos in the SDM
Morris Dovey
| In article <87sl8zt...@mithril.chromatico.net>,
| Charlton Wilbur <cwi...@chromatico.net> wrote:
||||||| "OW" == Old Wolf <old...@inspire.net.nz> writes:
||
||| I've been told that [resume padding] is endemic in American
||
|| There are so many people inflating their resumes that the resume of
|| someone who has not done the same will look anemic by comparison.
|
| I have a significantly higher ratio of job offers to job interviews
| than most people I know.
| This is mostly because I have trouble getting interviews when
| looking for a job; most places where I've been interviewed have
| seemed to be impressed with me. I have, on more than one occasion,
| been discussing this and said something like "Maybe I need to lie
| more on my resume", and I've found it disturbing how many people
| treat that as a serious suggestion. (For the curious, a lightly
| edited version of the resume that got
| me my current job is at <http://www.eskimo.com/~dj3vande/resume/>.
| Compare with http://www.seebs.net/res-p.html.)
I can see that I've been going about this all wrong. I think I'd best
attack http://www.iedu.com/mrd/mrd_res1.html with an axe and sprinkle
in a bit of humor.
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/