Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #94447 > unrolled thread

Most important aspect of any compiler (C or otherwise)

Back to article view | Back to comp.lang.c

Contents

  Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 11:02 -0700
    Re: Most important aspect of any compiler (C or otherwise) John Gordon <gordon@panix.com> - 2016-10-04 19:00 +0000
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 12:08 -0700
        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-04 21:56 +0200
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:06 -0700
        Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-04 21:29 +0100
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:46 -0700
            Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-05 00:30 +0100
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 16:58 -0700
                Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-05 01:07 +0000
              Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 08:07 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 11:51 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 14:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 14:25 -0700
                      Re: Most important aspect of any compiler (C or otherwise) "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-05 18:03 -0700
                        Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 18:13 -0700
                          Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:08 -0700
                            Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:18 -0700
                              Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:31 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:43 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-05 22:22 -0400
                        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-06 09:56 +0200
                          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 04:54 -0700
                            Re: Most important aspect of any compiler (C or otherwise) mark.bluemel@gmail.com - 2016-10-06 05:06 -0700
                              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:27 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:32 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 19:12 -0700
        Re: Most important aspect of any compiler (C or otherwise) Ian Collins <ian-news@hotmail.com> - 2016-10-05 13:42 +1300
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 04:53 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 05:04 -0700
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 05:12 -0700
    Re: Most important aspect of any compiler (C or otherwise) Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-10-07 15:02 -0700
      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-07 16:17 -0700
        Re: Most important aspect of any compiler (C or otherwise) luser droog <luser.droog@gmail.com> - 2016-10-07 18:11 -0700
          Re: Most important aspect of any compiler (C or otherwise) James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:53 -0400
            Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:12 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:05 -0700
                Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 10:15 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 02:17 -0700
              Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-08 11:02 +0000
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 05:14 -0700
                Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 12:20 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 15:31 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 15:58 -0700
                      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 17:46 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:09 -0700
            Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 14:49 -0700
              Re: Most important aspect of any compiler (C or otherwise) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-09 11:12 -0400
        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-07 21:15 -0400
          Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:02 -0700
            Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 06:04 -0400
              Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 11:45 +0100
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:57 -0400
                  Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:25 +0100
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:29 -0400
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 07:49 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 08:04 -0700
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:58 -0400
                  Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 14:42 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 15:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 19:27 -0400
                      Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 16:37 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:30 -0400
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-07 18:31 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#94595

Kenny McCormack, if you ever pass through Indianapolis, IN in your
travels, drop me an email.  There's a well known deli here called Shapiro's.
We could meet there for a meal and you could come to know the real-life
Rick rather than the perceived Rick from an interpreted-through-static-
text-version-of-Rick online.

I think you'll find I am not quite like you perceive, and that your
perceptions of me are influenced by prior experiences you've had.
I am a basic person.  I like Star Trek (all except JJ Abrams' reboot universe,
what was he thinking?), Keith Rucker's VintageMachinery.org channel
on YouTube, wooden boats (Tips From a Shipwright channel on
YouTube), playing music (guitar, piano), Blender 3D artwork and animations,
driving through the country, working on cars, doing crafts projects, watching
movies, learning about new products and technologies, etc.
I subject these interests to Jesus Christ, so I avoid unholy aspects
within them.  I edit movies and TV shows to remove certain parts,
and I avoid things which are profane.

I am just like other people with diverse interests and abilities, but what
makes me different than some other people is that I have been saved,
and because of that I see things differently, as by God's guidance.  It
stands in stark contrast to worldly ways because what I tell you is true:
There's an active enemy at work in this world deceiving man into
believing and following lies, and his power exists upon an influence
of the flesh because of sin.  Once Jesus takes a person's sin away, his
power is broken and we are set free.  God then takes it upon Himself
to begin teaching us everything we'll receive.

I think if we could meet you'd find I'm awkward in speech at first,
fumbling over what to say because my mind's racing on new encounters,
that I'm funny and witty, creative and expressive over time, and that I've
come to believe in something real, not a fantasy or imagination.

It just takes an honest pursuit of the truth to see and receive.

-----
I extend this offer to others as well.  We have an International airport
and are a common hub for flights.  If any of you would like to honestly
meet up sometime, I'd enjoy meeting you.  You'd get to see the fragile
Rick of real life.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#94613

On Saturday, October 8, 2016 at 12:02:32 PM UTC+1, Kenny McCormack wrote:
> In article <09e74b5b-93b0-411e-a752-97e64bd42734@googlegroups.com>,
> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> 
> >Whilst the project isn't entirely trivial, it's not really "interesting",
> >the standard is just a human construct, it's subject to fairly regular
> >revision, and it's not designed for the purpose of preventing useless
> >but conforming implementations. 
> 
> Which is kinda the same thing as when people insist that the Bible is
> literally true, exact in all its particulars, except, of course, when it
> isn't, and/or when it either says something that is manifestly silly or
> something that is inconvenient to the speaker's agenda.
> 
> This all true, given the high regard and worshipful stance the regs here
> have taken towards the standard.
> 
Hmm.

Maybe you should have a look at the Jewish exegete, Rashi. Rashi
attached great importance to the fact that an early line of the Bible,
usually translated

"And it was even and it was morning, the first day"

is in Hebrew

veohi erev veohi boker, yom echad.

"And it was even and it was morning, a single day"
(or maybe "day one", "a day", but not "the first day" which 
would  be "yom rishon").

one day: According to the sequence of the language of the chapter, 
it should have been written, “the first day,” as it is written 
regarding the other days, “second, third, fourth.” Why did Scripture
write“one” ? Because the Holy One, blessed be He, was the only one 
in His world, for the angels were not created until the second day. 
[i.e., יוֹם אֶחָד is understood as ‘the day of the only One’] So is it 
explained in Genesis Rabbah (3:8).

Virtually all the commentary is like that, it picks up little
bits of slightly surprising grammar and assigns mystical significance
to them.

So is Rashi barking up totally the wrong tree, or is he right? 
How would you decide? And would you apply a similar analysis to
the C standard?

 

[toc] | [prev] | [next] | [standalone]

#94628

On Saturday, October 8, 2016 at 2:20:40 PM UTC-5, Malcolm McLean wrote:
> "And it was even and it was morning, a single day"

> one day: According to the sequence of the language of the chapter, 
> it should have been written, “the first day,” as it is written 
> regarding the other days, “second, third, fourth.” Why did Scripture
> write“one” ?

By what name was Queen Elizabeth I generally called during her lifetime, or
indeed at any time prior to the coronation of Queen Elizabeth II?  While I
hadn't realized just how far back the linguistic convention of calling
things "first" only when there is a "second" goes, I don't see any reason
to attach any significance beyond that.

> And would you apply a similar analysis to the C standard? 

I think the proper way to read the C89 Standard is to look at what problems
the authors of the Standard were trying to solve, and what they did to solve
those problems.  Prior to C89, the normal interpretation of "C" would be
"A language which behaves the way Dennis Ritchie's C compiler would behave,
adapted to the extent necessary for any particular target platform".

On platforms like common microcomputers whose natural semantics were very
close to those of the PDP-11, C compilers were expected to behave similarly.
On platforms with things like ones'-complement arithmetic, however, things
were far less clear.  If a machine's natural arithmetic instructions operate
mod 262,143, for example, should "unsigned int" be an 18-bit type which wraps
with an odd modulus, or should be be a 17-bit type with a bit of padding?
Either approach would be reasonable, but if some C compilers used one and
some used the other, it would be impossible for such a machine to meaningfully
run "standard C".

Consequently, the C89 Standard focuses on issues where it would be plausible
that an implementer facing a choice without the Standard might decide to do
something contrary to what the authors of the Standard felt should be
expected (e.g. having an unsigned types whose modulus is not a power of two).
There was no reason to mandate that on two's-complement machines the expression
x<<y should multiply x by a power of 2 whenever the arithmetically-correct
result would be representable (whether x is positive or negative) given that
every single two's-complement implementation ever made had been doing that
and there was no reason to expect one to do otherwise.

I don't know what roles were played by the members of C89 who were absent
in C99, but the authors of C99 seem to have presumed that anything which was
not mandated in C89 was never a useful feature of the language, even if 99%
or for that matter 100% of implementations to date had behaved the same way.
Many aspects of the Standard would need to be reworded to support such a
reading, but such rewording has never taken place.

[toc] | [prev] | [next] | [standalone]

#94633

On Saturday, October 8, 2016 at 11:32:00 PM UTC+1, supe...@casperkitty.com wrote:
> On Saturday, October 8, 2016 at 2:20:40 PM UTC-5, Malcolm McLean wrote:
> > "And it was even and it was morning, a single day"
> 
> > one day: According to the sequence of the language of the chapter, 
> > it should have been written, “the first day,” as it is written 
> > regarding the other days, “second, third, fourth.” Why did Scripture
> > write“one” ?
> 
> By what name was Queen Elizabeth I generally called during her lifetime, 
> or indeed at any time prior to the coronation of Queen Elizabeth II? 
>

            TO 
        THE MOST HIGH, 
          MIGHTIE 
            and 
         MAGNIFICENT 
       EMPRESSE RENOVV- 
     MED FOR PIETIE, VER- 
     TVE, AND ALL GRATIOVS 
   GOVERNMENT ELIZABETH BY 
   THE GRACE OF GOD QVEENE 
   OF ENGLAND FRAVNCE AND 
    IRELAND AND OF VIRGI- 
    NIA, DEFENDOVR OF THE 
     FAITH, &. HER MOST 
      HVMBLE SERVANT 
      EDMVND SPENSER 
      DOTH IN ALL HV- 
       MILITIE DEDI- 
         CATE, PRE- 
           SENT 
    AND CONSECRATE THESE 
    HIS LABOVRS TO LIVE 
      VVITH THE ETERNI- 
        TIE OF HER   
          FAME.

> While I hadn't realized just how far back the linguistic convention
> of calling things "first" only when there is a "second" goes, I don't 
> see any reason to attach any significance beyond that.
> 
It is a bit odd, however. Most English translations have "the first 
day". You're right that when it was created, there was no second,
so it was not then the "first".
>
> > And would you apply a similar analysis to the C standard? 
> 
> I think the proper way to read the C89 Standard is to look at 
> what problems the authors of the Standard were trying to solve, 
> and what they did to solve those problems.  Prior to C89, the 
> normal interpretation of "C" would be
> "A language which behaves the way Dennis Ritchie's C compiler 
> would behave, adapted to the extent necessary for any particular 
> target platform".
> 
That's how languages usually start of course. You've got an informal
specification or description of what you want to achieve, knock
it up, then the behaviour of the compiler becomes the language 
definition. That's why you often get slightly different dialects, it's
always easier to write your own than to make sure you conform to
someone else's spec.
>
> On platforms like common microcomputers whose natural semantics 
> were very close to those of the PDP-11, C compilers were expected 
> to behave similarly.
> On platforms with things like ones'-complement arithmetic, however, 
> things were far less clear.  If a machine's natural arithmetic
> instructions operate mod 262,143, for example, should "unsigned int" 
> be an 18-bit type which wraps with an odd modulus, or should be be a 
> 17-bit type with a bit of padding?
> Either approach would be reasonable, but if some C compilers used 
> one and some used the other, it would be impossible for such a machine 
> to meaningfully run "standard C".
> 
> Consequently, the C89 Standard focuses on issues where it would 
> be plausible that an implementer facing a choice without the Standard
>  might decide to do something contrary to what the authors of the Standard
> felt should be expected (e.g. having an unsigned types whose modulus 
> is not a power of two).
> There was no reason to mandate that on two's-complement machines the
> expression
> x<<y should multiply x by a power of 2 whenever the arithmetically-correct
> result would be representable (whether x is positive or negative) 
> given that every single two's-complement implementation ever made had 
> been doing that and there was no reason to expect one to do otherwise.
> 
The problem is that you can't really legislate for new technology 
which hasn't been invented yet. No modern computer has analogue 
registers, for example, but there's no real reason to think that
they might not become common at some future date, if electronics
goes in that direction. Even something as simple as the introduction
of 64 bit machines caused a problem - previously int was the "natural
register size", which meant 16 bits if you had 64k memory /segments
and 32 bits if you had 4Gb. But on a 64 bit machine, most integers
are very low, and the code to load a half word is often more efficient
than the code to load a word. So what's the natural size now?

 

[toc] | [prev] | [next] | [standalone]

#94643

On Saturday, October 8, 2016 at 5:58:15 PM UTC-5, Malcolm McLean wrote:
> On Saturday, October 8, 2016 at 11:32:00 PM UTC+1, supercat wrote:
> > I think the proper way to read the C89 Standard is to look at 
> > what problems the authors of the Standard were trying to solve, 
> > and what they did to solve those problems.  Prior to C89, the 
> > normal interpretation of "C" would be
> > "A language which behaves the way Dennis Ritchie's C compiler 
> > would behave, adapted to the extent necessary for any particular 
> > target platform".
> > 
> That's how languages usually start of course. You've got an informal
> specification or description of what you want to achieve, knock
> it up, then the behaviour of the compiler becomes the language 
> definition. That's why you often get slightly different dialects, it's
> always easier to write your own than to make sure you conform to
> someone else's spec.

The main sources of problems were either with (1) platforms where it wasn't
clear how things should behave, or (2) features which got added, in slightly
different forms, in different implementations (the most common problems being
with standard library functions inhabiting different headers in different
implementations).  For aspects of the original which coincided with target
hardware features there really wasn't much ambiguity.

> The problem is that you can't really legislate for new technology 
> which hasn't been invented yet. No modern computer has analogue 
> registers, for example, but there's no real reason to think that
> they might not become common at some future date, if electronics
> goes in that direction. Even something as simple as the introduction
> of 64 bit machines caused a problem - previously int was the "natural
> register size", which meant 16 bits if you had 64k memory /segments
> and 32 bits if you had 4Gb. But on a 64 bit machine, most integers
> are very low, and the code to load a half word is often more efficient
> than the code to load a word. So what's the natural size now?

If the Standard describes an optional-but-recommended feature which becomes
expensive to support, it can prescribe a replacement which is better but
cheaper and deprecate the earlier form.  Code which needs the feature can
then be migrated to the new form in a clear and orderly fashion.

If the Standard instead pretends that the feature does not exist, then
implementations which want to provide the functionality but not in the
expensive fashion will have to formulate their own ways of supporting
it--thus negating the purpose of having a standard in the first place.

[toc] | [prev] | [next] | [standalone]

#94602

On Saturday, October 8, 2016 at 5:18:08 AM UTC-4, Malcolm McLean wrote:
> On Saturday, October 8, 2016 at 4:53:53 AM UTC+1, James Kuyper wrote:
> > On 10/07/2016 09:11 PM, luser droog wrote:
> > 
> > I've sometimes considered the idea of writing a fully conforming but
> > completely useless implementation of C, primarily for making the point
> > that the requirements for full conformance are a lot weaker than many
> > people think (including some of the people who had a role in creating
> > those requirements).
> > Creating a useless implementation would be a lot simpler than writing a
> > useful implementation, but (because #error directives have to be handled
> > correctly) it requires correctly implementing all of translation phases
> > 1-4, which is sufficiently complicated to make the project interesting.
> >
> Very geeky thing to do, in the bad sense of the term.
> 
> Whilst the project isn't entirely trivial, it's not really "interesting",

To me, it would be. I've never implemented a compiler, and don't have the time I'd need to implement a useful one. I don't have the time I'd need to implement a useless one, either - but it comes closer to being something I could find time for - purely as a recreational activity, of course.

[toc] | [prev] | [next] | [standalone]

#94625

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I've sometimes considered the idea of writing a fully conforming but
> completely useless implementation of C, primarily for making the point
> that the requirements for full conformance are a lot weaker than many
> people think (including some of the people who had a role in creating
> those requirements).
> Creating a useless implementation would be a lot simpler than writing a
> useful implementation, but (because #error directives have to be handled
> correctly) it requires correctly implementing all of translation phases
> 1-4, which is sufficiently complicated to make the project interesting.

I've thought about doing the same thing.

You don't need to implement phases 1-4 -- just re-use an existing
preprocessor.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94667

On 10/08/2016 05:49 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> I've sometimes considered the idea of writing a fully conforming but
>> completely useless implementation of C, primarily for making the point
>> that the requirements for full conformance are a lot weaker than many
>> people think (including some of the people who had a role in creating
>> those requirements).
>> Creating a useless implementation would be a lot simpler than writing a
>> useful implementation, but (because #error directives have to be handled
>> correctly) it requires correctly implementing all of translation phases
>> 1-4, which is sufficiently complicated to make the project interesting.
>
> I've thought about doing the same thing.
>
> You don't need to implement phases 1-4 -- just re-use an existing
> preprocessor.

What I was thinking about was designing one from scratch; I'd learn more 
that way. Reusing an existing preprocessor would render the exercise too 
simple to be of interest - but it would have the advantage of making the 
project small enough that I might plausibly someday be able to find time 
to do it..

[toc] | [prev] | [next] | [standalone]

#94580

On 10/7/2016 7:17 PM, supercat@casperkitty.com wrote:
> On Friday, October 7, 2016 at 5:02:34 PM UTC-5, Anand Hariharan wrote:
>> What do folks consider as *Most* important feature of a compiler? (my emphasis)
>>
>> I suppose standard conformance would come out top in this group?
> 
> Predictable and logical support for features of the target platform.
> 
> Since it's possible for an implementation to be conforming and yet
> incapable of running any useful programs, and since limited platforms
> may be better served by a compiler that deviates from the Standard than
> one which adheres to it perfectly, I don't see rigid standards conformance
> as being particularly valuable in and of itself.
> 

Your fault is in thinking it is impossible for an implementation to be
conforming yet incapable of running any useful programs.

That is a false conjecture, so the rest of your post is immaterial.  It
is perfectly possible for an implementation to be conforming and product
useful programs.  In fact, if the implementation is strictly conforming,
it will be required to be able to produce useful programs.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#94586

On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
> On 10/7/2016 7:17 PM, supercat wrote:
> > Since it's possible for an implementation to be conforming and yet
> > incapable of running any useful programs, and since limited platforms
> > may be better served by a compiler that deviates from the Standard than
> > one which adheres to it perfectly, I don't see rigid standards conformance
> > as being particularly valuable in and of itself.
> 
> Your fault is in thinking it is impossible for an implementation to be
> conforming yet incapable of running any useful programs.

The Implementation Limits section of the Standard requires that for every
implementation there must exist at least one program which exercises all
of the implementation limits described in the Standard, and which that
implementation will process without UB.  The rationale makes very clear
that the Standard does not require that an implementation be capable of
running all such programs, since a program which exercised all limitations
simultaneously would require over a megabyte of storage, and many computers
in 1989 weren't that big.  The stated intention in the rationale is that
someone who is trying to make a useful implementation which doesn't get
tripped up by any of the limits in isolation will likely produce an
implementation that can accommodate them in useful combinations, but the
Standard doesn't actually mandate that an implementation be capable of
running more than one possibly-contrived program.

[toc] | [prev] | [next] | [standalone]

#94591

On 10/8/2016 4:02 AM, supercat@casperkitty.com wrote:
> On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
>> On 10/7/2016 7:17 PM, supercat wrote:
>>> Since it's possible for an implementation to be conforming and yet
>>> incapable of running any useful programs, and since limited platforms
>>> may be better served by a compiler that deviates from the Standard than
>>> one which adheres to it perfectly, I don't see rigid standards conformance
>>> as being particularly valuable in and of itself.
>>
>> Your fault is in thinking it is impossible for an implementation to be
>> conforming yet incapable of running any useful programs.
> 
> The Implementation Limits section of the Standard requires that for every
> implementation there must exist at least one program which exercises all
> of the implementation limits described in the Standard, and which that
> implementation will process without UB.  The rationale makes very clear
> that the Standard does not require that an implementation be capable of
> running all such programs, since a program which exercised all limitations
> simultaneously would require over a megabyte of storage, and many computers
> in 1989 weren't that big.  The stated intention in the rationale is that
> someone who is trying to make a useful implementation which doesn't get
> tripped up by any of the limits in isolation will likely produce an
> implementation that can accommodate them in useful combinations, but the
> Standard doesn't actually mandate that an implementation be capable of
> running more than one possibly-contrived program.
> 

The Standard requires a conforming implementation must process all
conforming programs.  If it does not, it is not a conforming implementation.

Hardware limitations such as memory limits are not part of the Standard.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#94593

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 10/8/2016 4:02 AM, supercat@casperkitty.com wrote:
>> On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
>>> On 10/7/2016 7:17 PM, supercat wrote:
>>>> Since it's possible for an implementation to be conforming and yet
>>>> incapable of running any useful programs, and since limited platforms
>>>> may be better served by a compiler that deviates from the Standard than
>>>> one which adheres to it perfectly, I don't see rigid standards conformance
>>>> as being particularly valuable in and of itself.
>>>
>>> Your fault is in thinking it is impossible for an implementation to be
>>> conforming yet incapable of running any useful programs.
>> 
>> The Implementation Limits section of the Standard requires that for every
>> implementation there must exist at least one program which exercises all
>> of the implementation limits described in the Standard, and which that
>> implementation will process without UB.  The rationale makes very clear
>> that the Standard does not require that an implementation be capable of
>> running all such programs, since a program which exercised all limitations
>> simultaneously would require over a megabyte of storage, and many computers
>> in 1989 weren't that big.  The stated intention in the rationale is that
>> someone who is trying to make a useful implementation which doesn't get
>> tripped up by any of the limits in isolation will likely produce an
>> implementation that can accommodate them in useful combinations, but the
>> Standard doesn't actually mandate that an implementation be capable of
>> running more than one possibly-contrived program.
>> 
>
> The Standard requires a conforming implementation must process all
> conforming programs.  If it does not, it is not a conforming
> implementation.

Either you have that backwards or you are confusing a conforming program
with a /strictly/ conforming program.  Section 4 defines the term
"conforming program":

  7.  A conforming program is one that is acceptable to a conforming
      implementation.

The same section defines a conforming (hosted) implementation as one the
must accept any strictly conforming program.

So here's a counter-example -- a conforming program that a conforming
implementation is not obliged to accept:

  int main(void) { return -1 >> 1, 0; }

> Hardware limitations such as memory limits are not part of the Standard.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94622

On 10/8/2016 6:45 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 10/8/2016 4:02 AM, supercat@casperkitty.com wrote:
>>> On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
>>>> On 10/7/2016 7:17 PM, supercat wrote:
>>>>> Since it's possible for an implementation to be conforming and yet
>>>>> incapable of running any useful programs, and since limited platforms
>>>>> may be better served by a compiler that deviates from the Standard than
>>>>> one which adheres to it perfectly, I don't see rigid standards conformance
>>>>> as being particularly valuable in and of itself.
>>>>
>>>> Your fault is in thinking it is impossible for an implementation to be
>>>> conforming yet incapable of running any useful programs.
>>>
>>> The Implementation Limits section of the Standard requires that for every
>>> implementation there must exist at least one program which exercises all
>>> of the implementation limits described in the Standard, and which that
>>> implementation will process without UB.  The rationale makes very clear
>>> that the Standard does not require that an implementation be capable of
>>> running all such programs, since a program which exercised all limitations
>>> simultaneously would require over a megabyte of storage, and many computers
>>> in 1989 weren't that big.  The stated intention in the rationale is that
>>> someone who is trying to make a useful implementation which doesn't get
>>> tripped up by any of the limits in isolation will likely produce an
>>> implementation that can accommodate them in useful combinations, but the
>>> Standard doesn't actually mandate that an implementation be capable of
>>> running more than one possibly-contrived program.
>>>
>>
>> The Standard requires a conforming implementation must process all
>> conforming programs.  If it does not, it is not a conforming
>> implementation.
> 
> Either you have that backwards or you are confusing a conforming program
> with a /strictly/ conforming program.  Section 4 defines the term
> "conforming program":
>

No confusion at all.

>   7.  A conforming program is one that is acceptable to a conforming
>       implementation.
> 
> The same section defines a conforming (hosted) implementation as one the
> must accept any strictly conforming program.
> 
> So here's a counter-example -- a conforming program that a conforming
> implementation is not obliged to accept:
> 
>   int main(void) { return -1 >> 1, 0; }
> 

I never said it was obliged to accept it.

>> Hardware limitations such as memory limits are not part of the Standard.
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#94640

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 10/8/2016 6:45 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>> The Standard requires a conforming implementation must process all
>>> conforming programs.  If it does not, it is not a conforming
>>> implementation.
>> 
>> Either you have that backwards or you are confusing a conforming program
>> with a /strictly/ conforming program.  Section 4 defines the term
>> "conforming program":
>>
>
> No confusion at all.
>
>>   7.  A conforming program is one that is acceptable to a conforming
>>       implementation.
>> 
>> The same section defines a conforming (hosted) implementation as one the
>> must accept any strictly conforming program.
>> 
>> So here's a counter-example -- a conforming program that a conforming
>> implementation is not obliged to accept:
>> 
>>   int main(void) { return -1 >> 1, 0; }
>> 
>
> I never said it was obliged to accept it.

You said the standard requires it to be processed.  Can you tell me what
that means?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94647

On 10/8/2016 8:25 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 10/8/2016 6:45 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
> <snip>
>>>> The Standard requires a conforming implementation must process all
>>>> conforming programs.  If it does not, it is not a conforming
>>>> implementation.
>>>
>>> Either you have that backwards or you are confusing a conforming program
>>> with a /strictly/ conforming program.  Section 4 defines the term
>>> "conforming program":
>>>
>>
>> No confusion at all.
>>
>>>   7.  A conforming program is one that is acceptable to a conforming
>>>       implementation.
>>>
>>> The same section defines a conforming (hosted) implementation as one the
>>> must accept any strictly conforming program.
>>>
>>> So here's a counter-example -- a conforming program that a conforming
>>> implementation is not obliged to accept:
>>>
>>>   int main(void) { return -1 >> 1, 0; }
>>>
>>
>> I never said it was obliged to accept it.
> 
> You said the standard requires it to be processed.  Can you tell me what
> that means?
> 

Sorry, Ben, if you don't know, I'm not going to continue.  I've already
learned not to try to discuss the standards with you.  It's a complete
waste of time, just like teaching a pig to sing.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#94599

On Saturday, October 8, 2016 at 6:05:14 AM UTC-4, Jerry Stuckle wrote:
> On 10/8/2016 4:02 AM, supercat@casperkitty.com wrote:
> > On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
> >> On 10/7/2016 7:17 PM, supercat wrote:
> >>> Since it's possible for an implementation to be conforming and yet
> >>> incapable of running any useful programs, ...
...
> >> Your fault is in thinking it is impossible for an implementation to be
> >> conforming yet incapable of running any useful programs.

You're responding to a paragraph in which he expressed, very clearly, the exact opposite of the thought you've just accused him of believing. He said "possible", while you said "impossible" - the wording is otherwise identical. I won't claim to know whether he's particularly honest or sane, but if you're going to accuse him of believing the exact opposite of what he's clearly said, you should provide some supporting evidence.
 
> > The Implementation Limits section of the Standard requires that for every
> > implementation there must exist at least one program which exercises all
> > of the implementation limits described in the Standard, and which that
> > implementation will process without UB.  The rationale makes very clear
> > that the Standard does not require that an implementation be capable of
> > running all such programs, since a program which exercised all limitations
> > simultaneously would require over a megabyte of storage, and many computers
> > in 1989 weren't that big.  The stated intention in the rationale is that
> > someone who is trying to make a useful implementation which doesn't get
> > tripped up by any of the limits in isolation will likely produce an
> > implementation that can accommodate them in useful combinations, but the
> > Standard doesn't actually mandate that an implementation be capable of
> > running more than one possibly-contrived program.
> > 
> 
> The Standard requires a conforming implementation must process all
> conforming programs.  If it does not, it is not a conforming implementation.

The standard imposes no such requirement. The requirements which it does impose that bear the greatest similarity to that non-existent requirement are the following:

"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:" (5.2.4.1p1). That one program, which could be different for every implementation, is the only program for which any such requirement applies.

"A conforming hosted implementation shall accept any strictly conforming program." (4p6). The standard does not define the meaning of "accept" that applies in this context. Therefore, the definition is either provided by ISO/IEC 2382−1:1993 (3p1), or by ordinary English usage in the context of computer programming. ISO 2382 is too expensive for me to justify buying it. In all the years since I first talked about that issue, no one who does have a copy has bothered to posted a response citing a definition for "accept" from that standard. In ordinary English usage, there's nothing self-contradictory about the statement "I accepted his gift, but never opened it and never did anything with it". A fully conforming implementation which processes every strictly conforming program (except the "one program" - which need NOT be strictly conforming) by saying "program accepted" and doing nothing more with it.

The requirement that you think the standard imposes would not make any sense, because of the way the standard defines "conforming program". I suspect that you are under the impression that it gives a useful, sane definition for that term. It does not. To understand what the problem  with the standard's definition is, let me start with 4p4:

"The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion.". This is the only circumstance under which the standard prohibits successful translation of a program. Therefore, a fully conforming implementation could successfully translate every program that does not contain a #error directive that survives conditional inclusion. If a diagnostic message is mandatory, it issues that message, and then continues processing the program. For those programs with undefined behavior, "this international standard imposes no requirements", so no matter what the final executable does, it still conforms to all of the applicable requirements (in this case, none) of the standard.

"A conforming program is one that is acceptable to a conforming implementation." (4p7). The implementation I described in the previous paragraph renders every program it accepts a conforming program. This definition, like many ridiculous definitions, was the result of a political compromise. That compromise has no actual negative consequences - while the standard defines the term "conforming program", it never makes any use of the term. In particular, the standard does NOT impose the requirement you describe in your first paragraph above.

> Hardware limitations such as memory limits are not part of the Standard. 

The standard indirectly acknowledges the existence of limits like that: "Both the translation and execution environments constrain the implementation of
language translators and libraries." (5.2.4p1). Most of the specific types of limits listed in 5.2.4.1 exist in real-world compilers are indirectly the result of memory limits.

[toc] | [prev] | [next] | [standalone]

#94600

James Kuyper, I don't know if you have me in a killfile filter or not,
but I wanted you to know I greatly enjoy your posts.  They are very
clearly conveyed, to the point, and ripe with knowledge, wisdom, and
experience.  They are also without artificial bias.  They are peaceful, and
are among my favorite to read (along with Supercat's).

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#94623

On 10/8/2016 10:49 AM, jameskuyper@verizon.net wrote:
> On Saturday, October 8, 2016 at 6:05:14 AM UTC-4, Jerry Stuckle wrote:
>> On 10/8/2016 4:02 AM, supercat@casperkitty.com wrote:
>>> On Friday, October 7, 2016 at 8:15:09 PM UTC-5, Jerry Stuckle wrote:
>>>> On 10/7/2016 7:17 PM, supercat wrote:
>>>>> Since it's possible for an implementation to be conforming and yet
>>>>> incapable of running any useful programs, ...
> ...
>>>> Your fault is in thinking it is impossible for an implementation to be
>>>> conforming yet incapable of running any useful programs.
> 
> You're responding to a paragraph in which he expressed, very clearly, the exact opposite of the thought you've just accused him of believing. He said "possible", while you said "impossible" - the wording is otherwise identical. I won't claim to know whether he's particularly honest or sane, but if you're going to accuse him of believing the exact opposite of what he's clearly said, you should provide some supporting evidence.
>

Not at all.  But I already know you have problems with reading
comprehension.

>>> The Implementation Limits section of the Standard requires that for every
>>> implementation there must exist at least one program which exercises all
>>> of the implementation limits described in the Standard, and which that
>>> implementation will process without UB.  The rationale makes very clear
>>> that the Standard does not require that an implementation be capable of
>>> running all such programs, since a program which exercised all limitations
>>> simultaneously would require over a megabyte of storage, and many computers
>>> in 1989 weren't that big.  The stated intention in the rationale is that
>>> someone who is trying to make a useful implementation which doesn't get
>>> tripped up by any of the limits in isolation will likely produce an
>>> implementation that can accommodate them in useful combinations, but the
>>> Standard doesn't actually mandate that an implementation be capable of
>>> running more than one possibly-contrived program.
>>>
>>
>> The Standard requires a conforming implementation must process all
>> conforming programs.  If it does not, it is not a conforming implementation.
> 
> The standard imposes no such requirement. The requirements which it does impose that bear the greatest similarity to that non-existent requirement are the following:
> 
> "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:" (5.2.4.1p1). That one program, which could be different for every implementation, is the only program for which any such requirement applies.
> 
> "A conforming hosted implementation shall accept any strictly conforming program." (4p6). The standard does not define the meaning of "accept" that applies in this context. Therefore, the definition is either provided by ISO/IEC 2382−1:1993 (3p1), or by ordinary English usage in the context of computer programming. ISO 2382 is too expensive for me to justify buying it. In all the years since I first talked about that issue, no one who does have a copy has bothered to posted a response citing a definition for "accept" from that standard. In ordinary English usage, there's nothing self-contradictory about the statement "I accepted his gift, but never opened it and never did anything with it". A fully conforming implementation which processes every strictly conforming program (except the "one program" - which need NOT be strictly conforming) by saying "program accepted" and doing nothing more with it.
> 
> The requirement that you think the standard imposes would not make any sense, because of the way the standard defines "conforming program". I suspect that you are under the impression that it gives a useful, sane definition for that term. It does not. To understand what the problem  with the standard's definition is, let me start with 4p4:
> 
> "The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion.". This is the only circumstance under which the standard prohibits successful translation of a program. Therefore, a fully conforming implementation could successfully translate every program that does not contain a #error directive that survives conditional inclusion. If a diagnostic message is mandatory, it issues that message, and then continues processing the program. For those programs with undefined behavior, "this international standard imposes no requirements", so no matter what the final executable does, it still conforms to all of the applicable requirements (in this case, none) of the standard.
> 
> "A conforming program is one that is acceptable to a conforming implementation." (4p7). The implementation I described in the previous paragraph renders every program it accepts a conforming program. This definition, like many ridiculous definitions, was the result of a political compromise. That compromise has no actual negative consequences - while the standard defines the term "conforming program", it never makes any use of the term. In particular, the standard does NOT impose the requirement you describe in your first paragraph above.
> 
>> Hardware limitations such as memory limits are not part of the Standard. 
> 
> The standard indirectly acknowledges the existence of limits like that: "Both the translation and execution environments constrain the implementation of
> language translators and libraries." (5.2.4p1). Most of the specific types of limits listed in 5.2.4.1 exist in real-world compilers are indirectly the result of memory limits.
> 

You also seem to have reading comprehension problems with the standard.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#94624

On Saturday, October 8, 2016 at 4:58:42 PM UTC-4, Jerry Stuckle wrote:
...
> Not at all.  But I already know you have problems with reading
> comprehension.
...
> You also seem to have reading comprehension problems with the standard.

You routinely respond to reasoned arguments solidly supported with valid citations from the standard by not bothering to address the points raised, not challenging the citations as invalid, and you almost never bother making relevant citations of your own. You simply insult the intelligence of the person making the argument.
I thought you should know - you're not really fooling many people this way. It's perfectly obvious that you don't address any of the points raised because you have no arguments that can address them. You don't cite parts of the standard to support your point of view because there are no such parts. You don't even bother to explain what it is you think I've misunderstood - not because you don't deign to, but simply because you can't.

[toc] | [prev] | [next] | [standalone]

#94627

jameskuyper@verizon.net writes:
> On Saturday, October 8, 2016 at 4:58:42 PM UTC-4, Jerry Stuckle wrote:
> ...
>> Not at all.  But I already know you have problems with reading
>> comprehension.
> ...
>> You also seem to have reading comprehension problems with the standard.
>
> You routinely respond to reasoned arguments solidly supported with
> valid citations from the standard by not bothering to address the
> points raised, not challenging the citations as invalid, and you
> almost never bother making relevant citations of your own. You simply
> insult the intelligence of the person making the argument.  I thought
> you should know - you're not really fooling many people this way. It's
> perfectly obvious that you don't address any of the points raised
> because you have no arguments that can address them. You don't cite
> parts of the standard to support your point of view because there are
> no such parts. You don't even bother to explain what it is you think
> I've misunderstood - not because you don't deign to, but simply
> because you can't.

James, I think you misspelled "plonk".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web