Is it possible to finding all return values of a C/C++ function?

[binjobster]

Hello everyone,

I'm updating some documents that describes so many C/C++
functions/method(about 2500).
But I'm not familiar with these codes. So I want to find such a utility
can generate returning value list from the codes.
Is it possible? Or is it hard to write one?

Thanks.

 

[Morris Dovey]

(e-mail address removed) (in
(e-mail address removed)) said:

| I'm updating some documents that describes so many C/C++
| functions/method(about 2500).
| But I'm not familiar with these codes. So I want to find such a
| utility can generate returning value list from the codes.
| Is it possible? Or is it hard to write one?

Consider just one possible function:

double binjobster_div(double a, double b)
{ return a/b;
}

I think I'll let you answer your own question.

 

[binjobster]

I'm sorry I forgot to mention that all the code here returns the same
type. Let's say it's a predefined enumeration. So we won't get float or
double.

 

[Ian Collins]

(e-mail address removed) wrote:

Please don't top-post or quote signatures, corrected.

I'm sorry I forgot to mention that all the code here returns the same
type. Let's say it's a predefined enumeration. So we won't get float or
double.

So what do you want to find? Are you trying to predict what the
functions return?

 

[binjobster]

(e-mail address removed) wrote:

Please don't top-post or quote signatures, corrected.

So what do you want to find? Are you trying to predict what the
functions return?

I'm sorry I'm a newbie on news group.

Functions may call another function like below:

RTCODE foo1(TYPE1 a1, TYPE2 a2)
{
if (cond1)
return foo2(...);
else if (cond2)
return foo3(...);
return ERROR_NONE;
}

RTCODE foo2(TYPE1 a1, TYPE2 a2)
{
....
return ERROR_OUT_OF_MEMORY;
}

And reading code to list all the return values of foo1() is time
consuming, so I ask for a utility can do the job automatically.

 

[Dann Corbit]

I'm sorry I forgot to mention that all the code here returns the same
type. Let's say it's a predefined enumeration. So we won't get float or
double.

long long binjobster_div(long long a, long long b)
{ return a/b;
}

There are 3.4e+38 different inputs and 18446744073709551616 different
outputs (unless long long is bigger than 64 bits, in which case it is more).

I guess that you are not patient to enumerate them all, especially since
18446744073709551616 or so combinations result in a trap representation.

I doubt if anyone has the patience or lifespan to complete the task. We
could use the internet, but I doubt if the answer to the question is worth
the bother, since a moment's thought will show us what the answers can be.

In addition, on some machines, int is 64 bits.

I generally try to exhaustively test functions. But when the total bytes of
input (after dereferencing pointers) exceeds 4, I generally switch to
probability based approaches ( along with endpoint tests and other extreme
conditions ).

 

[Ian Collins]

I'm sorry I'm a newbie on news group.

Functions may call another function like below:

RTCODE foo1(TYPE1 a1, TYPE2 a2)
{
if (cond1)
return foo2(...);
else if (cond2)
return foo3(...);
return ERROR_NONE;
}

RTCODE foo2(TYPE1 a1, TYPE2 a2)
{
....
return ERROR_OUT_OF_MEMORY;
}

And reading code to list all the return values of foo1() is time
consuming, so I ask for a utility can do the job automatically.

You won't find one. Just look at your first example, if foo2 or foo3
call other functions, you will very quickly get an exponential growth in
the number of possible returns for any function, or at best any valid
value of RTCODE.

Sounds like a pointless exercise to me.

 

[Dann Corbit]

First suggestion:
Read the project's documentation to find the answers. If that is missing,
go polaxe the project's originator, until he provides the needed
information.

Second suggestion:
If he cannot be located for a good polaxing, then I suggest grepping through
the headers to find the enums and/or #defines that you are searching for and
building your case statements from those.

Third suggestion:
If the headers are missing and the documenation is missing, then it is
better to write a new solution from scratch (no, I'm not kidding).

 

[Snis Pilbor]

Hello everyone,

I'm updating some documents that describes so many C/C++
functions/method(about 2500).
But I'm not familiar with these codes. So I want to find such a utility
can generate returning value list from the codes.
Is it possible? Or is it hard to write one?

Thanks.

If I read you right (in this and your followup posts), all the relevant
functions return predetermined constants from a relatively small pool
of such (ruling out the division function someone else keeps
mentioning). If you are content with simply assuming that if a
function contains the line "return CONSTANT_BLAH" that it is somehow
possible for that function to indeed return CONSTANT_BLAH, then it
wouldn't be overwhelmingly difficult to just program your own simple
program to read in your .c files and parse them. When I say "it
wouldn't be overwhelmingly difficult" though, the emphasis is on
"overwhelmingly", this would probably be a week's worth of work if
you're new to file I/O and/or parsing text. (Well... this is assuming
you can assume the code is pretty well-behaved... if you wanted it to
be guaranteed to work no matter how scandalous the code in question,
then you'd practically have to include an entire preprocessor...)

On the other hand, if you want the program to be intelligent enough to
only count return lines which are actually reachable, then a general
solution would not be Turing computable since it would allow halting
oracles to be created...

S.P.

 

[Morris Dovey]

(e-mail address removed) (in
(e-mail address removed)) said:

|
| Morris Dovey wrote:
|| (e-mail address removed) (in
|| (e-mail address removed)) said:
||
||| I'm updating some documents that describes so many C/C++
||| functions/method(about 2500).
||| But I'm not familiar with these codes. So I want to find such a
||| utility can generate returning value list from the codes.
||| Is it possible? Or is it hard to write one?
||
|| Consider just one possible function:
||
|| double binjobster_div(double a, double b)
|| { return a/b;
|| }
||
|| I think I'll let you answer your own question.

| I'm sorry I forgot to mention that all the code here returns the
| same type. Let's say it's a predefined enumeration. So we won't get
| float or double.

Ok. My trivial example does provide a clue that a utility providing a
general solution isn't practical. If only enumerated values are
returned, then it should be sufficient to examine the sources to
determine which of the enumerated values are actually returned.

That certainly should be possible. Whether or not the utility you want
is hard to write depends on your own talents and skills...

 

[binjobster]

If I read you right (in this and your followup posts), all the relevant
functions return predetermined constants from a relatively small pool
of such (ruling out the division function someone else keeps
mentioning). If you are content with simply assuming that if a
function contains the line "return CONSTANT_BLAH" that it is somehow
possible for that function to indeed return CONSTANT_BLAH, then it
wouldn't be overwhelmingly difficult to just program your own simple
program to read in your .c files and parse them. When I say "it
wouldn't be overwhelmingly difficult" though, the emphasis is on
"overwhelmingly", this would probably be a week's worth of work if
you're new to file I/O and/or parsing text. (Well... this is assuming
you can assume the code is pretty well-behaved... if you wanted it to
be guaranteed to work no matter how scandalous the code in question,
then you'd practically have to include an entire preprocessor...)

On the other hand, if you want the program to be intelligent enough to
only count return lines which are actually reachable, then a general
solution would not be Turing computable since it would allow halting
oracles to be created...

S.P.

Is there any similiar implementations or examples on the problem?

It need some parsing work. I have some experience on stdio and regexp
but don't on such software tools like YACC or bison.

 

[Stephen Sprunk]

I'm sorry I'm a newbie on news group.

Functions may call another function like below:

RTCODE foo1(TYPE1 a1, TYPE2 a2)
{
if (cond1)
return foo2(...);
else if (cond2)
return foo3(...);
return ERROR_NONE;
}

RTCODE foo2(TYPE1 a1, TYPE2 a2)
{
....
return ERROR_OUT_OF_MEMORY;
}

And reading code to list all the return values of foo1() is time
consuming,

That's why code should be documented. The comments for foo2() and
foo3() should clearly state all possible return values; the comments
for foo1() should either enumerate all of those return values plus
ERROR_NONE, or they should say something like "returns ERROR_NONE or
the result of foo2() or foo3()" so that readers know to read through
those functions' comments as well.

In the absence of such documentation, you _must_ assume that foo1()
can return any possible value of type RTCODE (whatever that is). And,
in practice, it's generally a good idea to handle all possible values
even if the comments indicate they shouldn't happen, at least in debug
builds, so that you can handle errors in the comments.

so I ask for a utility can do the job automatically.

Since a utility can't read documentation, you won't get a satisfactory
answer. Fix the documentation and you won't need a utility anyways.

S

 

[Gordon Burditt]

I'm updating some documents that describes so many C/C++

functions/method(about 2500).
But I'm not familiar with these codes. So I want to find such a utility
can generate returning value list from the codes.
Is it possible? Or is it hard to write one?

If the function returns int, and it is written portably, then there are
no more than 65,536 different return values from that function.
(Although int can be larger than 16 bits and often is, portable C can't assume
that.)

If you've got a header file containing a bunch of definitions of error
codes, e.g.:

#define FAIL_LIPSTICK_AT_AIRPORT_SECURITY_GATE 7620

you could try counting the lines in the file.

I suspect determining all the possible return values from a function
is equivalent to the halting problem.

 

[Frederick Gotham]

Gordon Burditt posted:

If the function returns int, and it is written portably, then there are
no more than 65,536 different return values from that function.

Correction: no more than 65 535 different return values.

Minimum range: -32 767 through 32 767

That's 65 535 unique values.

 

[Richard Bos]

If you've got a header file containing a bunch of definitions of error
codes, e.g.:

#define FAIL_LIPSTICK_AT_AIRPORT_SECURITY_GATE 7620

YM

#define FAIL_WATER_BOTTLE_AT_AIRPORT_SECURITY_GATE 7620
#define FAIL_NECESSARY_MEDICINE_AT_AIRPORT_SECURITY_GATE 7621

Argh and cthulhudamn. I _was_ going to fly to London tomorrow and add
some money to the British economy. I'm having serious doubts now.

Richard

 

[Flash Gordon]

Gordon Burditt wrote:

I suspect determining all the possible return values from a function
is equivalent to the halting problem.

Part of the problem of all possible return values is the halting
problem. Since one thing you have to determine is whether the function
will halt (i.e. return). If it never returns the number of possible
return values is 0.

 

[Kevin Handy]

Gordon Burditt posted:




Correction: no more than 65 535 different return values.

Minimum range: -32 767 through 32 767

Correction: -32 768 through 32 767

For unsigned: 0 through 65 535

That's 65 535 unique values.

That's 65 536 values.

 

[Frederick Gotham]

Kevin Handy posted:

Frederick Gotham wrote:

Correction: -32 768 through 32 767

Incorrect. The minimum range of an "int" is:

-32767 through 32767

It may so happen that on a system where int's are 32-Bit and are two's
complement, that the range is -32768 through 32767, but this cannot be
relied upon in portable code.

For unsigned: 0 through 65 535


That's 65 536 values.

Yes, you're correct.