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

https://github.com/bartg/langs/tree/master/bccproj

Started by	jacobnavia <jacob@jacob.remcomp.fr>
First post	2017-04-24 23:33 +0200
Last post	2017-04-26 11:36 +0200
Articles	20 on this page of 116 — 20 participants

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

  https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-24 23:33 +0200
    Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-24 23:14 +0100
      Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-25 00:31 +0100
      Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-25 14:46 +0000
        Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-25 17:05 +0100
          Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-26 01:32 +0100
            Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-26 11:32 +0100
              Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-26 12:09 +0100
                Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:32 -0700
                  Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 06:23 -0700
                    Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 14:26 +0000
                      Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 11:04 -0700
                        Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 18:26 +0000
                          Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 12:59 -0700
                            Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 20:29 +0000
                    Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-28 17:35 +0100
                      Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 13:21 -0700
                        Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-28 22:35 +0100
                          Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-01 05:16 -0700
                            Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-01 13:47 +0100
                              Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 05:16 -0700
                                Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-05 18:46 -0700
                                  Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-06 12:00 +0100
                                    Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 12:01 -0700
                                      Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-06 12:15 -0700
                                        Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 14:03 -0700
                                          Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 05:53 -0700
                                            Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 14:26 +0100
                                              Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 07:10 -0700
                                                Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 15:36 +0100
                                                  Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 15:43 +0100
                                                    Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-08 12:06 -0700
                                                  Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 11:02 -0700
                                                    Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 19:46 +0100
                                                  Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 12:23 -0700
                                                    Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 21:08 +0100
                                                      Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-08 13:26 -0700
                                                        Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-08 13:32 -0700
                                                          Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-08 13:40 -0700
                                                        Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 21:33 +0100
                                                      Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 13:30 -0700
                                                        Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 22:00 +0100
                                                    Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 22:18 +0100
                                                      Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 18:12 -0700
                                                        Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 07:04 -0700
                                                          Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-05-10 07:50 +1200
                                                            Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 13:31 -0700
                                                              Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-05-10 08:58 +1200
                                                                Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 14:25 -0700
                                                                  Re: https://github.com/bartg/langs/tree/master/bccproj Philip Lantz <prl@canterey.us> - 2017-05-18 05:45 -0700
                                                                    Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 14:02 +0000
                                                                      Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-18 07:22 -0700
                                                                      Re: https://github.com/bartg/langs/tree/master/bccproj Robert Wessel <robertwessel2@yahoo.com> - 2017-05-18 22:27 -0500
                                                                        Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-19 08:29 -0700
                                                              Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-05-10 14:32 +0200
                                                          Re: https://github.com/bartg/langs/tree/master/bccproj raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:19 +0000
                                                            Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-10 09:51 -0700
                                                              Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-05-10 17:37 +0000
                                                                Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-10 10:53 -0700
                                                              Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:39 -0700
                                                                Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 07:58 -0700
                                                                  Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-15 11:54 -0700
                                                                    Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 12:25 -0700
                                                                      Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-15 15:20 -0700
                                                                        Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 15:43 -0700
                                                                        Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 04:38 -0700
                                                                          Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-16 12:48 -0700
                                                                            Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:12 -0700
                                                                              Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-24 09:10 -0700
                                                                                Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-05-25 07:22 +1200
                                                                                Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:03 -0700
                                                                                Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-27 11:42 -0700
                                                              Re: https://github.com/bartg/langs/tree/master/bccproj raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:34 +0000
                                                                Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 08:02 -0700
                                            Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 18:24 +0100
                                        Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 05:32 -0700
                                    Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-06 12:04 -0700
                    Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 09:53 -0700
                      Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-28 19:47 +0200
                        Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 11:56 -0700
                          Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 12:21 -0700
                            Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 13:07 -0700
                            Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-28 22:23 +0200
                              Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 14:03 -0700
                              Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 14:57 -0700
                                Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 15:57 -0700
                      Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 11:49 -0700
              Re: https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-26 13:31 +0200
                Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 15:14 +0200
                  Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-26 15:10 +0100
                    Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:36 +0200
                      Re: https://github.com/bartg/langs/tree/master/bccproj Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-26 08:49 -0700
                      Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-26 20:44 +0200
                        Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 21:02 +0200
                          Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-26 22:07 +0200
                            Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 22:56 +0200
                              Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 11:16 +0200
                                Re: https://github.com/bartg/langs/tree/master/bccproj Richard Heathfield <rjh@cpax.org.uk> - 2017-04-27 10:53 +0100
                                  Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 12:56 +0200
                                    Re: https://github.com/bartg/langs/tree/master/bccproj "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-27 04:13 -0700
                                      Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-27 12:27 +0100
                                        Re: https://github.com/bartg/langs/tree/master/bccproj "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-27 06:05 -0700
                          Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-04-27 09:38 +1200
                            Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-04-26 17:40 -0700
                    Re: https://github.com/bartg/langs/tree/master/bccproj Geoff <geoff@invalid.invalid> - 2017-04-26 22:22 -0700
                      Re: https://github.com/bartg/langs/tree/master/bccproj Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-27 01:45 -0700
          Re: https://github.com/bartg/langs/tree/master/bccproj Geoff <geoff@invalid.invalid> - 2017-04-26 21:55 -0700
            Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 11:25 +0200
              Re: https://github.com/bartg/langs/tree/master/bccproj "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-27 12:59 -0400
            Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-27 15:03 +0200
              Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-27 13:27 +0000
        Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 01:29 +0200
        Re: https://github.com/bartg/langs/tree/master/bccproj Philip Lantz <prl@canterey.us> - 2017-04-26 10:14 -0700
          Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-26 12:25 -0700
    Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-24 15:26 -0700
    Re: https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-26 11:36 +0200

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

#110039

From	supercat@casperkitty.com
Date	2017-05-15 07:58 -0700
Message-ID	<34bdc6a9-a31a-4051-be03-de6b3158d44e@googlegroups.com>
In reply to	#109969

On Sunday, May 14, 2017 at 2:39:33 PM UTC-5, Tim Rentsch wrote:
>            A major aspect of the ANSI standardization, and one
> that Ritchie surely must have realized and played a part in, is
> consideration of how C does or might work on processors other
> than the few on which it was originally implemented.  The idea
> that C's design was complete in 1974 is laughable, not to mention
> contradicted by historical evidence.

When the 1974 manual was written it worked on two which had noticeably
different architectures, establishing a pattern that suggested that certain
features of the language would vary based upon the hosting CPU.  I don't
think I've ever claimed that C should use two's-complement format integers
when running on, or called upon to emulate, sign-magnitude or ones'-
complement hardware.

On the other hand, I see no evidence that allowances for integer treatments
other than silent-wraparound or silent (and not necessarily consistent)
promotion were intended for any purpose other than to either facilitate
implementations on hardware whose underlying semantics were inconsistent
with those, or to allow for implementations that would affirmatively trap
integer overflow *in documented fashion*.  I am aware of *ZERO* twentieth-
century evidence that anyone of note thought that quality implementations
for two's-complement hardware should not be expected to either yield some
possibly-meaningless result, trap in documented fashion, or choose in
Unspecified fashion between those two behaviors.

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

#110066

From	Keith Thompson <kst-u@mib.org>
Date	2017-05-15 11:54 -0700
Message-ID	<lno9uu3q8a.fsf@kst-u.example.com>
In reply to	#110039

supercat@casperkitty.com writes:
[...]
> On the other hand, I see no evidence that allowances for integer treatments
> other than silent-wraparound or silent (and not necessarily consistent)
> promotion were intended for any purpose other than to either facilitate
> implementations on hardware whose underlying semantics were inconsistent
> with those, or to allow for implementations that would affirmatively trap
> integer overflow *in documented fashion*.  I am aware of *ZERO* twentieth-
> century evidence that anyone of note thought that quality implementations
> for two's-complement hardware should not be expected to either yield some
> possibly-meaningless result, trap in documented fashion, or choose in
> Unspecified fashion between those two behaviors.

The phrase "the behavior is undefined" in C90 6.3, 5th paragraph,
is not sufficient evidence for you?

-- 
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]

#110070

From	supercat@casperkitty.com
Date	2017-05-15 12:25 -0700
Message-ID	<2dd541b4-20f1-4f5e-bf0d-44897f7e9e9a@googlegroups.com>
In reply to	#110066

On Monday, May 15, 2017 at 1:54:52 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> [...]
> > On the other hand, I see no evidence that allowances for integer treatments
> > other than silent-wraparound or silent (and not necessarily consistent)
> > promotion were intended for any purpose other than to either facilitate
> > implementations on hardware whose underlying semantics were inconsistent
> > with those, or to allow for implementations that would affirmatively trap
> > integer overflow *in documented fashion*.  I am aware of *ZERO* twentieth-
> > century evidence that anyone of note thought that quality implementations
> > for two's-complement hardware should not be expected to either yield some
> > possibly-meaningless result, trap in documented fashion, or choose in
> > Unspecified fashion between those two behaviors.
> 
> The phrase "the behavior is undefined" in C90 6.3, 5th paragraph,
> is not sufficient evidence for you?

They no doubt expected that quality implementations *for hardware that did
not use silent-wraparound two's-complement overflow semantics* might behave
in fashions other than the above.  That alone would be sufficient reason for
them to classify the behavior as Undefined, whether or not they expected that
quality implementations targeting silent-wraparound two's-complement
hardware would ever do anything other than the above.

Given that the decision to have short unsigned types promote to signed int
was predicated in some measure on the way that silent-wraparound two's-
complement platforms--i.e. the majority of (then) current implementations--
behaved in cases where the Standard imposed no requirements, I would say
the rationale given would make no sense unless the authors expected that
such behaviors would continue to be commonplace for most kinds of
implementations.

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

#110095

From	Keith Thompson <kst-u@mib.org>
Date	2017-05-15 15:20 -0700
Message-ID	<lnbmqt4v9c.fsf@kst-u.example.com>
In reply to	#110070

supercat@casperkitty.com writes:
> On Monday, May 15, 2017 at 1:54:52 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> [...]
>> > On the other hand, I see no evidence that allowances for integer
>> > treatments other than silent-wraparound or silent (and not
>> > necessarily consistent) promotion were intended for any purpose
>> > other than to either facilitate implementations on hardware whose
>> > underlying semantics were inconsistent with those, or to allow for
>> > implementations that would affirmatively trap integer overflow *in
>> > documented fashion*.  I am aware of *ZERO* twentieth- century
>> > evidence that anyone of note thought that quality implementations
>> > for two's-complement hardware should not be expected to either
>> > yield some possibly-meaningless result, trap in documented fashion,
>> > or choose in Unspecified fashion between those two behaviors.
>> 
>> The phrase "the behavior is undefined" in C90 6.3, 5th paragraph,
>> is not sufficient evidence for you?
>
> They no doubt expected that quality implementations *for hardware that did
> not use silent-wraparound two's-complement overflow semantics* might behave
> in fashions other than the above.  That alone would be sufficient reason for
> them to classify the behavior as Undefined, whether or not they expected that
> quality implementations targeting silent-wraparound two's-complement
> hardware would ever do anything other than the above.
>
> Given that the decision to have short unsigned types promote to signed int
> was predicated in some measure on the way that silent-wraparound two's-
> complement platforms--i.e. the majority of (then) current implementations--
> behaved in cases where the Standard imposed no requirements, I would say
> the rationale given would make no sense unless the authors expected that
> such behaviors would continue to be commonplace for most kinds of
> implementations.

If the committee had wanted to mention that expectation in the
standard, either in a non-normative footnote or in a "Recommended
Practice" sections, they could easily have done so.  You seem
unwilling to draw any conclusion from the fact that they didn't.

Meanwhile, the standard says the behavior of signed overflow is
undefined, and compiler writers take it at its word.

-- 
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]

#110098

From	supercat@casperkitty.com
Date	2017-05-15 15:43 -0700
Message-ID	<e4abec61-0714-4c5d-82ad-4497d6a9b40d@googlegroups.com>
In reply to	#110095

On Monday, May 15, 2017 at 5:20:55 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > Given that the decision to have short unsigned types promote to signed int
> > was predicated in some measure on the way that silent-wraparound two's-
> > complement platforms--i.e. the majority of (then) current implementations--
> > behaved in cases where the Standard imposed no requirements, I would say
> > the rationale given would make no sense unless the authors expected that
> > such behaviors would continue to be commonplace for most kinds of
> > implementations.
> 
> If the committee had wanted to mention that expectation in the
> standard, either in a non-normative footnote or in a "Recommended
> Practice" sections, they could easily have done so.  You seem
> unwilling to draw any conclusion from the fact that they didn't.

The authors of the Standard were interested in specifying behavior in
cases where people writing compilers might otherwise do something else
(e.g. in the absence of a requirement that UINT_MAX be odd, a compiler
for a ones'-complement system might quite reasonably make it even).  What
reason would they have had to recommend that compilers to something that
they would do anyway?

> Meanwhile, the standard says the behavior of signed overflow is
> undefined, and compiler writers take it at its word.

It specifies that there is no behavior that would make an implementation
non-conforming.  That does not imply any judgment as to whether there exist
behaviors that would make an implementation unsuitable for some purposes.

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

#110131

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2017-05-16 04:38 -0700
Message-ID	<kfn8tlxm3pe.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#110095

Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>> On Monday, May 15, 2017 at 1:54:52 PM UTC-5, Keith Thompson wrote:
>>> supercat writes:
>>> [...]
>>>> On the other hand, I see no evidence that allowances for integer
>>>> treatments other than silent-wraparound or silent (and not
>>>> necessarily consistent) promotion were intended for any purpose
>>>> other than to either facilitate implementations on hardware whose
>>>> underlying semantics were inconsistent with those, or to allow for
>>>> implementations that would affirmatively trap integer overflow *in
>>>> documented fashion*.  I am aware of *ZERO* twentieth- century
>>>> evidence that anyone of note thought that quality implementations
>>>> for two's-complement hardware should not be expected to either
>>>> yield some possibly-meaningless result, trap in documented fashion,
>>>> or choose in Unspecified fashion between those two behaviors.
>>>
>>> The phrase "the behavior is undefined" in C90 6.3, 5th paragraph,
>>> is not sufficient evidence for you?
>>
>> They no doubt expected that quality implementations *for hardware that
>> did not use silent-wraparound two's-complement overflow semantics* might
>> behave in fashions other than the above.  That alone would be sufficient
>> reason for them to classify the behavior as Undefined, whether or not
>> they expected that quality implementations targeting silent-wraparound
>> two's-complement hardware would ever do anything other than the above.
>>
>> Given that the decision to have short unsigned types promote to signed
>> int was predicated in some measure on the way that silent-wraparound
>> two's- complement platforms--i.e.  the majority of (then) current
>> implementations-- behaved in cases where the Standard imposed no
>> requirements, I would say the rationale given would make no sense unless
>> the authors expected that such behaviors would continue to be
>> commonplace for most kinds of implementations.
>
> If the committee had wanted to mention that expectation in the
> standard, either in a non-normative footnote or in a "Recommended
> Practice" sections, they could easily have done so.  You seem
> unwilling to draw any conclusion from the fact that they didn't.

supercat suffers from willful myopia.  The only reason he
cannot see is that he doesn't /want/ to see.  This makes
pointing things out to him rather, well, pointless.

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

#110174

From	supercat@casperkitty.com
Date	2017-05-16 12:48 -0700
Message-ID	<1e05dcd7-2f9d-4b31-b292-ab94c27f01be@googlegroups.com>
In reply to	#110131

On Tuesday, May 16, 2017 at 6:38:44 AM UTC-5, Tim Rentsch wrote:
> Keith Thompson writes:
> > If the committee had wanted to mention that expectation in the
> > standard, either in a non-normative footnote or in a "Recommended
> > Practice" sections, they could easily have done so.  You seem
> > unwilling to draw any conclusion from the fact that they didn't.
> 
> supercat suffers from willful myopia.  The only reason he
> cannot see is that he doesn't /want/ to see.  This makes
> pointing things out to him rather, well, pointless.

What am I not "seeing"?  I am not drawing any conclusion from the
failure of the Committee to say things that everyone at the time
would have recognized as obvious and non-controversial.  If they
were not considered obvious and non-controversial, then there should
be some contemporaneous *contrary* arguments (rather than merely a
failure to overstate the obvious).  Can you identify any?

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

#110545

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2017-05-24 08:12 -0700
Message-ID	<kfnmva2i91a.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#110174

supercat@casperkitty.com writes:

> On Tuesday, May 16, 2017 at 6:38:44 AM UTC-5, Tim Rentsch wrote:
>> Keith Thompson writes:
>>> If the committee had wanted to mention that expectation in the
>>> standard, either in a non-normative footnote or in a "Recommended
>>> Practice" sections, they could easily have done so.  You seem
>>> unwilling to draw any conclusion from the fact that they didn't.
>>
>> supercat suffers from willful myopia.  The only reason he
>> cannot see is that he doesn't /want/ to see.  This makes
>> pointing things out to him rather, well, pointless.
>
> What am I not "seeing"?  [...]

Apparently one thing you're not seeing is the many times
you have been asked not to oversnip quoted material.

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

#110557

From	supercat@casperkitty.com
Date	2017-05-24 09:10 -0700
Message-ID	<6ad70b0e-dffa-4bdf-a691-ddd3c4f47a5d@googlegroups.com>
In reply to	#110545

On Wednesday, May 24, 2017 at 10:12:10 AM UTC-5, Tim Rentsch wrote:
> supercat writes:
> 
> > On Tuesday, May 16, 2017 at 6:38:44 AM UTC-5, Tim Rentsch wrote:
> >> Keith Thompson writes:
> >>> If the committee had wanted to mention that expectation in the
> >>> standard, either in a non-normative footnote or in a "Recommended
> >>> Practice" sections, they could easily have done so.  You seem
> >>> unwilling to draw any conclusion from the fact that they didn't.
> >>
> >> supercat suffers from willful myopia.  The only reason he
> >> cannot see is that he doesn't /want/ to see.  This makes
> >> pointing things out to him rather, well, pointless.
> >
> > What am I not "seeing"?  [...]
> 
> Apparently one thing you're not seeing is the many times
> you have been asked not to oversnip quoted material.

How many messages appear on this thread between the message I was relying
to and my response?  I know that different servers may have different
message orderings, but when the thread has a total of two messages from
that day I would find it surprising if they didn't appear consecutively
on just about every server.

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

#110575

From	Ian Collins <ian-news@hotmail.com>
Date	2017-05-25 07:22 +1200
Message-ID	<eom4s1Fha6pU1@mid.individual.net>
In reply to	#110557

On 05/25/17 04:10 AM, supercat@casperkitty.com wrote:
> On Wednesday, May 24, 2017 at 10:12:10 AM UTC-5, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Tuesday, May 16, 2017 at 6:38:44 AM UTC-5, Tim Rentsch wrote:
>>>> Keith Thompson writes:
>>>>> If the committee had wanted to mention that expectation in the
>>>>> standard, either in a non-normative footnote or in a "Recommended
>>>>> Practice" sections, they could easily have done so.  You seem
>>>>> unwilling to draw any conclusion from the fact that they didn't.
>>>>
>>>> supercat suffers from willful myopia.  The only reason he
>>>> cannot see is that he doesn't /want/ to see.  This makes
>>>> pointing things out to him rather, well, pointless.
>>>
>>> What am I not "seeing"?  [...]
>>
>> Apparently one thing you're not seeing is the many times
>> you have been asked not to oversnip quoted material.
>
> How many messages appear on this thread between the message I was relying
> to and my response?  I know that different servers may have different
> message orderings, but when the thread has a total of two messages from
> that day I would find it surprising if they didn't appear consecutively
> on just about every server.

That's not the point.  Each post on Usenet should stand on its own.

-- 
Ian

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

#110790

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2017-05-27 06:03 -0700
Message-ID	<kfnlgpifo4r.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#110557

supercat@casperkitty.com writes:

> On Wednesday, May 24, 2017 at 10:12:10 AM UTC-5, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Tuesday, May 16, 2017 at 6:38:44 AM UTC-5, Tim Rentsch wrote:
>>>> Keith Thompson writes:
>>>>> If the committee had wanted to mention that expectation in the
>>>>> standard, either in a non-normative footnote or in a "Recommended
>>>>> Practice" sections, they could easily have done so.  You seem
>>>>> unwilling to draw any conclusion from the fact that they didn't.
>>>>
>>>> supercat suffers from willful myopia.  The only reason he
>>>> cannot see is that he doesn't /want/ to see.  This makes
>>>> pointing things out to him rather, well, pointless.
>>>
>>> What am I not "seeing"?  [...]
>>
>> Apparently one thing you're not seeing is the many times
>> you have been asked not to oversnip quoted material.
>
> How many messages appear on this thread between the message I was relying
> to and my response?  I know that different servers may have different
> message orderings, but when the thread has a total of two messages from
> that day I would find it surprising if they didn't appear consecutively
> on just about every server.

There's another example of willful myopia.

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

#110797

From	Keith Thompson <kst-u@mib.org>
Date	2017-05-27 11:42 -0700
Message-ID	<lnwp92rvjn.fsf@kst-u.example.com>
In reply to	#110557

supercat@casperkitty.com writes:
> On Wednesday, May 24, 2017 at 10:12:10 AM UTC-5, Tim Rentsch wrote:
[...]
>> Apparently one thing you're not seeing is the many times
>> you have been asked not to oversnip quoted material.
>
> How many messages appear on this thread between the message I was relying
> to and my response?  I know that different servers may have different
> message orderings, but when the thread has a total of two messages from
> that day I would find it surprising if they didn't appear consecutively
> on just about every server.

Depending on the newsreader, jumping from the current message to its
parent is likely to be inconvenient, and might not be possible.
Messages can arrive out of order (that might not be as much of an issue
as it used to be).

In the newsreader I use, for example, there's a simple command to jump
to the parent message, but getting back to the message I came from can
be awkward.

If you want to refer to something in a previous message, you should make
it convenient for your readers to see the context.  If you don't, a lot
of people just won't bother.

-- 
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]

#110010

From	raltbos@xs4all.nl (Richard Bos)
Date	2017-05-15 12:34 +0000
Message-ID	<5919a042.17416453@news.xs4all.nl>
In reply to	#109690

supercat@casperkitty.com wrote:

> On Wednesday, May 10, 2017 at 5:19:54 AM UTC-5, Richard Bos wrote:
> > supercat wrote:
> > > C was designed to be a small language which could be processed into usable
> > > machine code by a compiler running on a minimal system. 
> > 
> > Yes, and _not_ as a portable assembler, or as a language which is
> > specifically tuned to a mythical "every 1980s computer".
> 
> I think the 1974 C Reference Manual is probably a good indication of what
> C was designed to be.  Would you disagree? 

Nice try, but I'm not getting into these games with you.

> If e.g. Ritchie had intended

Stop pretending that you can read dmr's mind. It's distasteful.

Richard

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

#110040

From	supercat@casperkitty.com
Date	2017-05-15 08:02 -0700
Message-ID	<9b9cae8d-918b-4b27-9210-55cc760b4157@googlegroups.com>
In reply to	#110010

On Monday, May 15, 2017 at 7:35:06 AM UTC-5, Richard Bos wrote:
> supercat wrote:
> > If e.g. Ritchie had intended
> 
> Stop pretending that you can read dmr's mind. It's distasteful.

I am claiming that what he wrote is consistent with certain intentions, and
inconsistent with others.  People who write things often do so *for the
purpose* of making their intentions known, and respect for someone's writing
would require ackowledging intentions expressed thereby.

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

#109518

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2017-05-08 18:24 +0100
Message-ID	<87a86nclcu.fsf@bsb.me.uk>
In reply to	#109493

Thiago Adams <thiago.adams@gmail.com> writes:

<snip>
(You might consider cutting some of these many many lines.  You are not
commenting on all of them.)

> If the parser has the information of preprocessor and vice versa we can 
> do and check a lot of things. This is the integration.
>
> For instance 
> #if sizeof(int) 
> preprocessor can use sizeof
>
> #if symbol_defined(F) 
>
> preprocessor can ask if function F was defined.

A small point: I think you mean "declared".

<snip>
-- 
Ben.

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

#109659

From	Thiago Adams <thiago.adams@gmail.com>
Date	2017-05-10 05:32 -0700
Message-ID	<46c08df9-52b2-4b40-b3c1-1758251a79e9@googlegroups.com>
In reply to	#109405

On Saturday, May 6, 2017 at 4:15:54 PM UTC-3, Thiago Adams wrote:
> On Saturday, May 6, 2017 at 4:01:42 PM UTC-3, David Kleinecke wrote:
> > On Saturday, May 6, 2017 at 4:00:26 AM UTC-7, Bart wrote:
> > > On 06/05/2017 02:46, Thiago Adams wrote:
> > > > On Wednesday, May 3, 2017 at 9:17:19 AM UTC-3, Thiago Adams wrote:
> > > 
> > > >> I do all preprocessing (#if, #include, macro expansion) inside the scanner.
> > > >> For #if,#else etc I have a kind of state machine to tell when tokens are ignored or not.
> > > >>
> > > >> #define A 0
> > > >>
> > > >> 1 + /*comment*/ A
> > > >>
> > > >> The parser will ask NextToken that returns '1',
> > > >> then NextToken that returns '+',
> > > >> then NextToken that returns '0'.
> > > >>
> > > >> I am planning to collect #define, #undef  and comments and put then inside AST nodes.
> > > >> When the AST node is created it will ask the scanner "give me all the collected comments and preprocessor" - "Clear the collected list".
> > > >> So, /*comment*/ will be inserted at "primary-expression node 0".
> > > >
> > > > Using this scanner I managed to rebuild source code from AST with macro.
> > > > I can put the macro call instead of the expansion in some places decided by me.
> > > > When I get a token, I can ask if that token is at the beginning of some macro expansion. I also can ask if the token is the end of the macro expansion.
> > > >
> > > > #define NULL ((void*)0)
> > > > int * p = NULL;
> > > >
> > > > So, when I parse the primary-expression ((void*)0) I can ask if am on the begging of some macro expansion. Token '(' is the begging of of expansion of NULL.
> > > > When the primary-expression ends, I ask if the macro expansion ended as well exactly at the end of primary-expression.
> > > > if this is true, then I replace all the primary-expression by the macro call, otherwise the macro the expansion is used.
> > > > I did this in some places.(some grammar productions)
> > > >
> > > > I don´t know if someone else is interested on this subject of rebuild the source code, or preprocessor as parser detail. I also managed to keep or not #includes.I can generated the amalgamation if desired or keep the includes.External includes are always kept so the source code can be used in other platform without rebuild.
> > > 
> > > Well, it's interesting that some of this stuff is possible to do. And it 
> > > is intriguing how it might work.
> > > 
> > > So it sounds like macro-calls need to be well-formed, but how about 
> > > #defines; start with a+a+a, then do this:
> > > 
> > >   a +
> > >   #define a x
> > >   a + a;
> > > 
> > > The current PP rules say that this now becomes a+x+x, but a typical AST 
> > > for such an expression would be (using numeric suffixes to make it clearer):
> > > 
> > >   (add2 (add1 a1 a2) a3)
> > > 
> > > where does the #define go? In the source, it's just after add1 so would 
> > > be here:
> > > 
> > >   (add2 (add1 (#define 'a' 'x') a1 a2) a3)
> > > 
> > > but it's influence would apply to a2 and a3, not a1 and a2. The scope of 
> > > #defines is out of kilter with that block-scope and expression precedence.
> > > 
> > > Or do #defines, the ones to be part of the AST, also need to be properly 
> > > placed and follow similar rules to expressions and statements?
> > > 
> > > -- 
> > > Bartc
> > 
> > The preprocessor and the parser are different modules. The
> > parser knows nothing about the #define, The preprocessor
> > knows nothing about the meaning of "+". 
> 
> In other topics, I raise the question of integration of the parser and preprocessor in a way that nobody would noticed (if desired) or they would notice for  good reasons.
> 
>  
> > The processor can be (= usually is?) implemented on a token
> > by token basis incrementally. It generates a new token whenever
> > the parser asks for a new token. After the pre-processor has
> > sent "a" and "+" the next call for a token results in processing
> > the #define, then reading in an "a" recognizing it as a macro
> > name, expanding the macro and finally returning the first token
> > in the macro expansion. After passing all the expansion tokens
> > (in this case just a single "x") the pre-processor reads in
> > another token ("+") and then finally another macro expansion.
> > 
> > But then you already knew all that.
> 
> I do all processing inside the scanner. 
> The parser just ask for the next token.
> 
>   a +
>   #define a x
>   a + a;
> 
> Next -> 'a'
> Next -> '+'
> Next -> 'x'
> Next -> '+'
> Next -> 'x'
> Next -> ';'
> Next -> EOF
> 
> But in the middle I can ask for the scanner for collected #define.
> 
>   a +
>   #define a x
>   a + a;
> 
> 
> 
> 
> 
> Next -> 'a'
> Next -> '+'
> 
> Scanner did  you collect anything? 
> If Yes put at begging-list of the next node.
> 
> Scanner are you at the begging of macro expansion?
> Next -> 'x'
> Scanner are you at the end of macro expansion? If yes, and I am on
> the primary-expression then I will give the node a 'expanded call' 
> that can be used latter to generate the macro call instead of 
> expansion.
> 
> Next -> '+'
> 
> //same 
> Next -> 'x'
> //same 
> 
> Next -> ';'
> Next -> EOF

I had an idea about how to parse and rebuild #ifdefs.
Basically  I will do like an "#include" of the TRUE path of #if and 
the FALSE paths will work like comments.

#ifdef TRUE
A
#else

#endif

Something similar of

//#ifdef TRUE
#include "a.h" where a.h is A
//#else
//
//#endif

The #if will be separated in two parts.

The FALSE part will work as a big comment. It's not analyzed 
but can be used to rebuild the source.
The first and second parts are inserted into begging-list
and end-list of some nodes.

If this was a code format tool for instance, the true path would be
formatted perfectly, but the false paths would be the same or formatted
with "relaxed" parser.

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

#109404

From	Thiago Adams <thiago.adams@gmail.com>
Date	2017-05-06 12:04 -0700
Message-ID	<7dea7d6b-381f-4793-92da-23278d200a0d@googlegroups.com>
In reply to	#109393

On Saturday, May 6, 2017 at 8:00:26 AM UTC-3, Bart wrote:
> On 06/05/2017 02:46, Thiago Adams wrote:
> > On Wednesday, May 3, 2017 at 9:17:19 AM UTC-3, Thiago Adams wrote:
> 
> >> I do all preprocessing (#if, #include, macro expansion) inside the scanner.
> >> For #if,#else etc I have a kind of state machine to tell when tokens are ignored or not.
> >>
> >> #define A 0
> >>
> >> 1 + /*comment*/ A
> >>
> >> The parser will ask NextToken that returns '1',
> >> then NextToken that returns '+',
> >> then NextToken that returns '0'.
> >>
> >> I am planning to collect #define, #undef  and comments and put then inside AST nodes.
> >> When the AST node is created it will ask the scanner "give me all the collected comments and preprocessor" - "Clear the collected list".
> >> So, /*comment*/ will be inserted at "primary-expression node 0".
> >
> > Using this scanner I managed to rebuild source code from AST with macro.
> > I can put the macro call instead of the expansion in some places decided by me.
> > When I get a token, I can ask if that token is at the beginning of some macro expansion. I also can ask if the token is the end of the macro expansion.
> >
> > #define NULL ((void*)0)
> > int * p = NULL;
> >
> > So, when I parse the primary-expression ((void*)0) I can ask if am on the begging of some macro expansion. Token '(' is the begging of of expansion of NULL.
> > When the primary-expression ends, I ask if the macro expansion ended as well exactly at the end of primary-expression.
> > if this is true, then I replace all the primary-expression by the macro call, otherwise the macro the expansion is used.
> > I did this in some places.(some grammar productions)
> >
> > I don´t know if someone else is interested on this subject of rebuild the source code, or preprocessor as parser detail. I also managed to keep or not #includes.I can generated the amalgamation if desired or keep the includes.External includes are always kept so the source code can be used in other platform without rebuild.
> 
> Well, it's interesting that some of this stuff is possible to do. And it 
> is intriguing how it might work.
> 
> So it sounds like macro-calls need to be well-formed, but how about 
> #defines; start with a+a+a, then do this:
> 
>   a +
>   #define a x
>   a + a;
> 
> The current PP rules say that this now becomes a+x+x, but a typical AST 
> for such an expression would be (using numeric suffixes to make it clearer):
> 
>   (add2 (add1 a1 a2) a3)
> 
> where does the #define go? In the source, it's just after add1 so would 
> be here:
> 
>   (add2 (add1 (#define 'a' 'x') a1 a2) a3)
> 
> but it's influence would apply to a2 and a3, not a1 and a2. The scope of 
> #defines is out of kilter with that block-scope and expression precedence.
> 
> Or do #defines, the ones to be part of the AST, also need to be properly 
> placed and follow similar rules to expressions and statements?
> 
> -- 

The AST nodes (as I am doing today) didn't change.
But each node have a begin-list and end-list that can be used
to keep #define , comments, #undef that where previously collected
by the scanner.

So, in this case, the preprocessor '#define a x' can be added 
at the end-list of  a1 node or at the begging-list of a2 node.

   a +              //a1
   #define a x
   a +              //a2
   a;               //a3

The decision if they will be collected or not, 
or if they will generate warning or error is delegated 
to parser. 
One suggestion is allow it at the same places where _Static_assert can 
go, but this is not a problem. Just more checks at 
each grammar production. If I want to regenerated /*comments*/ I
will have to check everywhere. 

When I generate code I place the begin-list before the 
node and end-list after.

This sample can be re-generated as it is.

   a +
   #define a x
   a + a;

When the primary-expression a (a2) is the current token 'x' the 
parser will understand that this is the begging of the expansion of 
macro 'a'. When the the token '+' is the current token the 
parser will know that the expansion of 'a' ended. 

But it ended at the exact point where the primary expression 
ended. So I can decide to replace that primary expression by 
the macro call or do nothing.

This one

#define X a +
int main()
{
	int a;
	X 1;
}

Will generate

#define X a +
int main()
{
	int a;
	a + 1;
}

Because the macro expansion of X didn't ended at the 
same point of primary-expression. I can decide where to 
put these rules. My current rule is inside the 
primary-expression and initializers.
For my personal use, I don´t want to allow this kind of macro 
expansion or I don´t care if the generated code is not similar.

For the keywords I need a similar decision. I have to decide if
I will keep the macro or keyword. The good sample for this 
is bool.

I am not checking anything at inner macro expansions.

#define NULL ((void*)0)
#define X 1 + NULL
int main()
{
	int a;
	a + X;
}

is expanded to

int main()
{
	int a;

        //results (( void*)0) instead of NULL because NULL 
        //is not recognized at inner expansions

        a+1+(( void*)0); 
}

Changing 
#define X 1 + NULL
To
#define X (1 + NULL)

generates:

a+X;

because now 
#define X (1 + NULL)
works as a primary-expression. The inner expansions are not relevant.

In my code the first macro expansion calls  other algorithm 
that does all the inner expansions and returns a string.
This is string is pushed to the scanner similar of 
one #include.

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

#108674

From	supercat@casperkitty.com
Date	2017-04-28 09:53 -0700
Message-ID	<e3c2713d-383d-400b-a20c-f0f7c0a70839@googlegroups.com>
In reply to	#108653

On Friday, April 28, 2017 at 8:23:58 AM UTC-5, Thiago Adams wrote:
> There is one C++ compiler (comeau), apart of CFront, that generates C code.
> I am curious about the output. How they managed the generation etc.., but
> I can't find samples, our trial download etc.

Do any such compilers make any effort to ensure defined behavior in cases
which it is required by the C++ Standard but not the C Standard, but where
most C compilers handle things as needed even when not required to do so?

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

#108676

From	David Brown <david.brown@hesbynett.no>
Date	2017-04-28 19:47 +0200
Message-ID	<odvv0q$sl8$1@dont-email.me>
In reply to	#108674

On 28/04/17 18:53, supercat@casperkitty.com wrote:
> On Friday, April 28, 2017 at 8:23:58 AM UTC-5, Thiago Adams wrote:
>> There is one C++ compiler (comeau), apart of CFront, that generates C code.
>> I am curious about the output. How they managed the generation etc.., but
>> I can't find samples, our trial download etc.
>
> Do any such compilers make any effort to ensure defined behavior in cases
> which it is required by the C++ Standard but not the C Standard, but where
> most C compilers handle things as needed even when not required to do so?
>

What cases are these?  I can't think off-hand of any situation where you 
can write something that is valid as C and C++, has basically the same 
meaning, but is fully defined by the C++ standards and not by the C 
standards.

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

#108682

From	supercat@casperkitty.com
Date	2017-04-28 11:56 -0700
Message-ID	<25ef1787-5f5c-428e-96e6-1acdbfb6aeba@googlegroups.com>
In reply to	#108676

On Friday, April 28, 2017 at 12:47:13 PM UTC-5, David Brown wrote:
> What cases are these?  I can't think off-hand of any situation where you 
> can write something that is valid as C and C++, has basically the same 
> meaning, but is fully defined by the C++ standards and not by the C 
> standards.

How about

   int shiftXY(int x, int y) { return x << y; }

The current C++ Standard defines shiftXY(1,31) as being equivalent to
(int)(1u << 31).  I don't like that change (I think the result should
have made the behavior of the shift Implementation-Defined, independent
of the behavior of unsigned-to-signed conversion), but the present
Standard(*) clearly and deliberately defines the meaning of that code in
a case where the C Standard does not.

(*) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf
    See section 5.8 paragraph 2.

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

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

csiph-web

https://github.com/bartg/langs/tree/master/bccproj

Contents

#110039

#110066

#110070

#110095

#110098

#110131

#110174

#110545

#110557

#110575

#110790

#110797

#110010

#110040

#109518

#109659

#109404

#108674

#108676

#108682