473,583 Members | 2,878 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Warning on assigning a function-returning-a-pointer-to-arrays

Hi. I'm more-or-less a C newbie. I thought I had pointers under control until
I started goofing around with this:

=============== =============== =============== =============== =============== =====
/* A function that returns a pointer-of-arrays to the calling function. */

#include <stdio.h>

int *pfunc(void);

int main(void)
{
int (*pd)[5];

pd = pfunc();

/* Should return 20 and 9 */
printf("\nDigit s are: %d and %d", *(*(pd + 0) + 3), *(*(pd + 1) + 2) );

return 0;
}

int *pfunc(void)
{
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return(*arr);
}

=============== =============== =============== =============== =============== =====
It compiles and works correctly, but the compilers I've tried it on warn me of
"illegal conversion of pointer type" or "suspicious pointer conversion"
regarding:

pd = pfunc();

I'm stumped. I think my syntax is correct, and there's nothing in the
literature or this group's FAQ that tells me otherwise; yet, if I combine the
declaration and initialisation to:

int (*pd)[5] = pfunc();

.. . . the warnings go away. What's up with that?

When I implement what I'm really working towards with this, I won't have the
option of combining the lines, so how serious is this warning?

Any elucidation is greatly appreciated.
--

I.M. (definitely) !Knuth
Jun 26 '06 #1
17 3231
I.M. !Knuth wrote:
Hi. I'm more-or-less a C newbie. I thought I had pointers under control until
I started goofing around with this:

=============== =============== =============== =============== =============== =====
/* A function that returns a pointer-of-arrays to the calling function. */

#include <stdio.h>

int *pfunc(void);

int main(void)
{
int (*pd)[5];

pd = pfunc();

/* Should return 20 and 9 */
printf("\nDigit s are: %d and %d", *(*(pd + 0) + 3), *(*(pd + 1) + 2) );

return 0;
}

int *pfunc(void)
{
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return(*arr);
}

=============== =============== =============== =============== =============== =====
It compiles and works correctly, but the compilers I've tried it on warn me of
"illegal conversion of pointer type" or "suspicious pointer conversion"
regarding:

pd = pfunc();

I'm stumped. I think my syntax is correct, and there's nothing in the
literature or this group's FAQ that tells me otherwise; yet, if I combine the
declaration and initialisation to:

They are different types. My compiler gives a more helpful warning
which says it all:

warning: assignment type mismatch:
pointer to array[5] of int "=" pointer to int

--
Ian Collins.
Jun 26 '06 #2
Ian Collins wrote:
They are different types. My compiler gives a more helpful warning
which says it all:

warning: assignment type mismatch:
pointer to array[5] of int "=" pointer to int


That makes sense. Do you happen to know of a way I can explicitly tell
the compiler:

pd[5] = pfunc();

.. . . or some such? If I enter the above (and I've tried all sorts of
colourful combinations, *s included) I get: "only lvalues may take
assignment" errors.

Thanks for you attention.
--

I.M. (definitely) !Knuth
Jun 26 '06 #3
In article <MP************ ************@ne ws.telus.net>
I.M. !Knuth <no*******@yoyo dyne.com> wrote:
int *pfunc(void);
This declares pfunc as a function taking no arguments and returning
"int *", or "pointer to int". A value of type "pointer to int" can
(but does not necessarily) point to the first of one or more "int"s
in sequence, or even into the middle of such a sequence:

int *p1;
int x, y[4];

p1 = NULL; /* p1 does not point to any "int"s */
p1 = &x; /* p1 points to a single "int" */
p1 = &y[0]; /* p1 points to the first of 4 ints */
p1 = &y[1]; /* p1 points to the second of 4 ints, so p1[-1] is y[0] */

Presumably pfunc() will return a pointer to a single int, or to the
first of a sequence of "int"s.
int main(void)
{
int (*pd)[5];
(Very good definition of main(), by the way. :-) )

"pd" has type "pointer to array 5 of int". As with p1 above, it can
(not necessarily "does") point to the first of one or more "array 5
of int"s in sequence.
pd = pfunc();
Type mismatch: pfunc() returns a pointer to an int, or some int
within a sequence of "int"s. "pd" needs to point to an "array 5
of int", or the first of a sequence of "array 5 of int"s.
/* Should return 20 and 9 */
printf("\nDigit s are: %d and %d", *(*(pd + 0) + 3), *(*(pd + 1) + 2) );
This could be written more clearly as:

printf("\nDigit s are: %d and %d", pd[0][3], pd[1][2]);
return 0;
For strict portability, make sure any output is newline-terminated
(e.g., replace the above printf format "\n..." with "...\n", or
"\n...\n" if you like the extra blank line for some reason).
}

int *pfunc(void)
{
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};
"arr" has type "array 2 of array 5 of int". That is, it is an array
of 2 "things", where each of those "things" is an "array 5 of int".
arr[0] is the first of those things and arr[1] is the second.
return(*arr);
}
Aside: the parentheses here are unnecessary, albeit harmless. The
syntax for "return" statements that return a value is:

return expression;

and of course expressions can be parenthesized. In any case, the
effect is to return a value.

*arr is one way to write arr[0]. This names the entire "array 5
of int" containing the sequence {5, 10, 15, 20, 25}. Whenever you
name an array object in a place where a value is required, C compilers
will produce, as a value, the address of the first element of that
array. Hence:

return arr[0];

"means" the same thing as:

return &arr[0][0];

Hence pfunc() returns a pointer to the "int" holding the value 5
(namely arr[0][0]), which is of course the first of five "int"s
in sequence.

Because C's arrays are always "a sequence of identically-typed
elements with no gaps in between"[%], this sequence of 5 "int"s is
going to be followed by the sequence of 5 "int"s that make up the
object arr[1]. That is, if you can somehow "flatten out" the array,
you get 2 * 5 = 10 "int"s in a row, holding the sequence {5, 10,
15, 20, 25, 3, 6, 9, 12, 15}.
-----
% Or more precisely, if there are gaps, they have to be invisible
as long as you stick to code with defined behavior.
-----

(The C standard does not promise that accessing the array in this
"flattened" manner will always work. There may be some rare
situations in which a clever C compiler tracks array-bounds
information so that it "knows" that, e.g., arr[0][i] can never have
a value of "i" greater than 4, and generates machine code that
actually fails if "i" really is greater than 4. But on real C
compilers on real machines, the flattened access usually does work.
Depending on this is like skating across a frozen pond where someone
has put out a "danger -- thin ice" sign. You will probably be
fine, but if you fall in and freeze to death, you will know who to
blame. :-) )

In this case, with some luck -- it is not clear whether this is
"good luck" or "bad luck" -- if the above code compiles, the value
pfunc() returns will "flatten out" the array, and this value will
be "re-folded" by the assignment to "pd". Having folded, spindled,
and perhaps mutilated the value, the code will go on to access
arr[0][3] and arr[1][2] through the pointer value now stored in
"pd". These two elements of "arr" should contain 20 and 9
respectively; and that is what you actually saw:

It compiles and works correctly, but the compilers I've tried it
on warn me of "illegal conversion of pointer type" or "suspicious
pointer conversion" regarding:

pd = pfunc();
The C standard says only that "a diagnostic" is required. A warning
suffices as a diagnostic, as does having the compiler spin the
CD-ROM really fast so that it makes a horrible whining sound (as
long as the compiler's documentation says as much). An "error"
that aborts compilation entirely is also a valid diagnostic.
I'm stumped. I think my syntax is correct, and there's nothing
in the literature or this group's FAQ that tells me otherwise; yet,
if I combine the declaration and initialisation to:

int (*pd)[5] = pfunc();

. . . the warnings go away. What's up with that?


That would indicate a bug in the compiler, as a diagnostic is
still required.

The "right" thing to do (for some version of "right" at least) is
to have pfunc() return a value of the correct type. This requires
some ugly syntax, or resorting to C's "typedef" type-alias-creating
facility.

Using a typedef -- which merely exchanges one ugly syntax for a
different ugly syntax, in my personal opinion :-) -- we get something
like this:

#include <stdio.h>

typedef int Zog[5]; /* Zog is now an alias for int[5] */

Zog *pfunc(void);

int main(void) {
Zog *pd;

pd = pfunc();
printf("%d and %d\n", pd[0][3], pd[1][2]);
return 0;
}

Zog *pfunc(void) {
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return arr; /* or return &arr[0]; */
}

To eliminate the typedef, we just have to expand it out -- but now
we need parentheses and "[5]"s in awkward places, as with the
original definition for "pd" in main():

int (*pfunc(void))[5];

int main(void) {
int (*pd)[5];

pd = pfunc();
printf("%d and %d\n", pd[0][3], pd[1][2]);
return 0;
}

int (*pfunc(void))[5] {
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return arr; /* or return &arr[0]; */
}

Note that (alas) in C89, pfunc() can only return a pointer to (the
first of several of) "array 5 of int"s. So we can change "arr" to
"static int arr[123][5]", or "static int arr[42][5]", but never to
"static int arr[2][7]", for instance. C99's "variable-length
arrays" and "variably modified" types solve this particular problem.

Aside: I dislike typedefs in general, and I dislike typedefs for
array types even more because of C's peculiar treatment of arrays.
Unlike every other data type, you *must* know whether some type
is an array type in order to predict the behavior of arguments,
and know whether it is OK to return a value of that type. That
is, given the "Zog" typedef above, the following is not valid C:

Zog f(void) {
Zog result;

while (need_more_work ())
fill_it_in(&res ult);
return result;
}

But if we were to replace the typedef line with, e.g.:

struct zog { int val[5]; };
typedef struct zog Zog;

then the function f() above would suddenly become valid C. Similarly,
if we have no idea whether "Morgle" is a typedef for an array type,
we cannot tell whether the following can be simplified:

void operate(void) {
Morgle a, b;

init(&a);
memcpy(&b, &a, sizeof a); /* ??? do we need this ? */

while (more_to_do())
frob(a);

/* make sure frob() did not modify "a" */
if (memcmp(&a, &b) != 0)
printf("alas! alack!\n");
}

If Morgle is *not* an array type, frob() will be unable to modify
"a", because frob() takes the *value* of "a", not the address of
"a". In this case, the copy in "b" is pointless and the memcmp()
will never show them as different, so we do not need the copy.
But if Morgle *is* an array type, frob() receives a pointer to the
first element of "a", and is able to modify "a".

(In some cases we can use "const" to promise, weakly, that frob()
will not modify "a" even if it gets a pointer to the first element;
but this promise can be violated, and in some cases adding "const"
is inappropriate anyway. I think it is better to avoid the situation
entirely.)

(The heart of the problem is really that C treats arrays "specially" .
Because of this, it is important to know whether some purportedly
abstract type is in fact an array type. If so, it will not behave
the way other types behave. C's structure types *do* behave
"properly", so in the limit, all abstract data types should be
"struct"s.)

The one place where even I break down and use "typedef" :-) is for
pointer-to-function types. Consider "signal", which takes two
parameters:

- one, an int specifying which signal, and
- the other, a pointer to a signal-hanlding function

and returns one value:

- a pointer to a signal-handling function

where the repeated type -- "pointer to signal-handling function"
is itself a pointer-to-function-taking-int-and-returning-void,
or "void (*)(int)", complete with awkwardly-placed parentheses,
asterisks, and parameter types. If we write down one typedef for
this particular type, we can then use it twice and get:

typedef void (*Sig_func_ptr) (int);
Sig_func_ptr signal(int sig, Sig_func_ptr func);

Of course, the standard header <signal.h> is not allowed to use
names that are in the user's namespace, so most implementors expand
the types in-line, and omit the parameter names, giving:

void (*signal(int, void (*)(int)))(int) ;

which is confusing at best. If you are the implementor, and
go to write the function's definition, it gets even worse:

void (*signal(int sig, void (*func)(int)))( int) {
void (*old(int, void (*)(int)))(int) ;

if (sig < __MIN_SIGNO || sig >= __MAX_SIGNO)
return SIG_ERR;

some sort of signal atomicity magic here;

old = __sigtable[sig - __MIN_SIGNO];
/*
* May need additional work depending on sig and/or whether
* func == SIG_DFL or SIG_IGN. For instance, instead of the
* crazy top-of-stack "trampoline code" that BSD systems (used
* to?) use, we might do something like this:
*
* if (func == SIG_DFL || func == SIG_IGN)
* kernel_entry = func;
* else
* kernel_entry = __sigtramp;
* __sig_syscall(s ig, kernel_entry, and, any, other, args);
*
* Then the local signal table contains the userland handler,
* while the kernel is told to jump to the trampoline code
* in the library, no matter where that has been loaded.
* Now the library always automatically matches itself, even
* with future version changes, e.g., to save additional state.
*
* I believe Sun did something like this way back in SunOS 4.x
* or 5.0 or so.
*/
__sigtable[sig - MIN_SIGNO] = func;

more atomicity here including check for pending signals;

return old;
}

Of course, signals (with their associated atomicity issues, operating
system interactions, and hardware dependencies) are "relatively deep
magic" in the first place.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Jun 26 '06 #4
I.M. !Knuth <no*******@yoyo dyne.com> writes:
Hi. I'm more-or-less a C newbie. I thought I had pointers under
control until I started goofing around with this:

=============== =============== =============== =============== ============
/* A function that returns a pointer-of-arrays to the calling function. */

#include <stdio.h>

int *pfunc(void);

int main(void)
{
int (*pd)[5];

pd = pfunc();

/* Should return 20 and 9 */
printf("\nDigit s are: %d and %d", *(*(pd + 0) + 3), *(*(pd + 1) + 2) );

return 0;
}

int *pfunc(void)
{
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return(*arr);
}

=============== =============== =============== =============== ============
It compiles and works correctly, but the compilers I've tried it on
warn me of "illegal conversion of pointer type" or "suspicious
pointer conversion" regarding:

pd = pfunc();

I'm stumped. I think my syntax is correct, and there's nothing in
the literature or this group's FAQ that tells me otherwise; yet, if
I combine the declaration and initialisation to:

int (*pd)[5] = pfunc();

. . . the warnings go away. What's up with that?


I don't know. When I tried it, the warning didn't go away.

You need to understand the difference between a pointer-to-int and a
pointer-to-array-of-int. Your function returns a pointer to int. (It
happens to point to the first element of an array). You assign the
result to a pointer-to-array-of-int, an incompatible type.

You can either change the function so it returns a result of type
int(*)[5] (pointer to array of 5 int), or you can change the caller so
it assigns the int* result to an int* variable.

In my opinion, points to arrays are rarely useful. Arrays are
commonly accessed via a pointer to the element type; this allows the
length to vary, rather than requiring a fixed size.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 26 '06 #5
Wow. I weap with gratitude at your thorough analysis of my problem.
Thank you. :-D

Chris Torek wrote:
I.M. !Knuth <no*******@yoyo dyne.com> wrote:
<snip>
int main(void)
{
int (*pd)[5];


(Very good definition of main(), by the way. :-) )


Thanks. I'm trying to go "by the book".

<snip>
/* Should return 20 and 9 */
printf("\nDigit s are: %d and %d", *(*(pd + 0) + 3), *(*(pd + 1) + 2) );


This could be written more clearly as:

printf("\nDigit s are: %d and %d", pd[0][3], pd[1][2]);


I agree that your recommendation is clearer, and I know array-subscript
notation and pointer notation are interchangeable , but I was under the
impression it was preferred practice (style?) to do as I did as a
reminder that it's a pointer and not merely a locally declared array
that is being dereferenced. Is this not correct?
For strict portability, make sure any output is newline-terminated
(e.g., replace the above printf format "\n..." with "...\n", or
"\n...\n" if you like the extra blank line for some reason).
Sound advice, thanks.

<snip>
return(*arr);
}


Aside: the parentheses here are unnecessary, albeit harmless. The
syntax for "return" statements that return a value is:

return expression;


Yeah, I've been flip-flopping on the style of my returns; (note "return
0;" at the end of main() ). :-/

<snip>Because C's arrays are always "a sequence of identically-typed
elements with no gaps in between"[%], this sequence of 5 "int"s is
going to be followed by the sequence of 5 "int"s that make up the
object arr[1]. That is, if you can somehow "flatten out" the array,
you get 2 * 5 = 10 "int"s in a row, holding the sequence {5, 10,
15, 20, 25, 3, 6, 9, 12, 15}.
-----
% Or more precisely, if there are gaps, they have to be invisible
as long as you stick to code with defined behavior.
-----

(The C standard does not promise that accessing the array in this
"flattened" manner will always work. There may be some rare
situations in which a clever C compiler tracks array-bounds
information so that it "knows" that, e.g., arr[0][i] can never have
a value of "i" greater than 4, and generates machine code that
actually fails if "i" really is greater than 4. But on real C
compilers on real machines, the flattened access usually does work.
Depending on this is like skating across a frozen pond where someone
has put out a "danger -- thin ice" sign. You will probably be
fine, but if you fall in and freeze to death, you will know who to
blame. :-) )
Thanks. That pretty much resolves part of my crisis; I was waffling
between: "Hmm, this warning makes me uneasy," and "But what the hey,
the program 'seems' to run properly." I'll take the warning with the
seriousness it was intended.

In this case, with some luck -- it is not clear whether this is
"good luck" or "bad luck" -- if the above code compiles, the value
pfunc() returns will "flatten out" the array, and this value will
be "re-folded" by the assignment to "pd". Having folded, spindled,
and perhaps mutilated the value, the code will go on to access
arr[0][3] and arr[1][2] through the pointer value now stored in
"pd". These two elements of "arr" should contain 20 and 9
respectively ; and that is what you actually saw:
Yes, well your: "perhaps mutilated the value" gives me pause.

<snip>
I'm stumped. I think my syntax is correct, and there's nothing
in the literature or this group's FAQ that tells me otherwise; yet,
if I combine the declaration and initialisation to:

int (*pd)[5] = pfunc();

. . . the warnings go away. What's up with that?


That would indicate a bug in the compiler, as a diagnostic is
still required.


A compiler bug? <grumble, grumble>

You're right too; now that I've checked again, it's just the one
compiler that doesn't repeat the warning.
The "right" thing to do (for some version of "right" at least) is
to have pfunc() return a value of the correct type. This requires
some ugly syntax, or resorting to C's "typedef" type-alias-creating
facility. <snip>

Wow. Using typedef in this situation would never have crossed my mind.
I agree: it's ugly.
To eliminate the typedef, we just have to expand it out -- but now
we need parentheses and "[5]"s in awkward places, as with the
original definition for "pd" in main():

int (*pfunc(void))[5];

int main(void) {
int (*pd)[5];

pd = pfunc();
printf("%d and %d\n", pd[0][3], pd[1][2]);
return 0;
}

int (*pfunc(void))[5] {
static int arr[2][5] = {{5, 10, 15, 20, 25}, {3, 6, 9, 12, 15}};

return arr; /* or return &arr[0]; */
}
int (*pfunc(void))[5]? That rocks! I didn't think that was possible.
So, this is an array-of-functions-that-return-pointers-to-int? Or is
it a (single) function-that-returns-an-array-of-pointers-to-int?
Honestly, I'm not sure what I'm looking at. :-O
Note that (alas) in C89, pfunc() can only return a pointer to (the
first of several of) "array 5 of int"s. So we can change "arr" to
"static int arr[123][5]", or "static int arr[42][5]", but never to
"static int arr[2][7]", for instance. C99's "variable-length
arrays" and "variably modified" types solve this particular problem.
That's fine. For my present purposes arr[][5] will do. While I'm
aware of C99's VLAs and I have access to the ISO, I'm certain none of
my freebie compilers are C99 compliant.
Aside: I dislike typedefs in general, and I dislike typedefs for
array types even more because of C's peculiar treatment of arrays.
Unlike every other data type, you *must* know whether some type
is an array type in order to predict the behavior of arguments,
and know whether it is OK to return a value of that type.

<snip>

I have no bias towards typedef one way or another, but I do try to
refrain from using it. Never would I think to "disguise" an array as
something else with typedef; that's new to me.

I fear the rest of your reply is a tad over my head, but that's not to
say all your typing will be wasted. I'll print out a hardcopy and work
through it until I "get it".

Thanks again for all your help.
--

I.M. (definitely) !Knuth
Jun 26 '06 #6
Keith Thompson wrote:
I.M. !Knuth <no*******@yoyo dyne.com> writes:

<snip>
I'm stumped. I think my syntax is correct, and there's nothing in
the literature or this group's FAQ that tells me otherwise; yet, if
I combine the declaration and initialisation to:

int (*pd)[5] = pfunc();

. . . the warnings go away. What's up with that?


I don't know. When I tried it, the warning didn't go away.

You need to understand the difference between a pointer-to-int and a
pointer-to-array-of-int. Your function returns a pointer to int. (It
happens to point to the first element of an array). You assign the
result to a pointer-to-array-of-int, an incompatible type.

You can either change the function so it returns a result of type
int(*)[5] (pointer to array of 5 int), or you can change the caller so
it assigns the int* result to an int* variable.

In my opinion, points to arrays are rarely useful. Arrays are
commonly accessed via a pointer to the element type; this allows the
length to vary, rather than requiring a fixed size.


Mr. Torec (above) scrutinised my code quite throroughly and I think
I've now got a good handle on what was happening. He also suggests a
compiler bug caused the warning to disappear, an evaluation that
appears spot on. If I read your third paragraph correctly, a believe
his recommendation and yours are in full agreement.

I'm too new (and inexperienced) at C to say how useful (or not)
pointers to arrays are, but since arrays are essentially pointers to
themselves, I think I understand where you're going. What messed me up
in this case was trying to have a function return a single pointer to a
multi-dimensional array.

Thanks for your help.

--

I.M. (definitely) !Knuth
Jun 26 '06 #7
I.M. !Knuth <no*******@yoyo dyne.com> writes:
[...]
int (*pfunc(void))[5]? That rocks! I didn't think that was possible.
So, this is an array-of-functions-that-return-pointers-to-int? Or is
it a (single) function-that-returns-an-array-of-pointers-to-int?
Honestly, I'm not sure what I'm looking at. :-O


See if you can find a program called "cdecl"; it's very useful for
unravelling this kind of thing. For example:

% cdecl
Type `help' or `?' for help
cdecl> explain int (*pfunc(void))[5]
declare pfunc as function (void) returning pointer to array 5 of int

In fact, I used cdecl myself to figure out how to declare a function
returning an array of int, the reverse of the above:

cdecl> declare p as function (void) returning pointer to array 5 of int
int (*p(void ))[5]

I actually thought I had found a bug in cdecl because it seemed just
too ugly to believe, but when I fed it to my compiler (with high
warning levels), it didn't complain.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 26 '06 #8
I.M. !Knuth <no*******@yoyo dyne.com> writes:
[...]
I'm too new (and inexperienced) at C to say how useful (or not)
pointers to arrays are, but since arrays are essentially pointers to
themselves, I think I understand where you're going. What messed me up
in this case was trying to have a function return a single pointer to a
multi-dimensional array.


No, arrays are not essentially pointers to themselves. An array
expression is, in most contexts, implicitly *converted* to a pointer
to its first element.

Arrays are not pointers. Pointers are not arrays. Arrays are arrays.
Pointers are pointers.

Note that the indexing operator, [], is actually defined to work on a
pointer, not on an array. In the most common case:
int arr[10];
...
arr[5]
the prefix "arr" can be used with [] only because it's converted to a
pointer.

Read (or re-read) section 6 of the comp.lang.c FAQ at
<http://www.c-faq.com/>.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 26 '06 #9
Keith Thompson wrote:
<snip>
See if you can find a program called "cdecl"; it's very useful for
unravelling this kind of thing. For example:

% cdecl
Type `help' or `?' for help
cdecl> explain int (*pfunc(void))[5]
declare pfunc as function (void) returning pointer to array 5 of int
Cool, but I note by the "%" it's a *NIX utility. I'm presently tooling
around on a WinXP box. Maybe I'll run it on CygWin or something.
Anyway, I found this link which I gather is the manual way of doing
what cdecl does: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

Now that I know what I'm looking for, I'm amazed at how silent my books
and the Net is on this subject.
In fact, I used cdecl myself to figure out how to declare a function
returning an array of int, the reverse of the above:

cdecl> declare p as function (void) returning pointer to array 5 of int
int (*p(void ))[5]

I actually thought I had found a bug in cdecl because it seemed just
too ugly to believe, but when I fed it to my compiler (with high
warning levels), it didn't complain.


Since I'm new at this, I can't say that this weird syntax is more ugly
or surprising to me than any other, and now that I've discovered the
Left-Right Rule, I think I can grow accustomed to it, though it's all
still dizzying.

Unfortunately, regarding *pfunc(), I'm still not out of the woods.
While . . .

int (*pfunc(void))[5];

.. . . works handily, the real app I'm working on requires that the
function take arguments (I might be getting in way over my head; it's
also meant to be recursive, but that's neither here nor there), so I
changed my test function to:

int (*pfunc(int))[5];

.. . . and now it won't compile at all. Two Borland compilers report
absolutely nothing wrong, but produce no executable, lcc reports "Error
-1" whatever that means, and the little compiler with the warning bug
reports "undefined identifier: num (error)" on the line where "num"
(the int argument passed to *pfunc() ) is used. It seems to me as if
the formal declaration isn't being passed into the function block.
<sigh!>

Thanks for your continued help and advice.
--

I.M. (definitely) !Knuth
Jun 26 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
11183
by: Senthilraja | last post by:
I am able to compile the following code and get "hello" as ouput everytime I execute it:- #include <stdio.h> int main (void) { char *str; str="hello"; puts(str); return 0;
6
95812
by: Jason | last post by:
I have a function (Inet_ntop) that returns const char * and if I try to assign that return value to a char * variable, I get the gcc error message: warning: assignment discards qualifiers from pointer target type Does anyone know what this warning means? Why do I get it? The program compiles and appears to work, but I'd like to understand...
16
5821
by: jose_luis_fdez_diaz_news | last post by:
Hi, If I don't include <libgen.h> I get then warnig below in regcmp call: warning: improper pointer/integer combination: op "=" but if I include it the warning is not shown, but them program compiles fine. What is the warning shown ?
10
1677
by: Rich Sienkiewicz | last post by:
The C# compiler gives warnings about unused variables. I thin it needs a warning about an unassigned reference. For instance, this compiles without any warnings/errors, but of course blows up when run: SqlConnection cnn = null; try { new SqlConnection(myConnectionString); cnn.Open()
6
35663
by: fctk | last post by:
hello, i'm trying to compile this small program: int main(void) { unsigned long int max; max = 4000000000;
4
3620
by: hsupoyang | last post by:
Hi, I would like to dynamic assigning different sets of strings to display on screen, such as, if user choose 1, display "1111", "111111", "111", if user choose 2, display "222", "22222", "2222", "22", if user chooses 3, then "333", "33" Is the following declaration OK? char *str={{"1111", "111111", "111"}, {"222", "22222", "2222",...
27
3106
by: Terry | last post by:
I am getting the following warning for the below function. I understand what it means but how do I handle a null reference? Then how do I pass the resulting value? Regards Warning 1 Function 'Dec2hms' doesn't return a value on all code paths. A null reference exception could occur at run time when the result is used.
1
1754
by: speralta | last post by:
For some reason the text in h2 tag is displaying as white in IE. http://www.salperalta.com/ <td class="sidebar" id="sidebar-right"> <div class="block block-listing" id="block-listing-0"> <h2>Easy MLS Search for Oregon and Southwest Washington:</h2> <div class="content"> </div> </div>
9
10515
by: Peithon | last post by:
Hi, This is a very simple question but I couldn't find it in your FAQ. I'm using VC++ and compiling a C program, using the /TC flag. I've got a function for comparing two strings int strspcmp(const char * s1, const char * s2) {
12
3632
by: elliot.li.tech | last post by:
Hello everyone, I'm migrating a C++ program from 32-bit systems to 64-bit systems. The old programmers used some annoying assignments like assigning "long" to "int", which may lead to data loss. Is it possible to let the compiler (specifically, GCC) spew some warnings on this kind of implicit type casts? Or you suggest use some other...
0
7888
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
8159
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7922
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
8185
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6571
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5689
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3811
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3836
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1416
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.