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

Groups > comp.lang.c > #396068 > unrolled thread

function pointer question

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

Contents

  function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 07:24 +0000
    Re: function pointer question Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 09:04 +0000
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 14:42 +0000
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 14:45 +0000
    Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-02 02:52 -0800
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 14:43 +0000
        Re: function pointer question highcrew <high.crew3868@fastmail.com> - 2026-01-02 17:21 +0100
          Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-02 09:37 -0800
          Re: function pointer question Ben Bacarisse <ben@bsb.me.uk> - 2026-01-03 03:33 +0000
            Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-03 07:41 -0800
              Re: function pointer question Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 21:46 +0000
                Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-04 12:03 +0100
              Re: function pointer question Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-06 20:41 +0000
                Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-07 07:18 -0800
                  Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 21:52 -0800
                    Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-08 09:17 +0100
    Re: function pointer question Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 17:48 +0000
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 19:35 +0000
        Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-02 12:07 -0800
          Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-03 06:06 +0000
        Re: function pointer question Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 21:50 +0000
        Re: function pointer question Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 21:52 +0000
          Re: function pointer question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-02 14:18 -0800
            Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-03 13:55 +0100
              Re: function pointer question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-03 12:04 -0800
                Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-03 13:01 -0800
                  Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:35 -0800
                    Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-07 08:17 -0800
                      Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-07 08:23 -0800
                        Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 18:44 -0800
                      Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 18:27 -0800
                Re: function pointer question Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 22:05 +0000
              Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-03 16:39 -0800
                Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-04 12:15 +0100
              Re: function pointer question Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-06 20:33 +0000
                Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:01 -0800
          Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-03 06:08 +0000
            Re: function pointer question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-05 12:40 -0800
              Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 04:30 +0000
                Re: function pointer question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-06 17:05 -0800
        Re: function pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-03 17:20 -0500
          Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-03 16:48 -0800
          Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-05 08:39 +0000
            Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 12:32 +0000
              Re: function pointer question highcrew <high.crew3868@fastmail.com> - 2026-01-06 13:59 +0100
                Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 13:57 +0000
                Re: function pointer question antispam@fricas.org (Waldek Hebisch) - 2026-01-06 14:50 +0000
                  Re: function pointer question highcrew <high.crew3868@fastmail.com> - 2026-01-06 21:44 +0100
                    Re: function pointer question scott@slp53.sl.home (Scott Lurndal) - 2026-01-06 22:08 +0000
                      Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:59 -0800
                    Re: function pointer question antispam@fricas.org (Waldek Hebisch) - 2026-01-07 09:25 +0000
                      Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-07 11:37 +0100
              Re: function pointer question Michael S <already5chosen@yahoo.com> - 2026-01-06 15:47 +0200
                Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 14:01 +0000
              Re: function pointer question David Brown <david.brown@hesbynett.no> - 2026-01-06 15:55 +0100
                Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 16:44 +0000
              Re: function pointer question scott@slp53.sl.home (Scott Lurndal) - 2026-01-06 15:41 +0000
                Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 16:45 +0000
              Re: function pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 10:58 -0500
                Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-06 16:49 +0000
                  Re: function pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 12:09 -0500
                    Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-07 21:18 +0000
                Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 09:14 -0800
                Re: function pointer question Andrey Tarasevich <noone@noone.net> - 2026-01-10 19:17 -0800
                  Re: function pointer question "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-10 22:39 -0500
                  Re: function pointer question Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:49 -0800
          Re: function pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 06:47 -0500
    Re: function pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-02 14:03 -0500
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 19:41 +0000
    Re: function pointer question bart <bc@freeuk.com> - 2026-01-02 19:18 +0000
      Re: function pointer question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-02 11:43 -0800
      Re: function pointer question Michael Sanders <porkchop@invalid.foo> - 2026-01-02 19:44 +0000

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

#396122

On 2026-01-02 14:35, Michael Sanders wrote:
> On Fri, 2 Jan 2026 17:48:16 -0000 (UTC), Kaz Kylheku wrote:
>
>> On 2026-01-02, Michael Sanders <porkchop@invalid.foo> wrote:
[restore snippage]
>>> void moo(char HISTORY[][64], int hst_len, int invalid, const char
>>> *gme_msg)
>>>
>>> void mastermind(char HISTORY[][64], int hst_len, int invalid, const
>>> char *gme_msg)
>>>
>>> to use either i have:
>>>
>>> void (*render)(char [][64], int, int, const char *) = MOO ? moo :
>>> mastermind;
>>>
>>> my multi-part question:
>>>
>>> why is void required for the function pointer?
...
> Its void that's throwing me Kaz. I'm not sure what to think when
> it comes to void pointers.

The pointer named render should be declared with 'void' at the beginning
because moo and mastermind are declared with a 'void' at the beginning.

Consider the following alternative:

int imoo(char HISTORY[][64], int hst_len, int invalid, const char *gme_msg)
int imastermind(char HISTORY[][64], int hst_len, int invalid, const char
*gme_msg)

int (*irender)(char [][64], int, int, const char *) = MOO ? imoo :
imastermind;

irender requires 'int' at the beginning because imoo and imastermind
have 'int' at the beginning. That is the return type of the function.

The only difference is that 'void' is, in this context, a special
keyword indicating that the function does not return a value. Since the
function has no return type, it's convenient to insert 'void' in the
same location that would otherwise have contained the type of the value
returned.

Similarly, in C, the declaration "int foo()" is an old-style K&R
declaration that says that foo is a function that takes an unspecified
number of arguments of unspecified types. K&R declarations were found to
be too error-prone, but the language still allows them for backwards
compatibility. When C was first standardized, K&R declarations were
replace with prototype declarations which specified the type of each
argument, which allowed error checking.
The natural way for a prototype declaration to say "no arguments" would
have been to simply specify no arguments, and C++ uses that approach.
However, since C still supports the old K&R declarations, a different
method was used. "int foo(void)" is a function prototype that says that
foo doesn't take any arguments.

The third meaning for 'void' is a special meaning for pointers: "void
*p" declares a pointer that can store any pointer to an object.


> A void pointer (the pointer itself) is not of the type
> it points to no? ...

Of course not. In general, if the type of the thing pointed at is "X",
the type of the pointer itself is "pointer to X". However, a void
pointer has the type "pointer to void". Note: there are no void pointers
in your code. The pointer named render has the type "pointer to a
function returning void with arguments of the types ...".

> ... Its typeless & unknown at compile time

No, it very definitely has a type, "pointer to void", and if that type
were not known at compile time, the compiler wouldn't know what to do
with it. Because it does know the type, it can take the following code:

int i;
void *p = &i;

and translate it into machine language that creates a pointer to an int
which points at 'i', and converts it into a pointer to void (on many
systems, that conversion is a no-op, but on some machines pointers to
different types can have different representations) before storing it in
'p'.

> A 'normal' pointer in C is a variable that stores the address
> of another variable. And *is of the type it points to*...

No, it does not. "pointer to X" is a different type from "X".

> char str[] = "learning publicly is a humbling experience.";
123456789012345678901234567890
> char *ptr = str;

In this case, str has the type "char[

>
> Then void enters stage left...
>
> void *genericPointer;
>
> It can point to an integer, a character, a structure, or any other type.

It can only point at object types. It cannot point at function types.

> void *genericPointer = &intValue; void *genericPointer = str[];
>
> And it seems to survive a lack of type at compile time.
> Man I'm confused on this. I mean I get void is flexible,
> but 'void' is not void in any sense... its like a mask in some
> way (I'm groping for a definition) I need to study void more.
void* is a pointer type that can point at objects of any type. However,
it must be converted back to a pointer to the appropriate type before
the converted pointer can be used to access the object.

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

#396131

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> Similarly, in C, the declaration "int foo()" is an old-style K&R
> declaration that says that foo is a function that takes an unspecified
> number of arguments of unspecified types. K&R declarations were found to
> be too error-prone, but the language still allows them for backwards
> compatibility. When C was first standardized, K&R declarations were
> replace with prototype declarations which specified the type of each
> argument, which allowed error checking.
> The natural way for a prototype declaration to say "no arguments" would
> have been to simply specify no arguments, and C++ uses that approach.
> However, since C still supports the old K&R declarations, a different
> method was used. "int foo(void)" is a function prototype that says that
> foo doesn't take any arguments.
[...]

Some of this changed in C23.  I don't have all the details off the top
of my head, but as I understand it old-style function definitions
are no longer allowed and `int foo()` is equivalent to `int foo(void)`.

(Which means, I think, that my argument that `int main()` has undefined
behavior does not apply in C23.)

It's still not a bad idea to write (void) on a parameterless function
declaration/definition unless you're sure your code will be compiled
only with a compiler that implements C23 or later.

The 2023 ISO C standard is expensive, but the closest draft is:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

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

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

#396159

On Sat, 3 Jan 2026 17:20:16 -0500, James Kuyper wrote:

> [...]

James, earnest thanks for the time you've spent in your
reply I /really/ appreciate it (Keith & others too).

I'm going to dig in on the void issue & get a grip on
understanding it better. I might have questions down the
road & am thankful for everyone's kindness & forbearance.

Must run (short handed at work).

-- 
:wq
Mike Sanders

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

#396203

On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:

> I might have questions down the road...

One more question, but 1st the context...

I asked ChatGPT this question:

    In C, what is the most common meaning of (void) *foo

Its reply:

    In C, (void) *foo most commonly means:

    “Evaluate *foo, but explicitly discard its value.”

    It is a cast-to-void used to silence warnings about an
    unused expression or unused result.

My question: Why?

-- 
:wq
Mike Sanders

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

#396204

On 1/6/26 1:32 PM, Michael Sanders wrote:
>      “Evaluate *foo, but explicitly discard its value.”
> 
>      It is a cast-to-void used to silence warnings about an
>      unused expression or unused result.
> 
> My question: Why?

I'll throw a guess on the wall :)

In C++ you might want to get side effect from some overloaded
operator.  In C the only reason I could think of for for
evaluating *foo and discarding the result would be if *foo
was volatile, and in this way you are poking at some
hardware-mapped address.

-- 
High Crew

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

#396208

On Tue, 6 Jan 2026 13:59:20 +0100, highcrew wrote:

> On 1/6/26 1:32 PM, Michael Sanders wrote:
>>      “Evaluate *foo, but explicitly discard its value.”
>> 
>>      It is a cast-to-void used to silence warnings about an
>>      unused expression or unused result.
>> 
>> My question: Why?
> 
> I'll throw a guess on the wall :)
> 
> In C++ you might want to get side effect from some overloaded
> operator.  In C the only reason I could think of for for
> evaluating *foo and discarding the result would be if *foo
> was volatile, and in this way you are poking at some
> hardware-mapped address.

I can see that but... why not just declare as volatile in that case?

-- 
:wq
Mike Sanders

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

#396210

highcrew <high.crew3868@fastmail.com> wrote:
> On 1/6/26 1:32 PM, Michael Sanders wrote:
>>      “Evaluate *foo, but explicitly discard its value.”
>> 
>>      It is a cast-to-void used to silence warnings about an
>>      unused expression or unused result.
>> 
>> My question: Why?
> 
> I'll throw a guess on the wall :)
> 
> In C++ you might want to get side effect from some overloaded
> operator.  In C the only reason I could think of for for
> evaluating *foo and discarding the result would be if *foo
> was volatile, and in this way you are poking at some
> hardware-mapped address.

Well, '(void)*foo' effectively says "foo" is not a null pointer
(otherwise if would be undefined behaviour).  Good optimizer
will _not_ dereference foo, but keep information for further
use.

-- 
                              Waldek Hebisch

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

#396229

On 1/6/26 3:50 PM, Waldek Hebisch wrote:
> Well, '(void)*foo' effectively says "foo" is not a null pointer
> (otherwise if would be undefined behaviour).  Good optimizer
> will_not_ dereference foo, but keep information for further
> use.

Hehe, now that I understand more of UB, that is correct, but
I don't think you can *rely* on the optimizer behavior, can you?

-- 
High Crew

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

#396235

highcrew <high.crew3868@fastmail.com> writes:
>On 1/6/26 3:50 PM, Waldek Hebisch wrote:
>> Well, '(void)*foo' effectively says "foo" is not a null pointer
>> (otherwise if would be undefined behaviour).  Good optimizer
>> will_not_ dereference foo, but keep information for further
>> use.
>
>Hehe, now that I understand more of UB, that is correct, but
>I don't think you can *rely* on the optimizer behavior, can you?

Say you have a function xxx defined in a header file, but that
function is only used in certain source files that include that
header file.

  int
  xxx(const char *a, size_t b)
  {
      /* do something with a and b */
  }

When compiling with -Wall, a translation unit that doesn't
reference 'xxx' yet requires other components of the
header file will get a warning (error with -Werror) that
the function was unreferenced.   It is not uncommon to
make a void reference to the function in those translation
units to avoid the warning, e.g.

yyy.c:

#include "xxx.h"

int
yyy(...)
{
   <function body>
   (void)xxx;
}

xxx in this context devolves to a function pointer, IIUC.

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

#396263

scott@slp53.sl.home (Scott Lurndal) writes:

> highcrew <high.crew3868@fastmail.com> writes:
>
>> On 1/6/26 3:50 PM, Waldek Hebisch wrote:
>>
>>> Well, '(void)*foo' effectively says "foo" is not a null pointer
>>> (otherwise if would be undefined behaviour).  Good optimizer
>>> will_not_ dereference foo, but keep information for further
>>> use.
>>
>> Hehe, now that I understand more of UB, that is correct, but
>> I don't think you can *rely* on the optimizer behavior, can you?
>
> Say you have a function xxx defined in a header file, but that
> function is only used in certain source files that include that
> header file.
>
>   int
>   xxx(const char *a, size_t b)
>   {
>       /* do something with a and b */
>   }
>
> When compiling with -Wall, a translation unit that doesn't
> reference 'xxx' yet requires other components of the
> header file will get a warning (error with -Werror) that
> the function was unreferenced.   It is not uncommon to
> make a void reference to the function in those translation
> units to avoid the warning, e.g.
>
> yyy.c:
>
> #include "xxx.h"
>
> int
> yyy(...)
> {
>    <function body>
>    (void)xxx;
> }

It seems better to address this problem in the header file
itself.  It's easy to do that by adding a second function
in the header file and having them mutually reference
each other.

> xxx in this context devolves to a function pointer, IIUC.

Just use (void)&xxx.  Now you're sure.

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

#396251

highcrew <high.crew3868@fastmail.com> wrote:
> On 1/6/26 3:50 PM, Waldek Hebisch wrote:
>> Well, '(void)*foo' effectively says "foo" is not a null pointer
>> (otherwise if would be undefined behaviour).  Good optimizer
>> will_not_ dereference foo, but keep information for further
>> use.
> 
> Hehe, now that I understand more of UB, that is correct, but
> I don't think you can *rely* on the optimizer behavior, can you?

Well, there is no warranty, but IME gcc is pretty reliable at
removing such accesses.

-- 
                              Waldek Hebisch

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

#396253

On 07/01/2026 10:25, Waldek Hebisch wrote:
> highcrew <high.crew3868@fastmail.com> wrote:
>> On 1/6/26 3:50 PM, Waldek Hebisch wrote:
>>> Well, '(void)*foo' effectively says "foo" is not a null pointer
>>> (otherwise if would be undefined behaviour).  Good optimizer
>>> will_not_ dereference foo, but keep information for further
>>> use.
>>
>> Hehe, now that I understand more of UB, that is correct, but
>> I don't think you can *rely* on the optimizer behavior, can you?
> 
> Well, there is no warranty, but IME gcc is pretty reliable at
> removing such accesses.
> 

gcc is pretty good at not evaluating an expression that is cast to void 
(unless it has side-effects).  But it is not good at using the 
assumption that "foo" is not null in later code.


If you just want to tell the compiler (and human readers) that "foo" is 
not null, you can be more explicit :


C23 :
	#include <stddef.h>
	if (!foo) unreachable();

Newer gcc :
	
	__attribute__((assume(foo)));

Older gcc :

	if (!foo) __builtin_unreachable();

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

#396206

On Tue, 6 Jan 2026 12:32:43 -0000 (UTC)
Michael Sanders <porkchop@invalid.foo> wrote:

> On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:
> 
> > I might have questions down the road...  
> 
> One more question, but 1st the context...
> 
> I asked ChatGPT this question:
> 
>     In C, what is the most common meaning of (void) *foo
> 
> Its reply:
> 
>     In C, (void) *foo most commonly means:
> 
>     “Evaluate *foo, but explicitly discard its value.”
> 
>     It is a cast-to-void used to silence warnings about an
>     unused expression or unused result.
> 
> My question: Why?
> 

Why what?

There exist a need to selectively silence otherwise useful compiler
warnings. There are no standard ways to do it.
So compilers gave to user ways to express their wishes.

I would speculate that in case of this particular pattern it happened
initially by accident - users found a way to exploit weakness in
compiler's warning logic to achieve desired effect.
Since the usage became widespread, compiler vendors paid attention and
turned accidental behavior into semi-official.

There is similar convention w.r.t. unused function parameters that is
even more widespread.

Does it answer your question or you already knew that and asked about
something else?

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

#396209

On Tue, 6 Jan 2026 15:47:41 +0200, Michael S wrote:

> On Tue, 6 Jan 2026 12:32:43 -0000 (UTC)
> Michael Sanders <porkchop@invalid.foo> wrote:
> 
>> On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:
>> 
>> > I might have questions down the road...  
>> 
>> One more question, but 1st the context...
>> 
>> I asked ChatGPT this question:
>> 
>>     In C, what is the most common meaning of (void) *foo
>> 
>> Its reply:
>> 
>>     In C, (void) *foo most commonly means:
>> 
>>     “Evaluate *foo, but explicitly discard its value.”
>> 
>>     It is a cast-to-void used to silence warnings about an
>>     unused expression or unused result.
>> 
>> My question: Why?
>> 
> 
> Why what?

If its unused, by definition its /unused/...

> There exist a need to selectively silence otherwise useful compiler
> warnings. There are no standard ways to do it.
> So compilers gave to user ways to express their wishes.
> 
> I would speculate that in case of this particular pattern it happened
> initially by accident - users found a way to exploit weakness in
> compiler's warning logic to achieve desired effect.
> Since the usage became widespread, compiler vendors paid attention and
> turned accidental behavior into semi-official.

I cant help but think this is the reason too.

> There is similar convention w.r.t. unused function parameters that is
> even more widespread.
> 
> Does it answer your question or you already knew that and asked about
> something else?

Well, lots of you guys here either do or/did this for a living.
Me? I'm a weekend warrior as it were, so lots of questions about
some of those dark corners...

-- 
:wq
Mike Sanders

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

#396211

On 06/01/2026 13:32, Michael Sanders wrote:
> On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:
> 
>> I might have questions down the road...
> 
> One more question, but 1st the context...
> 
> I asked ChatGPT this question:
> 
>      In C, what is the most common meaning of (void) *foo
> 
> Its reply:
> 
>      In C, (void) *foo most commonly means:
> 
>      “Evaluate *foo, but explicitly discard its value.”
> 
>      It is a cast-to-void used to silence warnings about an
>      unused expression or unused result.
> 
> My question: Why?
> 

It is not uncommon for people to have "-Wunused" warnings enabled in 
their builds.  If you have declared variables in a function, and 
possibly assigned values to them, but don't read them or use them, 
that's likely a mistake in your code.  The compiler can eliminate the 
unused variables and associated calculations, but a warning can remind 
you that your function is perhaps not finished yet.  Similarly, warnings 
on unused parameters can be helpful if you have forgotten something.

But sometimes you know you don't need the variables or parameters, but 
you might still want to have the declarations there.  Maybe they are 
used with some builds with different conditional compilation, or you 
know you might need them later.  Maybe you have extra parameters because 
the function has to fit a particular set of parameter types, even though 
in some cases you don't need them all.  (In C23, you can leave a 
parameter unnamed in the definition - but not prior to C23.)

As a way to silence such warnings - or as an indication to human readers 
that you know you don't need the value - you can cast the value to void.

It can also be used for discarding values from a function return marked 
"[[nodiscard]]" in C23 (or using equivalent compiler-specific features 
prior to C23), or after reading a volatile variable when you want the 
read to be done, but don't care about the value.

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

#396221

On Tue, 6 Jan 2026 15:55:37 +0100, David Brown wrote:

> But sometimes you know you don't need the variables or parameters, but 
> you might still want to have the declarations there.  Maybe they are 
> used with some builds with different conditional compilation, or you 
> know you might need them later.  Maybe you have extra parameters because 
> the function has to fit a particular set of parameter types, even though 
> in some cases you don't need them all.  (In C23, you can leave a 
> parameter unnamed in the definition - but not prior to C23.)

Hmm. Yes this makes sense too. Thanks David I'm soaking up the knowledge
as quickly as I can =)

-- 
:wq
Mike Sanders

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

#396214

Michael Sanders <porkchop@invalid.foo> writes:
>On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:
>
>> I might have questions down the road...
>
>One more question, but 1st the context...
>
>I asked ChatGPT this question:
>
>    In C, what is the most common meaning of (void) *foo
>
>Its reply:
>
>    In C, (void) *foo most commonly means:
>
>    “Evaluate *foo, but explicitly discard its value.”
>
>    It is a cast-to-void used to silence warnings about an
>    unused expression or unused result.
>
>My question: Why?

Perhaps the access has side effects[*].   Software might only care
about the side effect of the access, not the result returned.

[*] For example, an access to a memory mapped control register.

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

#396222

On Tue, 06 Jan 2026 15:41:59 GMT, Scott Lurndal wrote:

> Perhaps the access has side effects[*].   Software might only care
> about the side effect of the access, not the result returned.
> 
> [*] For example, an access to a memory mapped control register.

That's a good candidate too!

-- 
:wq
Mike Sanders

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

#396216

On 2026-01-06 07:32, Michael Sanders wrote:
> On Mon, 5 Jan 2026 08:39:53 -0000 (UTC), Michael Sanders wrote:
> 
>> I might have questions down the road...

In the message you were responding to, I was talking about declarations,
not expressions.

> One more question, but 1st the context...
> 
> I asked ChatGPT this question:
> 
>     In C, what is the most common meaning of (void) *foo

I'm curious - in what context did you encounter that code? As written,
it's an expression, and foo would have to be a pointer to an object,
which would be a change of subject from the previous messages in this
thread.

However,

     (void) *foo;

would be a declaration equivalent to

    void *foo;

which is a pointer to void, which would fit the context of our previous
discussion. Could that be what you're actually asking about?

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

#396223

On Tue, 6 Jan 2026 10:58:36 -0500, James Kuyper wrote:

> I'm curious - in what context did you encounter that code? As written,
> it's an expression, and foo would have to be a pointer to an object,
> which would be a change of subject from the previous messages in this
> thread.

I just just managed to get myself confused because there seems to be
more than one way to use void.

> However,
> 
>      (void) *foo;
> 
> would be a declaration equivalent to
> 
>     void *foo;
> 
> which is a pointer to void, which would fit the context of our previous
> discussion. Could that be what you're actually asking about?

Shoot, its just that I lack at the moment the C-specific vocabulary to
describe what I'm wondering about James. Frustrating trust me =) Mainly
its that void seems to be used across multiple contexts (in differing ways).
Keith was saying void has special properties...

Nevertheless, I bumbled through it. Here are the functions:

  void mastermind(int hst_len, const char *gme_msg);
  void moo(int hst_len, const char *gme_msg);
  void bagels(int hst_len, const char *gme_msg);

Here's the latest way I'm using them...

   static void (*mode[])(int, const char *) = { mastermind, moo, bagels };
   void (*render)(int, const char *) = mode[app.idx];

Welp, back to studying for me.

-- 
:wq
Mike Sanders

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

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

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

csiph-web