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

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

declarator

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

Contents

  declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-28 21:58 -0400
    declarator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 19:14 -0700
      Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-28 22:36 -0400
        Re: declarator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 19:46 -0700
        Re: declarator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 11:22 +0100
          Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 16:07 -0400
          Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 16:09 -0400
    Re: declarator Barry Schwarz <schwarzb@dqel.com> - 2015-06-28 21:51 -0700
    Re: declarator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 11:08 +0100
      Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 16:18 -0400
        Re: declarator Barry Schwarz <schwarzb@dqel.com> - 2015-06-29 14:23 -0700
          Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 18:39 -0400
          Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 20:39 -0400
            Re: declarator Keith Thompson <kst-u@mib.org> - 2015-06-29 19:01 -0700
              Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-29 22:13 -0400
                Re: declarator Barry Schwarz <schwarzb@dqel.com> - 2015-06-29 20:45 -0700
                  Re: declarator Keith Thompson <kst-u@mib.org> - 2015-06-30 08:22 -0700
                    Re: declarator Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:44 -0700
                  Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-30 12:48 -0400
                    Re: declarator Barry Schwarz <schwarzb@dqel.com> - 2015-06-30 15:32 -0700
                      Re: declarator John Bode <jfbode1029@gmail.com> - 2015-07-01 13:50 -0700
                        Re: declarator gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-01 21:57 +0000
                          Re: declarator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 15:05 -0700
                            Re: declarator "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-02 20:34 -0400
    Re: declarator Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2015-06-29 14:55 +0000

Page 1 of 2  [1] 2  Next page →

#64406 — declarator

    Ok I came across a new term today. I know of dereferences and 
declarations. But declarator? It's like a pointer to something. I might be 
related to array of pointers or pointers to arrays.

void (*g) (void)

What exactly is this? I see the 'g' is pointing to something. The 
parenthesis throw me off. And it looks like there's no function there.

Bill

[toc] | [next] | [standalone]

#64407

It's an indirect function. Call with g().

Best regards,
Rick C. Hodgin

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

#64408

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote in message 
news:7936ac41-8011-4164-84c3-28727b620f0a@googlegroups.com...
> It's an indirect function. Call with g().
>

    So *g() is a pointer to a function that returns nothing and takes no 
arguments basically right? That's the way I'm beginning to understand it.

Bill

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

#64409

Correct. To declare another type with params:

   int (*example)(int a, char b);

Call with:

    x = example(5,4);

See SEvents structure around line 200:

    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_structs.h 

Best regards,
Rick C. Hodgin

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

#64436

"Bill Cunningham" <nospam@nspam.invalid> writes:

> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote in message 
> news:7936ac41-8011-4164-84c3-28727b620f0a@googlegroups.com...
>> It's an indirect function. Call with g().
>
>     So *g() is a pointer to a function that returns nothing and takes no 
> arguments basically right?

No.  You originally asked about void (*g)(void); and *g() is something
else entirely (for one thing it's a fragment which could be part of
either an expression or part of a declaration).  You'll have to be exact
if you want to understand this stuff because the details matter a lot.
In particular, empty brackets in a function declaration don't mean "no
arguments", they mean "an un-stated number of argument which might be
none".  To say none, you write (void) in that position, as you had in
your original posting.

<snip>
-- 
Ben.

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

#64488

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:877fqmerut.fsf@bsb.me.uk...

> No.  You originally asked about void (*g)(void); and *g() is something
> else entirely (for one thing it's a fragment which could be part of
> either an expression or part of a declaration).  You'll have to be exact
> if you want to understand this stuff because the details matter a lot.

    Ok yes I see now. It is mentioned in the standard at 6.7.6 I believe. 
The wording there is a little tough for me at this time. I am coming across 
this in code and I've never got into more complicated code like this before. 
Never needed too. What learn something you will forget for lack of use.

> In particular, empty brackets in a function declaration don't mean "no
> arguments", they mean "an un-stated number of argument which might be
> none".  To say none, you write (void) in that position, as you had in
> your original posting.

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

#64489

    And I had down pointers to arrays and arrays of pointers too. Lack of 
use would make me to have to restudy it. When needed. Something similar to 
this /might/ be possibly usesd at some point.

Bill

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

#64412

On Sun, 28 Jun 2015 21:58:19 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>    Ok I came across a new term today. I know of dereferences and 
>declarations. But declarator? It's like a pointer to something. I might be 

A declarator is part of a declaration.  It is not like a pointer at
all.  The fact that in your particular example g is a pointer is an
incidental detail.    The similar declaration
    int g
contains the same declarator but there is mention of a pointer.

>related to array of pointers or pointers to arrays.

What part of left field did you pull this out of?  Declarators are no
more, and no less, related to arrays of pointers or pointers to arrays
than they are to int, float, array of int, etc.

>void (*g) (void)
>
>What exactly is this? I see the 'g' is pointing to something. The 

Whatever it is, it is incomplete.  Assuming you left off the
terminating semicolon, it is the declaration of a pointer to function.
But it does not point to anything unless it is initialized or assigned
a value.

>parenthesis throw me off. And it looks like there's no function there.

If you look at qsort, you will see a very similar declaration for the
pointer to the compare function.

Since this is a pointer and not a function, why would you  expect to
see a function there?  In the declaration
    int *x;
x is a pointer to int but there is no int there.

-- 
Remove del for email

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

#64435

"Bill Cunningham" <nospam@nspam.invalid> writes:

>     Ok I came across a new term today. I know of dereferences and 
> declarations. But declarator?

The declarator is the part of a declaration that is syntactically
attached to the name.  It includes that parts that say that a name (or
type) is a pointer or an array or a function, together with qualifiers
like const when they apply to those parts of the type.  In

  const int x = 42, *const ip = &x, (*f)(void);

the "const int" part apples to all the declarations.  It's called a type
specifier and it includes a type qualifier.  The parts "x", "*const ip"
and "(*f)(void)" are three declarators.  Two of the declared objects are
initialised.

<snip>
-- 
Ben.

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

#64492

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:87d20eesim.fsf@bsb.me.uk...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>
>>     Ok I came across a new term today. I know of dereferences and
>> declarations. But declarator?
>
> The declarator is the part of a declaration that is syntactically
> attached to the name.  It includes that parts that say that a name (or
> type) is a pointer or an array or a function, together with qualifiers
> like const when they apply to those parts of the type.  In
>
>  const int x = 42, *const ip = &x, (*f)(void);
>
> the "const int" part apples to all the declarations.  It's called a type
> specifier and it includes a type qualifier.  The parts "x", "*const ip"
> and "(*f)(void)" are three declarators.  Two of the declared objects are
> initialised.

    So I would say here. All return ints. The "function pointer." would be 
"f" pointing to a function that returns int and takes no arguments.

int printthis (void) {...} //declaration and body of function

printthis *f (void); //initialization right? or...

printhis (*f) (void);

Now if those parenthesis around "*f" are needed can someone give a quick 
help. The API I am looking at has an /optional/ pointer to dunction in it's 
code. Coding does not require using it.

Bill


Bill

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

#64502

On Mon, 29 Jun 2015 16:18:13 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
>news:87d20eesim.fsf@bsb.me.uk...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>
>>>     Ok I came across a new term today. I know of dereferences and
>>> declarations. But declarator?
>>
>> The declarator is the part of a declaration that is syntactically
>> attached to the name.  It includes that parts that say that a name (or
>> type) is a pointer or an array or a function, together with qualifiers
>> like const when they apply to those parts of the type.  In
>>
>>  const int x = 42, *const ip = &x, (*f)(void);
>>
>> the "const int" part apples to all the declarations.  It's called a type
>> specifier and it includes a type qualifier.  The parts "x", "*const ip"
>> and "(*f)(void)" are three declarators.  Two of the declared objects are
>> initialised.
>
>    So I would say here. All return ints. The "function pointer." would be 

What do you mean "All"?  Return is an action performed by a function.
Since neither x nor ip is a function, they don't return anything.

>"f" pointing to a function that returns int and takes no arguments.
>
>int printthis (void) {...} //declaration and body of function
>
>printthis *f (void); //initialization right? or...

Not even close.  This declares f as a function that takes no arguments
and returns a pointer to something of type printthis.  Since printthis
is not a type, this is a syntax error 

Initialization is part of the declaration.  You would need the
declaration to look like
     const int (*f)(void) = printthis;
If you wish to assign a value to f after it is defined, use the
original declaration and an assignment statement such as 
     f = printthis;

>printhis (*f) (void);

This is no better.  This declares f as a pointer to function taking no
arguments and returning a value of type printhis.  As above, it is
just syntax error.  Changing printhis to printthis makes no
difference.

>Now if those parenthesis around "*f" are needed can someone give a quick 

Look at the two above.  What does the * apply to?  Without the
parentheses, it applies to the return type (f returns a pointer). With
the parentheses, it applies to the name being declared (f is a
pointer).

>help. The API I am looking at has an /optional/ pointer to dunction in it's 
>code. Coding does not require using it.

What is an optional pointer?  Is it like the third argument to strtol
which either points to a char* or is NULL?  This argument is not
optional.  It must be present in the function call.  The only option
is if it points to something or not.

Whatever it is, if you don't need to use it, you shouldn't need to
define it.  If you do need to use it, you will have provide more
details.

-- 
Remove del for email

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

#64509

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:p2c3pa578rsfhdkfq2olp0bb9vq710lfec@4ax.com...
> On Mon, 29 Jun 2015 16:18:13 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>
>>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>news:87d20eesim.fsf@bsb.me.uk...
>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>
>>>>     Ok I came across a new term today. I know of dereferences and
>>>> declarations. But declarator?
>>>
>>> The declarator is the part of a declaration that is syntactically
>>> attached to the name.  It includes that parts that say that a name (or
>>> type) is a pointer or an array or a function, together with qualifiers
>>> like const when they apply to those parts of the type.  In
>>>
>>>  const int x = 42, *const ip = &x, (*f)(void);
>>>
>>> the "const int" part apples to all the declarations.  It's called a type
>>> specifier and it includes a type qualifier.  The parts "x", "*const ip"
>>> and "(*f)(void)" are three declarators.  Two of the declared objects are
>>> initialised.
>>
>>    So I would say here. All return ints. The "function pointer." would be
>
> What do you mean "All"?  Return is an action performed by a function.
> Since neither x nor ip is a function, they don't return anything.

    Ok I guess yes you are correct. The pointers point to their declared 
type.

>>"f" pointing to a function that returns int and takes no arguments.
>>
>>int printthis (void) {...} //declaration and body of function
>>
>>printthis *f (void); //initialization right? or...
>
> Not even close.  This declares f as a function that takes no arguments
> and returns a pointer to something of type printthis.  Since printthis
> is not a type, this is a syntax error
>
> Initialization is part of the declaration.  You would need the
> declaration to look like
>     const int (*f)(void) = printthis;
> If you wish to assign a value to f after it is defined, use the
> original declaration and an assignment statement such as
>     f = printthis;
>
>>printhis (*f) (void);
>
> This is no better.  This declares f as a pointer to function taking no
> arguments and returning a value of type printhis.  As above, it is
> just syntax error.  Changing printhis to printthis makes no
> difference.
>
>>Now if those parenthesis around "*f" are needed can someone give a quick
>
> Look at the two above.  What does the * apply to?  Without the
> parentheses, it applies to the return type (f returns a pointer). With
> the parentheses, it applies to the name being declared (f is a
> pointer).

    Yes I see now. I didn't catch that. f would simply be a function.

>>help. The API I am looking at has an /optional/ pointer to dunction in 
>>it's
>>code. Coding does not require using it.
>
> What is an optional pointer?

    Optional to use the function pointer in coding. There are other 
interfaces. That is a good question.

Is it like the third argument to strtol
> which either points to a char* or is NULL?  This argument is not
> optional.  It must be present in the function call.  The only option
> is if it points to something or not.
>
> Whatever it is, if you don't need to use it, you shouldn't need to
> define it.  If you do need to use it, you will have provide more
> details.

Bill

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

#64514

    Ok here is just a quickie. Demonstrating the "function pointer." This is 
sloppy because I did get these two warnings after compilation. And I know if 
something was passed to the print wrapper function and the printf specifier 
needed to be something other than %s there would be a problem. But this is 
as I say just a quickie.

#include <stdio.h>

int print(char *);
int (*pf) (char *);

int main()
{
    pf = print("hello there");
    return pf;
}

int print(char *input)
{
    printf("%s\n", input);
    return 0;
}

    And the warnings:

p.c: In function 'main':
p.c:8:8: warning: assignment makes pointer from integer without a cast 
[enabled by default]
     pf = print("hello there");
        ^
p.c:9:5: warning: return makes integer from pointer without a cast [enabled 
by default]
     return pf;
     ^

I did not use -Wall either. as the compiler says "enabled by default. It 
compiles and runs.

Bill

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

#64516

"Bill Cunningham" <nospam@nspam.invalid> writes:
>     Ok here is just a quickie. Demonstrating the "function pointer." This is 
> sloppy because I did get these two warnings after compilation. And I know if 
> something was passed to the print wrapper function and the printf specifier 
> needed to be something other than %s there would be a problem. But this is 
> as I say just a quickie.

Compiler warnings often indicate *serious* problems.  That's not always
the case, but it is here.

> #include <stdio.h>
>
> int print(char *);
> int (*pf) (char *);

Ok, pf is a pointer-to-function.

> int main()
> {
>     pf = print("hello there");

The print() function return a result of type int.  You're trying to
assign that int value to a function pointer.

The name of a function, in an expression context, gives you the address
of (i.e., a pointer to) the function.  The name of a function followed
by parentheses *calls* the function, and gives you the value returned by
the function.

If you want the pointer object pf to point to the function print, you
need to do:

    pf = print;

which is equivalent to:

    pf = &print;

Once you've done that, you can use pf to call the function it points to:

    pf("hello there");

which is equivalent to:

    (*pf)("hello there");

>     return pf;

Now you're trying to return a pointer from main.  Why?

> }
>
> int print(char *input)
> {
>     printf("%s\n", input);
>     return 0;
> }
>
>     And the warnings:
>
> p.c: In function 'main':
> p.c:8:8: warning: assignment makes pointer from integer without a cast 
> [enabled by default]
>      pf = print("hello there");
>         ^
> p.c:9:5: warning: return makes integer from pointer without a cast [enabled 
> by default]
>      return pf;
>      ^
>
> I did not use -Wall either. as the compiler says "enabled by default. It 
> compiles and runs.

gcc has an unfortunate habit of issuing non-fatal warnings for code that
is unambiguously incorrect.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#64519

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnk2um2bv7.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>     Ok here is just a quickie. Demonstrating the "function pointer." This 
>> is
>> sloppy because I did get these two warnings after compilation. And I know 
>> if
>> something was passed to the print wrapper function and the printf 
>> specifier
>> needed to be something other than %s there would be a problem. But this 
>> is
>> as I say just a quickie.
>
> Compiler warnings often indicate *serious* problems.  That's not always
> the case, but it is here.
>
>> #include <stdio.h>
>>
>> int print(char *);
>> int (*pf) (char *);
>
> Ok, pf is a pointer-to-function.
>
>> int main()
>> {
>>     pf = print("hello there");
>
> The print() function return a result of type int.  You're trying to
> assign that int value to a function pointer.
>
> The name of a function, in an expression context, gives you the address
> of (i.e., a pointer to) the function.  The name of a function followed
> by parentheses *calls* the function, and gives you the value returned by
> the function.
>
> If you want the pointer object pf to point to the function print, you
> need to do:
>
>    pf = print;
>
> which is equivalent to:
>
>    pf = &print;

    Of the two above is there a preferred format?

> Once you've done that, you can use pf to call the function it points to:
>
>    pf("hello there");

    Ah hah. I guess I am trying to declare a "pointer to a function" without 
even knowing what it looks like in code and what it's for. Whew. But I am 
seeing.

> which is equivalent to:
>
>    (*pf)("hello there");

    Ok now the above. Is that the way you would want to use this pointer 
function if it wasn't assigned? ie
pf=print;

>>     return pf;
>
> Now you're trying to return a pointer from main.  Why?

    I don't know. I have no idea what Im doing. Til now as you have 
exaplained it to me. I'm not quite sure in what circustance one would want 
to use a pointer to function.

>> }
>>
>> int print(char *input)
>> {
>>     printf("%s\n", input);
>>     return 0;
>> }
>>
>>     And the warnings:
>>
>> p.c: In function 'main':
>> p.c:8:8: warning: assignment makes pointer from integer without a cast
>> [enabled by default]
>>      pf = print("hello there");
>>         ^
>> p.c:9:5: warning: return makes integer from pointer without a cast 
>> [enabled
>> by default]
>>      return pf;
>>      ^
>>
>> I did not use -Wall either. as the compiler says "enabled by default. It
>> compiles and runs.
>
> gcc has an unfortunate habit of issuing non-fatal warnings for code that
> is unambiguously incorrect.

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

#64520

On Mon, 29 Jun 2015 22:13:58 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Keith Thompson" <kst-u@mib.org> wrote in message 
>news:lnk2um2bv7.fsf@kst-u.example.com...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>     Ok here is just a quickie. Demonstrating the "function pointer." This 
>>> is
>>> sloppy because I did get these two warnings after compilation. And I know 
>>> if
>>> something was passed to the print wrapper function and the printf 
>>> specifier
>>> needed to be something other than %s there would be a problem. But this 
>>> is
>>> as I say just a quickie.
>>
>> Compiler warnings often indicate *serious* problems.  That's not always
>> the case, but it is here.
>>
>>> #include <stdio.h>
>>>
>>> int print(char *);
>>> int (*pf) (char *);
>>
>> Ok, pf is a pointer-to-function.
>>
>>> int main()
>>> {
>>>     pf = print("hello there");
>>
>> The print() function return a result of type int.  You're trying to
>> assign that int value to a function pointer.
>>
>> The name of a function, in an expression context, gives you the address
>> of (i.e., a pointer to) the function.  The name of a function followed
>> by parentheses *calls* the function, and gives you the value returned by
>> the function.
>>
>> If you want the pointer object pf to point to the function print, you
>> need to do:
>>
>>    pf = print;
>>
>> which is equivalent to:
>>
>>    pf = &print;
>
>    Of the two above is there a preferred format?
>
>> Once you've done that, you can use pf to call the function it points to:
>>
>>    pf("hello there");
>
>    Ah hah. I guess I am trying to declare a "pointer to a function" without 
>even knowing what it looks like in code and what it's for. Whew. But I am 
>seeing.
>
>> which is equivalent to:
>>
>>    (*pf)("hello there");
>
>    Ok now the above. Is that the way you would want to use this pointer 
>function if it wasn't assigned? ie
>pf=print;

NO!  As you say, the two expressions are equivalent.  Therefore, if pf
has not been assigned or initialized with a value, either attempt to
evaluate it leads to undefined behavior.

You can NEVER use the value of a variable, whether pointer or not,
unless that variable has been given a value.  Under this condition,
the value is said to be indeterminate,  Evaluating an indeterminate
value leads to undefined behavior

>>>     return pf;
>>
>> Now you're trying to return a pointer from main.  Why?
>
>    I don't know. I have no idea what Im doing. Til now as you have 
>exaplained it to me. I'm not quite sure in what circustance one would want 
>to use a pointer to function.

Trying to learn C (or anything else for that matter) in the abstract
is not an easy task.  You would be better served having a goal in mind
and writing code to accomplish that goal.  Then when you run into
problems, instead of writing pointless code where you don't know what
you are doing, you can describe your objective and post the code so
others can help.

>>> }
>>>
>>> int print(char *input)
>>> {
>>>     printf("%s\n", input);
>>>     return 0;
>>> }
>>>
>>>     And the warnings:
>>>
>>> p.c: In function 'main':
>>> p.c:8:8: warning: assignment makes pointer from integer without a cast
>>> [enabled by default]
>>>      pf = print("hello there");
>>>         ^
>>> p.c:9:5: warning: return makes integer from pointer without a cast 
>>> [enabled
>>> by default]
>>>      return pf;
>>>      ^
>>>
>>> I did not use -Wall either. as the compiler says "enabled by default. It
>>> compiles and runs.

It compiles with diagnostics which you have chosen to ignore
(something that should not be done unless you have a VERY THOROUGH
understanding of what the diagnostic means) and APPEARS to run.  Since
you don't know what you want to do, you have no idea if the code
accomplished same.  Given that you ended up assigning an int 0 to a
pointer (making the pointer a NULL pointer which does not point
anywhere), any subsequent attempt to use the pointer to actually call
a function would have failed.  Please tell us this was not your goal.

>> gcc has an unfortunate habit of issuing non-fatal warnings for code that
>> is unambiguously incorrect.

-- 
Remove del for email

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

#64549

Barry Schwarz <schwarzb@dqel.com> writes:
[...]
>>"Keith Thompson" <kst-u@mib.org> wrote in message 
>>news:lnk2um2bv7.fsf@kst-u.example.com...
>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
[...]
>>>> p.c: In function 'main':
>>>> p.c:8:8: warning: assignment makes pointer from integer without a cast
>>>> [enabled by default]
>>>>      pf = print("hello there");
>>>>         ^
>>>> p.c:9:5: warning: return makes integer from pointer without a cast 
>>>> [enabled
>>>> by default]
>>>>      return pf;
>>>>      ^
>>>>
>>>> I did not use -Wall either. as the compiler says "enabled by default. It
>>>> compiles and runs.
>
> It compiles with diagnostics which you have chosen to ignore
> (something that should not be done unless you have a VERY THOROUGH
> understanding of what the diagnostic means) and APPEARS to run.  Since
> you don't know what you want to do, you have no idea if the code
> accomplished same.  Given that you ended up assigning an int 0 to a
> pointer (making the pointer a NULL pointer which does not point
> anywhere), any subsequent attempt to use the pointer to actually call
> a function would have failed.  Please tell us this was not your goal.

Storing a null pointer in pf is the most likely consequence of assigning
the int value 0 to pf, but it's not the only possibility.  There is no
implicit conversion from int to a pointer type -- other than the special
case of a *constant* expression with the value 0, which is a null
pointer constant.  Even an explicit conversion (a cast) from an integer
0 to a pointer does not necessarily yield a null pointer though it
commonly does.

The assignment is a constraint violation.  A compiler
can simply reject it.  If it chooses to accept it the behavior is undefined.

>>> gcc has an unfortunate habit of issuing non-fatal warnings for code that
>>> is unambiguously incorrect.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#65296

Keith Thompson <kst-u@mib.org> writes:

> Barry Schwarz <schwarzb@dqel.com> writes:
> [...]
>>> "Keith Thompson" <kst-u@mib.org> wrote in message 
>>> news:lnk2um2bv7.fsf@kst-u.example.com...
>>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>
> [...]
>
>>>>> p.c:  In function 'main':
>>>>> p.c:8:8: warning: assignment makes pointer from integer without a cast
>>>>> [enabled by default]
>>>>>      pf = print("hello there");
>>>>>         ^
>>>>> p.c:9:5: warning: return makes integer from pointer without a cast 
>>>>> [enabled
>>>>> by default]
>>>>>      return pf;
>>>>>      ^
>>>>>
>>>>> I did not use -Wall either.  as the compiler says "enabled by
>>>>> default.  It compiles and runs.
>>
>> It compiles with diagnostics which you have chosen to ignore
>> (something that should not be done unless you have a VERY THOROUGH
>> understanding of what the diagnostic means) and APPEARS to run.
>> Since you don't know what you want to do, you have no idea if the
>> code accomplished same.  Given that you ended up assigning an int 0
>> to a pointer (making the pointer a NULL pointer which does not
>> point anywhere), any subsequent attempt to use the pointer to
>> actually call a function would have failed.  Please tell us this
>> was not your goal.
>
> Storing a null pointer in pf is the most likely consequence of
> assigning the int value 0 to pf, but it's not the only possibility.
> There is no implicit conversion from int to a pointer type -- other
> than the special case of a *constant* expression with the value 0,
> which is a null pointer constant.  Even an explicit conversion (a
> cast) from an integer 0 to a pointer does not necessarily yield a
> null pointer though it commonly does.
>
> The assignment is a constraint violation.  A compiler can simply
> reject it.  If it chooses to accept it the behavior is undefined.

I feel obliged to point out that there are different opinions on
this question.  I acknowledge your interpretation that this case
is one of undefined behavior.  I believe it is also reasonable
to interpret that Standard as saying this case is a constraint
violation, but if an implementation chooses to accept it then
the behavior is defined (ie, by the semantics of how assignment
and conversion work).  I don't object to you voicing your
opinion, but to be fair I think it should be pointed out that
there are other views on how the Standard should be interpreted
in such cases.

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

#64558

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:t434pahgvcplooij8kdp6kfap4u52bb430@4ax.com...

...
> Trying to learn C (or anything else for that matter) in the abstract
> is not an easy task.  You would be better served having a goal in mind
> and writing code to accomplish that goal.  Then when you run into
> problems, instead of writing pointless code where you don't know what
> you are doing, you can describe your objective and post the code so
> others can help.
...

That is for sure true. And writing small utilities is quite different from 
looking and more complex things. Like these poiner to functions. But as 
Keith has showed me I believe I can do it. Now will I need it. I tend to 
forget some things I don't use.

Bill

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

#64575

On Tue, 30 Jun 2015 12:48:57 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
>news:t434pahgvcplooij8kdp6kfap4u52bb430@4ax.com...
>
>...
>> Trying to learn C (or anything else for that matter) in the abstract
>> is not an easy task.  You would be better served having a goal in mind
>> and writing code to accomplish that goal.  Then when you run into
>> problems, instead of writing pointless code where you don't know what
>> you are doing, you can describe your objective and post the code so
>> others can help.
>...
>
>That is for sure true. And writing small utilities is quite different from 
>looking and more complex things. Like these poiner to functions. But as 
>Keith has showed me I believe I can do it. Now will I need it. I tend to 
>forget some things I don't use.

Pointers to functions are no more complex than any other pointers.
Your complexity problem started when you falsely assumed there was
some special relationship between these pointers and the term
"declarator."

Declarators are always going to be an abstract topic of interest
mostly to language lawyers who write the standard and those who
implement compilers.  If you want to work with pointers to functions,
then start the conversation with that and explain what it is you want
to use such a pointer for.

-- 
Remove del for email

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web