No return in LONG InterlockedDecrement ( LONG *lpAddend )

Discussion in 'C Programming' started by slackcode, Aug 27, 2008.

  1. slackcode

    slackcode Guest

    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
    slackcode, Aug 27, 2008
    #1
    1. Advertising

  2. slackcode

    slackcode Guest

    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
    slackcode, Aug 27, 2008
    #2
    1. Advertising

  3. slackcode

    Flash Gordon Guest

    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.
    --
    Flash Gordon
    Flash Gordon, Aug 27, 2008
    #3
  4. On 27 Aug, 06:22, slackcode <> 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.


    > 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
    Nick Keighley, Aug 27, 2008
    #4
  5. slackcode

    Ian Collins Guest

    Nick Keighley wrote:
    > On 27 Aug, 06:22, slackcode <> 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.

    --
    Ian Collins.
    Ian Collins, Aug 27, 2008
    #5
  6. slackcode

    Richard Bos Guest

    Ian Collins <> wrote:

    > Nick Keighley wrote:
    > > On 27 Aug, 06:22, slackcode <> 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.


    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
    Richard Bos, Aug 27, 2008
    #6
  7. slackcode

    James Kuyper Guest

    Richard Bos wrote:
    > Ian Collins <> wrote:
    >
    >> Nick Keighley wrote:
    >>> On 27 Aug, 06:22, slackcode <> 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.

    >
    > 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.
    James Kuyper, Aug 27, 2008
    #7
  8. slackcode

    Willem Guest

    Ian Collins wrote:
    ) Nick Keighley wrote:
    )> On 27 Aug, 06:22, slackcode <> 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
    Willem, Aug 27, 2008
    #8
  9. On 2008-08-27, Richard Bos <> wrote:
    > Ian Collins <> wrote:
    >
    >> Nick Keighley wrote:
    >> > On 27 Aug, 06:22, slackcode <> 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.

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

    --
    Andrew Poelstra
    To email me, use the above email addresss with .com set to .net
    Andrew Poelstra, Aug 27, 2008
    #9
  10. slackcode

    Ian Collins Guest

    Willem wrote:
    > Ian Collins wrote:
    > ) Nick Keighley wrote:
    > )> On 27 Aug, 06:22, slackcode <> 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.
    Ian Collins, Aug 27, 2008
    #10
  11. 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()?
    Harald van Dijk, Aug 27, 2008
    #11
  12. slackcode

    slackcode Guest

    > 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
    slackcode, Aug 29, 2008
    #12
  13. slackcode

    slackcode Guest

    On 8ÔÂ27ÈÕ, ÏÂÎç7ʱ48·Ö, Willem <> wrote:
    > Ian Collins wrote:
    > ) Nick Keighley wrote:
    >
    > )> On 27 Aug, 06:22, slackcode <> 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.
    slackcode, Aug 29, 2008
    #13
  14. slackcode

    slackcode Guest

    On 8ÔÂ28ÈÕ, ÉÏÎç3ʱ09·Ö, Ian Collins <> wrote:
    > Willem wrote:
    > > Ian Collins wrote:
    > > ) Nick Keighley wrote:
    > > )> On 27 Aug, 06:22, slackcode <> 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.
    slackcode, Aug 29, 2008
    #14
  15. slackcode

    slackcode Guest

    On 8ÔÂ28ÈÕ, ÉÏÎç10ʱ15·Ö, Jack Klein <> wrote:
    > On Wed, 27 Aug 2008 01:02:11 -0700 (PDT), Nick Keighley
    > <> wrote in comp.lang.c:
    >
    > > On 27 Aug, 06:22, slackcode <> 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?
    slackcode, Aug 29, 2008
    #15
  16. slackcode

    Ian Collins Guest

    slackcode wrote:
    > On 8ÔÂ28ÈÕ, ÉÏÎç3ʱ09·Ö, Ian Collins <> wrote:
    >> Willem wrote:
    >>> Ian Collins wrote:
    >>> ) Nick Keighley wrote:
    >>> )> On 27 Aug, 06:22, slackcode <> 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.
    Ian Collins, Aug 29, 2008
    #16
  17. On Wed, 27 Aug 2008 21:15:29 -0500, Jack Klein <>
    wrote:

    > On Wed, 27 Aug 2008 01:02:11 -0700 (PDT), Nick Keighley
    > <> wrote in comp.lang.c:
    >
    > > On 27 Aug, 06:22, slackcode <> 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
    David Thompson, Sep 7, 2008
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    672
    Eric Sosman
    Jul 8, 2003
  2. Greenhorn
    Replies:
    15
    Views:
    811
    Keith Thompson
    Mar 6, 2005
  3. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,184
    Peter Shaggy Haywood
    Sep 20, 2005
  4. Mathieu Dutour

    long long and long

    Mathieu Dutour, Jul 17, 2007, in forum: C Programming
    Replies:
    4
    Views:
    471
    santosh
    Jul 24, 2007
  5. Bart C

    Use of Long and Long Long

    Bart C, Jan 9, 2008, in forum: C Programming
    Replies:
    27
    Views:
    796
    Peter Nilsson
    Jan 15, 2008
Loading...

Share This Page