Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379517
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Call to a function |
| Date | 2023-11-19 00:09 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <865y1yxiyw.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:
> The code we're discussing was snipped at some point, so here it
> is again:
>
> int main(void) {
> int obj = 42;
> typedef void func(void);
> if (0) {
> func *fptr = (func*)&obj;
> fptr();
> }
> }
>
> It illustrates the issue that the standard does not define the behavior
> of a conversion from an object pointer type to a function pointer type
> (other than the special case of a null pointer constant), but does not
> make such conversion, expressed as a cast, a constraint violation.
>
> I asked: "On what basis do you think a conforming implementation may
> reject it?
The code is not strictly conforming.
> Do you see a syntax rule or constraint that it violates?
No.
> Do you see some other basis for rejecting it?"
Yes. The conversion expression can be untranslatable on some
platforms. That means any such expression cannot be part of
a strictly conforming program.
> To be clear, I'm asking about whether an implementation may reject it
> specifically because of the pointer conversion, not about reasons for
> rejecting it that would apply equally to a "hello, world" program.
It is the pointer conversion expression that makes the program be
not strictly conforming.
> Feel free to disregard the following paragraphs.
>
> The impression I get (very likely a wrong one) is that you are
> trying to use a Socratic method,
I'm not.
> 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.
I have no interest in treating you as a student. I'd be much
happier if you would do more thinking for yourself.
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