Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108434 > unrolled thread
| 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 107 — 19 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 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 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 →
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| 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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-28 12:21 -0700 |
| Message-ID | <lnbmrgl4mv.fsf@kst-u.example.com> |
| In reply to | #108682 |
supercat@casperkitty.com writes:
> 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 fail to see how wrapping it in a function made it any clearer, but OK.
> 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.
You're right. That change was made after the ISO C++11 standard,
and it still appears in the draft C++17 standard (N4296). I was
mistaken when I previously stated otherwise. Apparently it also
appears in C++14 (I don't have a copy).
Note that the result is implementation-defined, because the result of
the conversion is implementation-defined. (It's undefined behavior
in C.)
Here's the wording from the C++11 standard, discussing E1 << E2
(changing some of the punctuation to avoid non-ASCII characters):
Otherwise, if E1 has a signed type and non-negative value,
and E1 * 2**E2 is representable in the result type, then that
is the resulting value; otherwise, the behavior is undefined.
The N4296 draft of C++17 says:
Otherwise, if E1 has a signed type and non-negative value, and
E1 * 2**E2 is representable in the corresponding unsigned type of
the result type, then that value, converted to the result type,
is the resulting value; otherwise, the behavior is undefined.
I don't know why that change was made.
To answer your original question, a C++ implementation that uses
C intermediate code must do whatever is necessary to ensure that
it behaves in accordance with whichever C++ standard it claims to
support. That might or might not involve some extra work for the
"<<" operator with a signed left operand. I have no idea what any
such implementations actually do.
(BTW, thank you for posting with shorter lines.)
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-28 13:07 -0700 |
| Message-ID | <04ce0cb8-1ebd-408a-84eb-447816a0521b@googlegroups.com> |
| In reply to | #108684 |
On Friday, April 28, 2017 at 2:21:51 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > 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 fail to see how wrapping it in a function made it any clearer, but OK.
It makes clear that x and y are values of type "int" that may or may not
be constants.
> > 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.
>
> You're right. That change was made after the ISO C++11 standard,
> and it still appears in the draft C++17 standard (N4296). I was
> mistaken when I previously stated otherwise. Apparently it also
> appears in C++14 (I don't have a copy).
> Note that the result is implementation-defined, because the result of
> the conversion is implementation-defined. (It's undefined behavior
> in C.)
The behavior is defined as yielding an Implementation-Defined value. On
a two's-complement system, such behavior would make sense, but on a
36-bit ones'-complement system it really doesn't make sense to say that
a template substitution which would produce 1<<35 must be considered valid
even though it's unlikely the resulting value would be useful.
Rather than trying to bodge a particular spot where some implementations
would define a useful behavior but were forbidden from doing so, a better
approach would be to split UB into two subcategories: actions for which
many implementations should define meaningful behaviors, but where some
implementations may be unable to do so, versus actions for which no
meaningful behavior would be defined on any platform, and allow expressions
of the former type to be used in compile-time constants on platforms that
define their meaning.
> Here's the wording from the C++11 standard, discussing E1 << E2
> (changing some of the punctuation to avoid non-ASCII characters):
>
> Otherwise, if E1 has a signed type and non-negative value,
> and E1 * 2**E2 is representable in the result type, then that
> is the resulting value; otherwise, the behavior is undefined.
>
> The N4296 draft of C++17 says:
>
> Otherwise, if E1 has a signed type and non-negative value, and
> E1 * 2**E2 is representable in the corresponding unsigned type of
> the result type, then that value, converted to the result type,
> is the resulting value; otherwise, the behavior is undefined.
>
> I don't know why that change was made.
From what I understand, the change was made because compilers were
expressly forbidden from accepting any expression that invoked Undefined
Behavior in any context requiring a compile-time constant. In C++, there
is a construct which means, "try interpreting the following code with
various type substitutions until one is found that works"; it would be
of limited usefulness if a substitution that could launch missiles even
before any user code executes could be chosen in preference to one which
behaved in defined fashion.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-28 22:23 +0200 |
| Message-ID | <oe085f$tpl$1@dont-email.me> |
| In reply to | #108684 |
On 28/04/17 21:21, Keith Thompson wrote:
> supercat@casperkitty.com writes:
>> 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 fail to see how wrapping it in a function made it any clearer, but OK.
>
>> 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.
>
> You're right. That change was made after the ISO C++11 standard,
> and it still appears in the draft C++17 standard (N4296). I was
> mistaken when I previously stated otherwise. Apparently it also
> appears in C++14 (I don't have a copy).
>
> Note that the result is implementation-defined, because the result of
> the conversion is implementation-defined. (It's undefined behavior
> in C.)
>
> Here's the wording from the C++11 standard, discussing E1 << E2
> (changing some of the punctuation to avoid non-ASCII characters):
>
> Otherwise, if E1 has a signed type and non-negative value,
> and E1 * 2**E2 is representable in the result type, then that
> is the resulting value; otherwise, the behavior is undefined.
>
> The N4296 draft of C++17 says:
>
> Otherwise, if E1 has a signed type and non-negative value, and
> E1 * 2**E2 is representable in the corresponding unsigned type of
> the result type, then that value, converted to the result type,
> is the resulting value; otherwise, the behavior is undefined.
>
> I don't know why that change was made.
I'd been looking at the C++11 standard - it had not occurred to me that
there would be such a change between standard versions.
>
> To answer your original question, a C++ implementation that uses
> C intermediate code must do whatever is necessary to ensure that
> it behaves in accordance with whichever C++ standard it claims to
> support. That might or might not involve some extra work for the
> "<<" operator with a signed left operand. I have no idea what any
> such implementations actually do.
>
gcc has this to say about integers:
> The results of some bitwise operations on signed integers (C90 6.3,
> C99 and C11 6.5).
>
> Bitwise operators act on the representation of the value including
> both the sign and value bits, where the sign bit is considered
> immediately above the highest-value value bit. Signed ‘>>’ acts on
> negative numbers by sign extension.
>
> As an extension to the C language, GCC does not use the latitude
> given in C99 and C11 only to treat certain aspects of signed ‘<<’ as
> undefined. However, -fsanitize=shift (and -fsanitize=undefined) will
> diagnose such cases. They are also diagnosed where constant
> expressions are required.
That last paragraph does not sound very clear to me. Did the behaviour
of signed << change between C90 and C99 ?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-28 14:03 -0700 |
| Message-ID | <f079475d-b9b4-4743-a75f-2bf1e255939e@googlegroups.com> |
| In reply to | #108691 |
On Friday, April 28, 2017 at 3:23:20 PM UTC-5, David Brown wrote: > That last paragraph does not sound very clear to me. Did the behaviour > of signed << change between C90 and C99 ? In C89, the behavior was defined in terms of physical bit shifting, regardless of how integers were stored. Thus, the expression -4 << 1 would yield -8 on a two's-complement machine (111...1100 << 1 yields 111...11000) -9 on a ones'-complement machine (111...1011 << 1 yields 111...10110) +8 on a ones'-complement machine (100...0100 << 1 yields 000...01000) Depending upon what one is trying to do with a particular implementation, it may be more helpful to have a left-shift do one of the above (not necessarily the one associated with the hardware platform) or select arbitrarily between them (e.g. on machines where left-shifting a register by one is sometimes slower than adding a number to itself, but is sometimes faster, it may be helpful to let a compiler do whichever is more efficient in any given situation). When porting code among systems, it may also be useful to have an option to trap on situations where behaviors could differ. Short of introducing a new category of behavior, the only way the C99 Standard could allow implementations the freedom to behave in those various *useful* fashions was to treat left shifts of negative numbers as Undefined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-28 14:57 -0700 |
| Message-ID | <ln1ssckxes.fsf@kst-u.example.com> |
| In reply to | #108691 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/04/17 21:21, Keith Thompson wrote:
[...]
>> Here's the wording from the C++11 standard, discussing E1 << E2
>> (changing some of the punctuation to avoid non-ASCII characters):
>>
>> Otherwise, if E1 has a signed type and non-negative value,
>> and E1 * 2**E2 is representable in the result type, then that
>> is the resulting value; otherwise, the behavior is undefined.
>>
>> The N4296 draft of C++17 says:
>>
>> Otherwise, if E1 has a signed type and non-negative value, and
>> E1 * 2**E2 is representable in the corresponding unsigned type of
>> the result type, then that value, converted to the result type,
>> is the resulting value; otherwise, the behavior is undefined.
>>
>> I don't know why that change was made.
>
> I'd been looking at the C++11 standard - it had not occurred to me that
> there would be such a change between standard versions.
I found the C++ DR that triggered the change.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457
The rationale given in the DR is:
As a result, this technique cannot be used in a constant expression,
which will break a significant amount of code.
>> To answer your original question, a C++ implementation that uses
>> C intermediate code must do whatever is necessary to ensure that
>> it behaves in accordance with whichever C++ standard it claims to
>> support. That might or might not involve some extra work for the
>> "<<" operator with a signed left operand. I have no idea what any
>> such implementations actually do.
>>
>
> gcc has this to say about integers:
>
>> The results of some bitwise operations on signed integers (C90 6.3,
>> C99 and C11 6.5).
>>
>> Bitwise operators act on the representation of the value including
>> both the sign and value bits, where the sign bit is considered
>> immediately above the highest-value value bit. Signed ">>" acts on
>> negative numbers by sign extension.
>>
>> As an extension to the C language, GCC does not use the latitude
>> given in C99 and C11 only to treat certain aspects of signed "<<" as
>> undefined. However, -fsanitize=shift (and -fsanitize=undefined) will
>> diagnose such cases. They are also diagnosed where constant
>> expressions are required.
>
> That last paragraph does not sound very clear to me. Did the behaviour
> of signed << change between C90 and C99 ?
C90 says:
The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros. If E1 has an unsigned
type, the value of the result is E1 multiplied by the quantity,
2 raised to the power E2, reduced modulo ULONG_MAX+1 if E1
has type unsigned long, UINT-MAX+1 otherwise. (The constants
ULONG_MAX and UINT_MAX are defined in the header <limits.h>.)
C99 says (and C11 is identical) (I've changed some of the punctuation
to avoid non-ASCII characters):
The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros. If E1 has an unsigned type,
the value of the result is E1 * 2^E2, reduced modulo one more
than the maximum value representable in the result type. If
E1 has a signed type and nonnegative value, and E1 * 2^E2 is
representable in the result type, then that is the resulting
value; otherwise, the behavior is undefined.
The wording for the maximum value of an unsigned type was made more
general due to C99's addition of long long, and the final sentence:
If E1 has a signed type and nonnegative value, and E1 * 2^E2 is
representable in the result type, then that is the resulting value;
otherwise, the behavior is undefined.
was added by C99. It's difficult to say what C90's intent was when E1
is negative. I'd say that sentence was added precisely because the C90
wording was unclear.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-28 15:57 -0700 |
| Message-ID | <7efd0477-ab27-4ce8-a224-6421f7128de2@googlegroups.com> |
| In reply to | #108699 |
On Friday, April 28, 2017 at 4:57:55 PM UTC-5, Keith Thompson wrote: > was added by C99. It's difficult to say what C90's intent was when E1 > is negative. I'd say that sentence was added precisely because the C90 > wording was unclear. The meaning of "shift left" could be ambiguous on a sign-magnitude machine, but the statement that shifted-in bits are zeroes eliminates any ambiguity about how ones'-complement machines should behave [instead mandating what for many purposes would be the less useful behavior]. In two's-complement systems, the behavior of a logical and arithmetic left shift are equivalent, so there would be no need to resolve ambiguities on those systems except in cases where they are configured to do something other than use normal two's- complement semantics.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-28 11:49 -0700 |
| Message-ID | <lnfugsl648.fsf@kst-u.example.com> |
| In reply to | #108674 |
supercat@casperkitty.com writes:
> 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?
Do you have an example of such a case?
I don't know the answer to your question, but a C++ implementation that
generates C intermediate code obviously must conform to the C++
standard. It can do so by generating portable C code (which, if the
cases you describe actually exist, might be some extra effort), or by
relying on the known behavior of the C compiler. That might include
passing additional command-line arguments.
--
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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-26 13:31 +0200 |
| Message-ID | <odq08j$9d8$1@dont-email.me> |
| In reply to | #108520 |
Le 26/04/2017 à 12:32, bartc a écrit : > On 26/04/2017 01:32, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> (It's still a puzzle why I didn't see the clash on my Linux.) >> >> Didn't "man strmode" solve the puzzle for you? (I'd have written >> strmode(3) except that notation seems to be almost unknown these days.) > > Well, the answer is that 'strmode()' doesn't exist on my Linux. > > Otherwise I would have noticed the clash in my tests and done something > about it. > > (The puzzle then becomes why strmode() isn't there; maybe it's only on > FreeBSD or something because I first tried 'man strmode' online and it > was on a site for FreeBSD. I think jacob uses a Mac so that could be > another difference.) > Yes, it is absent in linux but present in my mac, OS X 10.11.6 in /usr/include/string.h I would just suggest that you replace strmode by Strmode, and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-04-26 15:14 +0200 |
| Message-ID | <20170426151409.5cc17fa8419e14b75bba492e@gmail.com> |
| In reply to | #108526 |
On Wed, 26 Apr 2017 13:31:30 +0200 jacobnavia <jacob@jacob.remcomp.fr> wrote: > I would just suggest that you replace strmode by Strmode, and be done > with it. I think renaming his strmode function as Strmode create confusion. I would suggest to rather use an unambiguous name such as strstat, strset, ... or to treat the BSD conflict as a buggy case warning the programmer of the incompatibility if you really like the name.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web