Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > No return in LONG InterlockedDecrement ( LONG *lpAddend )

Reply
Thread Tools

No return in LONG InterlockedDecrement ( LONG *lpAddend )

 
 
Harald van D某k
Guest
Posts: n/a
 
      08-27-2008
On Thu, 28 Aug 2008 07:09:32 +1200, Ian Collins wrote:
> Willem wrote:
>> Ian Collins wrote:


[ non-void functions exiting by reaching the } ]

>> ) 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.


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()?
 
Reply With Quote
 
 
 
 
slackcode
Guest
Posts: n/a
 
      08-29-2008
> 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
 
Reply With Quote
 
 
 
 
slackcode
Guest
Posts: n/a
 
      08-29-2008
On 8月27日, 下午7时48分, Willem <(E-Mail Removed)> wrote:
> Ian Collins wrote:
> ) Nick Keighley wrote:
>
> )> On 27 Aug, 06:22, slackcode <(E-Mail Removed)> 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.
 
Reply With Quote
 
slackcode
Guest
Posts: n/a
 
      08-29-2008
On 8月28日, 上午3时09分, Ian Collins <(E-Mail Removed)> wrote:
> Willem wrote:
> > Ian Collins wrote:
> > ) Nick Keighley wrote:
> > )> On 27 Aug, 06:22, slackcode <(E-Mail Removed)> 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..
>
> --
> Ian Collins.- 隐藏被引用文字 -
>
> - 显示引用的文字 -


But I don't dare to modify this function because of it runs steadily.
And we use CString so many.
 
Reply With Quote
 
slackcode
Guest
Posts: n/a
 
      08-29-2008
On 8月28日, 上午10时15分, Jack Klein <(E-Mail Removed)> wrote:
> On Wed, 27 Aug 2008 01:02:11 -0700 (PDT), Nick Keighley
> <(E-Mail Removed)> wrote in comp.lang.c:
>
> > On 27 Aug, 06:22, slackcode <(E-Mail Removed)> 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.

>
> This function and it's execution are undefined in C90, but not in C99.
>
> > > 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)

>
> 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?
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-29-2008
slackcode wrote:
> On 8月28日, 上午3时09分, Ian Collins <(E-Mail Removed)> wrote:
>> Willem wrote:
>>> Ian Collins wrote:
>>> ) Nick Keighley wrote:
>>> )> On 27 Aug, 06:22, slackcode <(E-Mail Removed)> 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..
>>

>
> 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.

--
Ian Collins.
 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      09-07-2008
On Wed, 27 Aug 2008 21:15:29 -0500, Jack Klein <(E-Mail Removed)>
wrote:

> On Wed, 27 Aug 2008 01:02:11 -0700 (PDT), Nick Keighley
> <(E-Mail Removed)> wrote in comp.lang.c:
>
> > On 27 Aug, 06:22, slackcode <(E-Mail Removed)> wrote:

<snip: valued function that 'falls off end'>
> > 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.
>

<snip: call that uses value>
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
long long and long Mathieu Dutour C Programming 4 07-24-2007 11:15 AM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments