No return in LONG InterlockedDecrement ( LONG *lpAddend )

S

slackcode

I use MiniMFC in Linux. And found the function InterlockedDecrement
don't has the "return xxx":
LONG InterlockedDecrement ( LONG *lpAddend )
{
*lpAddend = *lpAddend - 1;
}

I write a test program like this function, and it return the value of
*lpAddend without the return sentence in the end of the function.
Maybe It return EAX by default, but I'm not sure about that.

CString of MiniMFC use this function like:
void CString::Release()
{
if (GetData() != _afxDataNil)
{
ASSERT(GetData()->nRefs != 0);
if (InterlockedDecrement(&GetData()->nRefs) <= 0)
FreeData(GetData());
Init();
}
}

So the return value of InterlockedDecrement is very important. And I
am not sure the return value and the CString::Release() will occur
some mistagke
 
S

slackcode

Sorry!

So the return value of InterlockedDecrement is very important. And I
am not sure the return value and the CString::Release() will occur
some mistake. Could some one can explain that? Thank you very much!

regards,
slackcode
 
F

Flash Gordon

slackcode wrote, On 27/08/08 06:22:
I use MiniMFC in Linux. And found the function InterlockedDecrement
don't has the "return xxx":
LONG InterlockedDecrement ( LONG *lpAddend )
{
*lpAddend = *lpAddend - 1;
}

I write a test program like this function, and it return the value of
*lpAddend without the return sentence in the end of the function.
Maybe It return EAX by default, but I'm not sure about that.

It happened to be somewhere that allowed you to pick it up by chance.
Change something apparently unrelated and that could change. Either make
the function return an appropriate or change the return type of the
function to void. Also see if you can turn up the warning level on your
compiler, some can warn about problems like this.
CString of MiniMFC use this function like:
void CString::Release()

<snip>

C++ and C are different languages with separate groups. Since
comp.lang.c++ is next to comp.lang.c in most newsgroup lists I find it
hard to understand how people miss the group and end up posting C++ here.
 
N

Nick Keighley

I use MiniMFC in Linux. And found the function InterlockedDecrement
don't has the "return xxx":
LONG InterlockedDecrement ( LONG *lpAddend )
{
        *lpAddend = *lpAddend - 1;

}

that is an error. Or more formally "Undefined Behaviour".
The implementation can do whatever it likes.

I write a test program like this function, and it return the value of
*lpAddend  without the return sentence in the end of the function.

such as that
Maybe It return EAX by default, but I'm not sure about that.

CString of MiniMFC use this function like:
void CString::Release()
{
        if (GetData() != _afxDataNil)
        {
                ASSERT(GetData()->nRefs != 0);
                if (InterlockedDecrement(&GetData()->nRefs) <= 0)
                        FreeData(GetData());
                Init();
        }
}

So the return value of InterlockedDecrement is very important. And I
am not sure the return value and the  CString::Release() will occur
some [mistake. can someone explain this?]

you have Undefined Behaviour

--
Nick Keighley

Programming should never be boring, because anything
mundane and repetitive should be done by the computer.
~Alan Turing
 
I

Ian Collins

Nick said:
that is an error. Or more formally "Undefined Behaviour".
The implementation can do whatever it likes.
Which really should be a constraint violation.
 
R

Richard Bos

Ian Collins said:
Which really should be a constraint violation.

It can't be; it is possible (with thanks to Gödel and related theorems)
to write a function in which all paths terminate in a return statement,
but the implementation isn't able to prove that.

Richard
 
J

James Kuyper

Richard said:
It can't be; it is possible (with thanks to Gödel and related theorems)
to write a function in which all paths terminate in a return statement,
but the implementation isn't able to prove that.

The standard could make it a constraint violation to leave out return
statements in certain locations, even if the programmer can figure out
that they will never be executed. If "certain locations" is specified
appropriately (which I will not attempt to do), then checking whether
this has been done would become feasible in all cases.

I don't think that this would be popular. Compilers which currently
perform a sufficiently sophisticated check for unreachable code might,
as a QoI issue, have to turn off the corresponding warning in cases
where leaving out the unreachable code would be a constraint violation
under the new rule.
 
W

Willem

Ian Collins wrote:
) Nick Keighley wrote:
)>
)>> I use MiniMFC in Linux. And found the function InterlockedDecrement
)>> don't has the "return xxx":
)>> LONG InterlockedDecrement ( LONG *lpAddend )
)>> {
)>> *lpAddend = *lpAddend - 1;
)>>
)>> }
)>
)> that is an error. Or more formally "Undefined Behaviour".
)> The implementation can do whatever it likes.
)>
) Which really should be a constraint violation.

constraint violations are usually restricted to things that can be easily
checked by a compiler. Ensuring that a non-void function always returns a
value requires code path analysis at the very least.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
A

Andrew Poelstra

It can't be; it is possible (with thanks to Gödel and related theorems)
to write a function in which all paths terminate in a return statement,
but the implementation isn't able to prove that.

Indeed. C# requires superfluous return statements, and it is a source
of great frustration, since the programmer needs to add a comment saying
that he's being program-illogical to appease the compiler.
 
I

Ian Collins

Willem said:
Ian Collins wrote:
) Nick Keighley wrote:
)>
)>> I use MiniMFC in Linux. And found the function InterlockedDecrement
)>> don't has the "return xxx":
)>> LONG InterlockedDecrement ( LONG *lpAddend )
)>> {
)>> *lpAddend = *lpAddend - 1;
)>>
)>> }
)>
)> that is an error. Or more formally "Undefined Behaviour".
)> The implementation can do whatever it likes.
)>
) Which really should be a constraint violation.

constraint violations are usually restricted to things that can be easily
checked by a compiler. Ensuring that a non-void function always returns a
value requires code path analysis at the very least.
Ensuring a non-void function has at least one return statement isn't hard.
 
H

Harald van Dijk

[ non-void functions exiting by reaching the } ]
Ensuring a non-void function has at least one return statement isn't
hard.

And what if a non-void function intentionally has no return statement,
because it's not supposed to ever return? For example, int main(void)
which starts up an otherwise infinite loop containing a conditional call
to exit()?
 
S

slackcode

C++ and C are different languages with separate groups. Since
comp.lang.c++ is next to comp.lang.c in most newsgroup lists I find it
hard to understand how people miss the group and end up posting C++ here.

Sorry, I just think InterlockedDecrement is C, so I post it here. thx
 
S

slackcode

Ian Collins wrote:
) Nick Keighley wrote:

)>
)>> I use MiniMFC in Linux. And found the function InterlockedDecrement
)>> don't has the "return xxx":
)>> LONG InterlockedDecrement ( LONG *lpAddend )
)>> {
)>> *lpAddend = *lpAddend - 1;
)>>
)>> }
)>
)> that is an error. Or more formally "Undefined Behaviour".
)> The implementation can do whatever it likes.
)>
) Which really should be a constraint violation.

constraint violations are usually restricted to things that can be easily
checked by a compiler. Ensuring that a non-void function always returns a
value requires code path analysis at the very least.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Actually, MiniMFC runs very well for years.
But I found gcc 'warning' in this function these days.
And I found that It returns *lpAddend, and the parament is *lpAddend.
 
S

slackcode

Ensuring a non-void function has at least one return statement isn't hard..

But I don't dare to modify this function because of it runs steadily.
And we use CString so many.
 
S

slackcode

that is an error. Or more formally "Undefined Behaviour".
The implementation can do whatever it likes.

This function and it's execution are undefined in C90, but not in C99.
such as that

It is in the line above, where the caller uses the value that the
function failed to return, that undefined behavior occurs in C99. And
of course, any other place where callers of the function happen to use
the value.
FreeData(GetData());
Init();
}
}
So the return value of InterlockedDecrement is very important. And I
am not sure the return value and the CString::Release() will occur
some [mistake. can someone explain this?]
you have Undefined Behaviour

Yes, under any version of the C standard, since the value is used.

--
Jack Klein
Home:http://JK-Technology.Com
FAQs for
comp.lang.chttp://c-faq.com/
comp.lang.c++http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Thank you for all of you warm words.
And How could I fix the problem?
 
I

Ian Collins

slackcode said:
But I don't dare to modify this function because of it runs steadily.

Until something in the compiler changes the behaviour of that particular
bit of undefined behaviour.
 
D

David Thompson

This function and it's execution are undefined in C90, but not in C99.
It is in the line above, where the caller uses the value that the
function failed to return, that undefined behavior occurs in C99. And
of course, any other place where callers of the function happen to use
the value.
No, in C90 also it is (or was) UB only if the value is used. It's just
described in a different place: 6.6.6.4 return statement rather than
6.9.1p12 function definition. Two things that did change are:

- in C99 it is a constraint violation to have an explicit return
/*novalue*/; statement in a valued function (so that method of
returning indeterminate is gone, but fall-off-end is still there)

- in C99 fall-off-end of (initial call of) main() returns status 0
(success) rather than undefined

- formerly david.thompson1 || achar(64) || worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top