Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379356
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Call to a function |
| Date | 2023-10-29 05:47 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86msw11tpp.fsf@linuxsc.com> (permalink) |
| References | (2 earlier) <87zg1et4wv.fsf@nosuchdomain.example.com> <86jzs3de3h.fsf@linuxsc.com> <87h6n7tkv4.fsf@nosuchdomain.example.com> <86ttqf2w6p.fsf@linuxsc.com> <uha85r$ha56$1@dont-email.me> |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 10/24/23 8:54 PM, Tim Rentsch wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> [...] >>> >>>> The point isn't quite the same. The C standard explicitly says >>>> integers may be converted to any pointer type. The C standard >>>> does not say that a pointer to an object type may be converted >>>> to a pointer to function type. Every implementation is within >>>> its rights to reject any program whose static text includes[*] a >>>> cast from a pointer to an object type to a pointer to function >>>> type, regardless of whether the cast has any chance of being >>>> executed. >>>> >>>> [*] meaning, still present as source of any preprocessor >>>> conditionals have been processed, etc. >>> >>> I disagree. (I think we've discussed this before.) >>> >>> Concretely, I believe that this program violates no syntax error >>> or constraint. It includes code whose behavior would be undefined >>> if it were executed, but the `if (0)` prevents that. >>> >>> On what basis do you think a conforming implementation may reject >>> it? >> >> First let me ask a question. Does the C standard allow an >> implementation to reject any program that is not strictly >> conforming? > > [...] > > The standard never talks about rejection. It requires that "A > conforming hosted implementation shall accept any strictly > conforming program.". No such requirement applies to any program > which is not strictly conforming. (4p6) Perhaps I shouldn't have used the word "reject". If the question were phrased "Does the C standard allow an implementation not to accept any program that is not strictly conforming?", does your comment above mean you would say Yes to that question?
Back to comp.lang.c | Previous | Next — Next in thread | Find similar | Unroll thread
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-29 05:47 -0700
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-29 14:40 -0700
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-10 06:33 -0800
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-17 21:16 -0800
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-19 00:09 -0800
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:20 -0800
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-19 12:49 -0800
Re: Call to a function Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 03:27 +0000
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-21 20:14 -0800
Re: Call to a function scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:36 +0000
Re: Call to a function Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:05 +0000
Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 18:50 -0500
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 18:11 -0800
Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 14:19 -0500
csiph-web