Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #92398 > unrolled thread

“ChattyG takes a college freshman C/C++ programming exam”

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

Contents

  “ChattyG takes a college freshman C/C++ programming exam” Lynn McGuire <lynnmcguire5@gmail.com> - 2023-10-05 17:40 -0500
    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-05 15:57 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Christian Gollwitzer <auriocus@gmx.de> - 2023-10-06 07:36 +0200
      Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-06 11:59 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-07 23:54 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” jak <nospam@please.ty> - 2023-10-08 09:42 +0200
        Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 04:27 -0400
        Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 12:55 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 13:06 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” candycanearter07 <no@thanks.net> - 2023-10-08 06:22 -0500
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 15:03 +0300
              Re: “ChattyG takes a college freshman C/C++ programming exam” Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-15 15:51 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <richard@damon-family.org> - 2023-10-15 17:53 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-16 00:07 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-16 22:01 -0400
                    Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <richard@damon-family.org> - 2023-10-16 22:41 -0400
                    Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-17 12:22 -0400
            Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-08 12:31 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-08 21:17 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:13 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-10 12:18 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” MarioCCCP <NoliMihiFrangereMentulam@libero.it> - 2023-10-13 11:22 +0200
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-13 10:04 -0700
          Re: “ChattyG takes a college freshman C/C++ programming exam” Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-08 13:54 +0100
          Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 11:25 -0400
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 20:07 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-10-08 16:37 +0000
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 20:05 +0300
              Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:13 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-09 13:30 -0700
                  Re: Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 20:33 +0000
                    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-10 12:04 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-10-09 12:17 +0000
                Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:03 +0300
                  Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 20:30 +0000
                    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:45 +0300
                      Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 21:21 +0000
                      Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 21:26 +0000
                      Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 22:41 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-09 21:47 +0100
            Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-08 15:31 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:12 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-10 18:46 -0700
                  Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-11 01:14 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-11 13:47 +0000
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-11 07:56 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:06 +0300
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-09 17:15 -0700
        Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 11:08 -0400
    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 21:06 -0700
      Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 21:10 -0700
      Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:56 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:57 +0300
        Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-12 12:59 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:53 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” Phil Carmody <pc+usenet@asdf.org> - 2023-10-23 15:39 +0300
        Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-23 16:45 +0300

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

#92522

On 10/8/2023 10:13 PM, James Kuyper wrote:
> On 10/8/23 21:17, Richard Damon wrote:
>> On 10/8/23 3:31 PM, Chris M. Thomasson wrote:
> ...
>>> Not sure if that's allowed. A function pointer cast to a void
>>> pointer, which in turn is cast back to a function pointer is
>>> undefined? What am I forgetting here?
>>
>> While not specifically called out as undefined behavior, it also isn't
>> ever said to be allowed.
> 
> Precisely - it is undefined "... by the omission of any explicit
> definition of behavior." (4p2
> 
> 

Right. :^)

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

#92740

On 08/10/23 21:31, Chris M. Thomasson wrote:
> On 10/8/2023 4:22 AM, candycanearter07 wrote:
>> On 10/8/23 04:55, Anton Shepelev wrote:
>>> I disagree.  A function returns the value of its declared
>>> return type.  And although C allows the definition of self-
>>> referential structs, it does allow the declaration of self-
>>> referencial functions.
>>
>> What if you typedef'd the function pointer?
>>
>> Also, you could probably get away with it by just setting 
>> it to a void pointer and casting the return value to the 
>> function pointer.
> 
> Not sure if that's allowed. A function pointer cast to a 
> void pointer, which in turn is cast back to a function 
> pointer is undefined? What am I forgetting here?

mine is not an answer but a doubt : maybe void * and void 
(*) (void) could require different alignment restrictions ?

I dunno whether or not void * has any restriction at all ...


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

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

#92785

MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
> On 08/10/23 21:31, Chris M. Thomasson wrote:
>> On 10/8/2023 4:22 AM, candycanearter07 wrote:
>>> On 10/8/23 04:55, Anton Shepelev wrote:
>>>> I disagree.  A function returns the value of its declared
>>>> return type.  And although C allows the definition of self-
>>>> referential structs, it does allow the declaration of self-
>>>> referencial functions.
>>>
>>> What if you typedef'd the function pointer?
>>>
>>> Also, you could probably get away with it by just setting it to a
>>> void pointer and casting the return value to the function pointer.
>> Not sure if that's allowed. A function pointer cast to a 
>> void pointer, which in turn is cast back to a function pointer is
>> undefined? What am I forgetting here?
>
> mine is not an answer but a doubt : maybe void * and void (*) (void)
> could require different alignment restrictions ?
>
> I dunno whether or not void * has any restriction at all ...

It does.

Object pointers can be converted to void* and back without loss of
information.  Quoting the C standard:

    A pointer to void may be converted to or from a pointer to any
    object type. A pointer to any object type may be converted to a
    pointer to void and back again; the result shall compare equal to
    the original pointer.

Function pointers can be converted to other function pointer types and
back again without loss of information.  Quoting the C standard again:

    A pointer to a function of one type may be converted to a pointer to
    a function of another type and back again; the result shall compare
    equal to the original pointer. If a converted pointer is used to
    call a function whose type is not compatible with the referenced
    type, the behavior is undefined.

But conversions between object pointer types (including void*) and
function pointer types have undefined behavior.

Many implementations do support meaningful conversion between function
pointer types and void* (and POSIX requires such conversions to work at
least for values returned by dlsym()).  On most implementations, all
pointers have the same representation, but that's not required.  A
conforming implementation could, for example, have 64-bit object
pointers and 128-bit function pointers.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#92441

Anton Shepelev <anton.txt@gmail.moc> writes:

> jak to Anton Shepelev:
>
>> > AS: Can a C function return a pointer to itself?
>> > CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
>
> I disagree.  A function returns the value of its declared
> return type.  And although C allows the definition of self-
> referential structs, it does [not] allow the declaration of self-
> referencial functions.

C does not have any way to express the /type/ of a function that returns
a pointer to itself.  But self-referential functions (as most people
would use the term) are commonplace, many of them having very dull and
ordinary types!

>> #include <stdio.h>
>>
>> typedef void (* fptr)(int) ;
>>
>> fptr foo(int n)
>> {
>>      printf("Call n. %d\n", n);
>>      return (fptr)foo;
>> }
>>
>> int main()
>> {
>>      fptr p = foo(1);
>>      p(2);
>>      return 0;
>> }

> You are converting void to function pointer fptr.  This is not
> supported in C.

Not in the fragment shown.  The conversion is from one
pointer-to-function type (void (*(*)(int))(int)) to another (void
(*)(int)) and that's allowed.

The trouble is that foo and foo(1) have different pointer-to-function
types.  If C could express the right type, one could write

  foo(1)(2)(3)(4);

but is it stands we can only write

  foo(1)(2);

before the types go wrong.  A third chained call would try to "call" a
void result.

> You might have taken advantage of
> void*, which is silently convertible to any pointer, but
> then again it does not work with function pointer, and C has
> not analog of void* for functions pointers, so an explicit
> conversion is seem inevitable.

I think it would be reasonable to say that a function /can/ return a
pointer to itself.  It's just that the type will be wrong.  After all,
we are happy to say that (void *)&some_int_var is a pointer to that int
object even though the type is wrong.  To use that pointer to get at the
int object, a conversion is required.  Similarly, to use the pointer
returned by a function like foo, a conversion is required.  I would do
it like this:

  #include <stdio.h>
   
  typedef void (*generic_function_ptr)(void);
  typedef generic_function_ptr (*fintp)(int);
   
  generic_function_ptr foo(int n)
  {
       printf("Call n. %d\n", n);
       return foo;
  }
   
  int main(void)
  {
       ((fintp)((fintp)foo(1))(2))(3);
  }


-- 
Ben.

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

#92444

On 10/8/23 05:55, Anton Shepelev wrote:
> jak to Anton Shepelev:
> 
>>> AS: Can a C function return a pointer to itself?
>>> CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
> 
> I disagree.  A function returns the value of its declared
> return type.  And although C allows the definition of self-
> referential structs, it does allow the declaration of self-
> referencial functions.
> 
>> #include <stdio.h>
>>
>> typedef void (* fptr)(int) ;
>>
>> fptr foo(int n)
>> {
>>      printf("Call n. %d\n", n);
>>      return (fptr)foo;

The line above converts "fptr(*)(int)" to "void(*)(int)'.

>> }
>>
>> int main()
>> {
>>      fptr p = foo(1);>>      p(2);
>>      return 0;
>> }
>>
>> Out:
>>
>> Call n. 1
>> Call n. 2
> 
> You are converting void to function pointer fptr. ...

I see no such conversion in the above code. Could you identify where it
occurs?

> ...  This is
> not supported in C.  You might have taken advantage of
> void*, which is silently convertible to any pointer, but
> then again it does not work with function pointer, and C has
> not analog of void* for functions pointers,so an explicit
> conversion is seem inevitable.

That's true - but the only conversion I can find in the above code is in
fact explicit, not implicit.
It's the function call that has undefined behavior, due to the code's
failure to convert the pointer back to it's original type. There's
nothing wrong with the conversion that is actually present.

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

#92447

James Kuyper to Anton Shepelev:

> > You are converting void to function pointer fptr. ...
>
> I see no such conversion in the above code. Could you
> identify where it occurs?

You are correct.  I overlooked that the OP's ignores the
return value, and therefore need not convert it to anything
to make it useful.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#92445

Anton Shepelev wrote:

> You are converting void to function pointer fptr.  This is not supported
> in C.  You might have taken advantage of void*, which is silently
> convertible to any pointer, but then again it does not work with
> function pointer, and C has not analog of void* for functions pointers,
> so an explicit conversion is seem inevitable.

It mayn't be supported in standard C, but it's a common extension—in fact, 
POSIX _requires_ it in order for the dlsym subroutine to work.



-- 
Blue-Maned_Hawk│shortens to 
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr. 
bluemanedhawk.github.io
Y'know, the one with the thing!

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

#92446

Blue-Maned_Hawk:
[Unicode em-dash replaced with --]
> [functions returning pointers to themselves]
> It mayn't be supported in standard C, but it's a common
> extension--in fact, POSIX _requires_ it in order for the
> dlsym subroutine to work.

How so, when casing the return value (from a different
function pointer) does not solve the problem?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#92460

On 10/8/23 13:05, Anton Shepelev wrote:
> Blue-Maned_Hawk:
> [Unicode em-dash replaced with --]
>> [functions returning pointers to themselves]
>> It mayn't be supported in standard C, but it's a common
>> extension--in fact, POSIX _requires_ it in order for the
>> dlsym subroutine to work.
>
> How so, when casing the return value (from a different
> function pointer) does not solve the problem?

The problem is behavior that is not defined by the C standard. POSIX
solves the problem by defining the behavior:

"Note that conversion from a void * pointer to a function pointer as in:

fptr = (int (*)(int))dlsym(handle, "my_function");

is not defined by the ISO C standard. This standard requires this
conversion to work correctly on conforming implementations."

"This standard" refers to the POSIX standard, not the C standard.

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

#92483

On 10/8/2023 10:13 PM, James Kuyper wrote:
> On 10/8/23 13:05, Anton Shepelev wrote:
>> Blue-Maned_Hawk:
>> [Unicode em-dash replaced with --]
>>> [functions returning pointers to themselves]
>>> It mayn't be supported in standard C, but it's a common
>>> extension--in fact, POSIX _requires_ it in order for the
>>> dlsym subroutine to work.
>>
>> How so, when casing the return value (from a different
>> function pointer) does not solve the problem?
> 
> The problem is behavior that is not defined by the C standard. POSIX
> solves the problem by defining the behavior:
> 
> "Note that conversion from a void * pointer to a function pointer as in:
> 
> fptr = (int (*)(int))dlsym(handle, "my_function");
> 
> is not defined by the ISO C standard. This standard requires this
> conversion to work correctly on conforming implementations."
> 
> "This standard" refers to the POSIX standard, not the C standard.
> 

That about sums it all up. POSIX does not equal the C/C++ standards. If 
a system and one of its C compilers claims support for POSIX, well so be it.

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

#92484

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 10/8/2023 10:13 PM, James Kuyper wrote:
>> On 10/8/23 13:05, Anton Shepelev wrote:
>>> Blue-Maned_Hawk:
>>> [Unicode em-dash replaced with --]
>>>> [functions returning pointers to themselves]
>>>> It mayn't be supported in standard C, but it's a common
>>>> extension--in fact, POSIX _requires_ it in order for the
>>>> dlsym subroutine to work.
>>>
>>> How so, when casing the return value (from a different
>>> function pointer) does not solve the problem?
>> 
>> The problem is behavior that is not defined by the C standard. POSIX
>> solves the problem by defining the behavior:
>> 
>> "Note that conversion from a void * pointer to a function pointer as in:
>> 
>> fptr = (int (*)(int))dlsym(handle, "my_function");
>> 
>> is not defined by the ISO C standard. This standard requires this
>> conversion to work correctly on conforming implementations."
>> 
>> "This standard" refers to the POSIX standard, not the C standard.
>> 
>
>That about sums it all up. POSIX does not equal the C/C++ standards. If 
>a system and one of its C compilers claims support for POSIX, well so be it.

If you're using dlsym  in your application, you are unlikely to be using
a non-POSIX system in the first place.

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

#92521

On 10/9/2023 1:33 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 10/8/2023 10:13 PM, James Kuyper wrote:
>>> On 10/8/23 13:05, Anton Shepelev wrote:
>>>> Blue-Maned_Hawk:
>>>> [Unicode em-dash replaced with --]
>>>>> [functions returning pointers to themselves]
>>>>> It mayn't be supported in standard C, but it's a common
>>>>> extension--in fact, POSIX _requires_ it in order for the
>>>>> dlsym subroutine to work.
>>>>
>>>> How so, when casing the return value (from a different
>>>> function pointer) does not solve the problem?
>>>
>>> The problem is behavior that is not defined by the C standard. POSIX
>>> solves the problem by defining the behavior:
>>>
>>> "Note that conversion from a void * pointer to a function pointer as in:
>>>
>>> fptr = (int (*)(int))dlsym(handle, "my_function");
>>>
>>> is not defined by the ISO C standard. This standard requires this
>>> conversion to work correctly on conforming implementations."
>>>
>>> "This standard" refers to the POSIX standard, not the C standard.
>>>
>>
>> That about sums it all up. POSIX does not equal the C/C++ standards. If
>> a system and one of its C compilers claims support for POSIX, well so be it.
> 
> If you're using dlsym  in your application, you are unlikely to be using
> a non-POSIX system in the first place.

Agreed. :^)

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

#92476

Anton Shepelev wrote:

> Blue-Maned_Hawk:
> [Unicode em-dash replaced with --]

Why?

>> [functions returning pointers to themselves]
>> It mayn't be supported in standard C, but it's a common extension--in
>> fact, POSIX _requires_ it in order for the dlsym subroutine to work.
> 
> How so, when casing the return value (from a different function pointer)
> does not solve the problem?

I was not referring to functions returning pointers to themselves in the 
quoted part of my message.  I was referring to void * being castable to a 
function pointer.



-- 
Blue-Maned_Hawk│shortens to 
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr. 
bluemanedhawk.github.io
Variably constant!

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

#92478

Blue-Maned_Hawk to Anton Shepelev:

> > Blue-Maned_Hawk:
> > [Unicode em-dash replaced with --]
>
> Why?

Oh, it just doesn't go with Usenet, stylistically and
aesthetically.  English plain-text is must like
code -- 7-bit-clean.  And like code (e.g. for Troff or
LaTeX), there are convensions for dashes, /italic/ text,
<URLs>, &c.  Your signature is a mess of Unicode
characters -- terrible :-!

> > > It mayn't be supported in standard C, but it's a
> > > common extension--in fact, POSIX _requires_ it in
> > > order for the dlsym subroutine to work.
> >
> > How so, when casing the return value (from a different
> > function pointer) does not solve the problem?
>
> I was not referring to functions returning pointers to
> themselves in the quoted part of my message.  I was
> referring to void * being castable to a function pointer.

Yes, and I asked why the authors of that API decided not to
use the casing that is guarranteed to work, preferring the
dubious casing of void* to function pointers.  If /I/ were
the designer (should you be afraid?), I should make it two
functions:

   void *        dlsym_o(void *restrict handle, const char *restrict name);
   void(*)(void) dlsym_f(void *restrict handle, const char *restrict name);

because the caller usually knows what he seeks.  If he
doesn't, let it be a single function with a compund return
type.  I am not sure what a good way to do it would be,
however, because, having to declare a struct, (with possibly
an union inside) and an enum just for this function may be
bloat, yet:--

   enum dlsym_type {dsOBJ, dsFUN, dsNA}; /* the 3rd member optional */

   struct dlsym_info
   {  char            is_found; /* flag, optional    */
      enum dlsym_type type    ; /* optional          */
      void *          obj_ptr ; /* NULL if not found */
      void(*)(void)   fun_ptr ; /* NULL if not found */
   }

`optional' above means the element may be omitted from the
interface. For example, dsNA and .is_found are mutually
exclusive, and both the flag and the enum may be done away
with by requiring that the caller use whichever pointer is
not NULL, and consider the symbol not found if both are
NULL.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#92482

Anton Shepelev <anton.txt@gmail.moc> writes:
>Blue-Maned_Hawk to Anton Shepelev:
>
>> > Blue-Maned_Hawk:
>> > [Unicode em-dash replaced with --]
>>
>> Why?
>
>Oh, it just doesn't go with Usenet, stylistically and
>aesthetically.  English plain-text is must like
>code -- 7-bit-clean.  And like code (e.g. for Troff or
>LaTeX), there are convensions for dashes, /italic/ text,
><URLs>, &c.  Your signature is a mess of Unicode
>characters -- terrible :-!
>
>> > > It mayn't be supported in standard C, but it's a
>> > > common extension--in fact, POSIX _requires_ it in
>> > > order for the dlsym subroutine to work.
>> >
>> > How so, when casing the return value (from a different
>> > function pointer) does not solve the problem?
>>
>> I was not referring to functions returning pointers to
>> themselves in the quoted part of my message.  I was
>> referring to void * being castable to a function pointer.
>
>Yes, and I asked why the authors of that API decided not to
>use the casing that is guarranteed to work, preferring the
>dubious casing of void* to function pointers.

Because all POSIX systems of the day had identically
sized function and object pointers, and the committee possibly
did not believe that there would ever be a future architecture
for which POSIX would be useful that had a distinction
between object and function pointers and they had little
interest in obsoleting existing code.

dlsym showed up about 1990 in SVR4, coming from SunOS IIRC.

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

#92485

Scott Lurndal to Anton Shepelev:

> > Yes, and I asked why the authors of that API decided not
> > to use the casing that is guarranteed to work,
> > preferring the dubious casing of void* to function
> > pointers.
>
> Because all POSIX systems of the day had identically sized
> function and object pointers, and the committee possibly
> did not believe that there would ever be a future
> architecture for which POSIX would be useful that had a
> distinction between object and function pointers

Sounds like a instance myopic thinking.  Compliance with the
Standard is always the safest road into the future.  ("Write
it down in your notebooks, gentlemen!"[1])

> and they had little interest in obsoleting existing code.
>
> dlsym showed up about 1990 in SVR4, coming from SunOS
> IIRC.

What was there to obsolete in 1990, or did you mean ever
since?
____________________
1. /One-storied America/

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#92487

Anton Shepelev <anton.txt@gmail.moc> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > Yes, and I asked why the authors of that API decided not
>> > to use the casing that is guarranteed to work,
>> > preferring the dubious casing of void* to function
>> > pointers.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
>
>Sounds like a instance myopic thinking.  Compliance with the
>Standard is always the safest road into the future.  ("Write
>it down in your notebooks, gentlemen!"[1])

The POSIX standard had been successful in supporting a
portability  ecosystem spanning a wide range of
implementations.

Are you aware of any extant implementations for which
the POSIX dlsym requirement doesn't hold?

>
>> and they had little interest in obsoleting existing code.
>>
>> dlsym showed up about 1990 in SVR4, coming from SunOS
>> IIRC.
>
>What was there to obsolete in 1990, or did you mean ever
>since?

There were no dynamically loaded libraries in system V
before SVR4.  There was a limited form of shared library
in SVR3 where the memory for the library would be shared
by multiple processes - each library was linked at a
different physical address and was loaded into that
range.   Quite unwieldy and limited and replaced by
the ELF-based dynamic linking inherited from SunOS
when SUN and USL were developing SVr4.

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

#92488

Anton Shepelev <anton.txt@gmail.moc> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > Yes, and I asked why the authors of that API decided not
>> > to use the casing that is guarranteed to work,
>> > preferring the dubious casing of void* to function
>> > pointers.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
>
>Sounds like a instance myopic thinking.  Compliance with the
>Standard is always the safest road into the future.  ("Write
>it down in your notebooks, gentlemen!"[1])
>
>> and they had little interest in obsoleting existing code.
>>
>> dlsym showed up about 1990 in SVR4, coming from SunOS
>> IIRC.
>
>What was there to obsolete in 1990, or did you mean ever
>since?

The dlsym() interface was added to the SuS in issue 5, call it late 90's.

It was not part of SVID Issue 3 (1989) which formalized the
API changes in SVR4.

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

#92498

On 10/9/23 16:45, Anton Shepelev wrote:
> Scott Lurndal to Anton Shepelev:
> 
>>> Yes, and I asked why the authors of that API decided not
>>> to use the casing that is guarranteed to work,
>>> preferring the dubious casing of void* to function
>>> pointers.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
> 
> Sounds like a instance myopic thinking.  Compliance with the
> Standard is always the safest road into the future. 

I'm not sure I understand what you're trying to say. Which standard are
you referring to, and how is compliance with that standard relevant to
this issue. POSIX is a standard, one which incorporates the C standard
by reference, so any implementation of POSIX includes an C compiler
which conforms to the C standard. There are additional requirements for
compliance with the POSIX standard on top of those that are required for
compliance with the C standard, and this is one example of that.

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

#92486

Anton Shepelev <anton.txt@gmail.moc> writes:

> Blue-Maned_Hawk to Anton Shepelev:
>
>> > Blue-Maned_Hawk:
>> > [Unicode em-dash replaced with --]
>>
>> Why?
>
> Oh, it just doesn't go with Usenet, stylistically and
> aesthetically.

What is aesthetically wrong about using a bullet-point marker?  What
is stylistically wrong about writing accented characters?

> English plain-text is much like
> code -- 7-bit-clean.

That's circular.  By "plain-text" you mean 7-bit clean.  Texts written
in English have, traditionally, used all sort of typographical marks,
and it has always been considered goof style to write correctly.
Phonetic script should be rendered correctly.  Foreign words should be
rendered correctly.

What many people think of a "plain" English text is just what we've been
forced to write by clunky technology; first typewriters and then
computers.  We should more on.  There was a time when people would moan
if I sent a file with lower case letters in it because it could not be
rendered on a CDC mainframe.  Come on, it's the 21st century.

> And like code (e.g. for Troff or
> LaTeX), there are convensions for dashes, /italic/ text,
> <URLs>, &c.  Your signature is a mess of Unicode
> characters -- terrible :-!

BMH has posted a bad signature.  It's not UTF-8 encoded Unicode at all,
despite what the header says.  It is what's called mojibake.

In fact, properly rendered, his sig just contains a few phonetic letters
and, oddly, some "BOX DRAWINGS LIGHT VERTICAL" lines for which I would
have used | (despite what I wrote above).

Of course the fact that he did not post it correctly could be seen as
undermining my case, but I take as a further call to action: come on
BMH, buck up and get it right!

>> I was not referring to functions returning pointers to
>> themselves in the quoted part of my message.  I was
>> referring to void * being castable to a function pointer.
>
> Yes, and I asked why the authors of that API decided not to
> use the casing that is guarranteed to work, preferring the
> dubious casing of void* to function pointers.

Almost certainly a case that the designers knew the system involved and
were solving an immediate problem for one particular OS on a limited
class of machines (SunOS, I think).  They never thought that people
would still be using it, much less critiquing it, 40 years later!

-- 
Ben.

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

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

Back to top | Article view | comp.lang.c++

csiph-web