Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379497
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Call to a function |
| Date | 2023-11-10 06:33 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86edgxznhy.fsf@linuxsc.com> (permalink) |
| References | (4 earlier) <87h6n7tkv4.fsf@nosuchdomain.example.com> <86ttqf2w6p.fsf@linuxsc.com> <uha85r$ha56$1@dont-email.me> <86msw11tpp.fsf@linuxsc.com> <87leblhzud.fsf@nosuchdomain.example.com> |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> 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? >>> >>> [...] Let me respond now to the paragraph below, and get back to your other comments in a later posting. > The impression I get (very likely a wrong one) is that you are > trying to use a Socratic method, asking me questions that you > think will steer me to the correct conclusion -- a conclusion that > you have not shared. I am not speculating about your motivations > (which you hide very well); rather, I am letting you know about the > impression that I get from what you write. I'm interested in what > you think about relevant technical issues, but I'm not interested > in playing the role of your student. To be clear, my question above is meant to elicit your views on what I asked about. My question was not meant to educate you, to be a Socratic question, or to steer you in any particular direction. I was only looking for an answer, nothing more. I ask the question because it is a threshold question for your earlier question upthread. My answer to your prior question depends on this premise for its conclusion. I asked my question separately because I want to clarify the discussion. As things stand, my question has gotten a yes answer from James Kuyper and Kaz, and a no answer from Richard Damon and yourself. I responded to Richard's posting sometime last week but have not seen any followup from him on that. I responded to several of your postings just in the last day, so I'm not sure if you have had a chance yet to read those. If after reading my comments you agree that the C standard allows implementations not to accept any program that is not strictly conforming then I can go ahead and answer your question. If after reading my comments you still do not agree to that premise then there really isn't anything more for me to say other than I believe your understanding of the C standard is not consistent with what its authors intend. I can agree to accept (no pun intended) either view as your final opinion on the matter.
Back to comp.lang.c | Previous | Next — Previous in thread | 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