c++.windows.32-bits - Problem with RegOpenKeyEx() only experienced by DMC++

Matthew (38/38) Feb 13 2004 I'm writing a test program - which is used with Borland 5.6.4, CodeWarri...

Matthew (29/67) Feb 13 2004 Amazingly, several hours of debugging later, this is actually DMC++'s

Walter (9/92) Feb 13 2004 That came about because of a bug fix where temporaries are supposed to b...

Matthew (7/110) Feb 13 2004 Do you mean the standard behaviour, or DMC++'s behaviour?

Walter (8/121) Feb 13 2004 That's supposed to be standard behavior.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

I'm writing a test program - which is used with Borland 5.6.4, CodeWarrior
8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC
2.06 - that uses the WinSTL reg_key_sequence class. It works correctly for
all compilers except DMC++.

For DMC++, the function reg_traits<> function key_dup() fails. It is defined
as:

    static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
KEY_ALL_ACCESS)
    {
        hkey_type   hkeyDup;
        ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
&hkeyDup);

        if(res != ERROR_SUCCESS)
        {
            hkeyDup = NULL;
        }

        return hkeyDup;
    }

    (hkey_type is HKEY)

(FYI, this technique is described in
http://www.windevnet.com/documents/win0304f/)

For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
GetLastError return 6 (ERROR_INVALID_HANDLE).

After much jiggery pokery, I have got a work around for DMC++ that simply
calls RegOpenKey(). However, this then loses the ability to specify
different access rights.

Clearly, this must be a bug in DMC++'s code generation, since all exes,
irrespective of compiler, use the same system library ADVAPI32.LIB.

Cheers


-- 
Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

-----------------------------------------------------

Feb 13 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Amazingly, several hours of debugging later, this is actually DMC++'s
failure to properly deal with holding temporaries around when a const
reference is placed on them.

The code looks like

    void iterate_recurse(reg_key_sequence::const_iterator from,
reg_key_sequence::const_iterator to, int &found, int &total)
    {
        for(; from != to; ++from)
        {
            const reg_key       &key = *from;
// The temporary '*from' is destroyed HERE!
            reg_key_sequence    keys(key);

            ++total;
            if(key.name() == "Settings")
            {
                ++found;
            }
            iterate_recurse(keys.begin(), keys.end(), found, total);

// But it should be destroyed HERE!
        }
    }

I can't remember which bit of the standard this is in, but I know for a fact
it is standard C++.

The fix for the moment is to change key from a reference to a value. But
this should be fixed asap, as I know several libs, e.g. loki, use it, and I
use it in client code from time to time


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c0jjmr$fci$1 digitaldaemon.com...
 I'm writing a test program - which is used with Borland 5.6.4, CodeWarrior
 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC
 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly for
 all compilers except DMC++.

 For DMC++, the function reg_traits<> function key_dup() fails. It is

defined
 as:

     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
 KEY_ALL_ACCESS)
     {
         hkey_type   hkeyDup;
         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
 &hkeyDup);

         if(res != ERROR_SUCCESS)
         {
             hkeyDup = NULL;
         }

         return hkeyDup;
     }

     (hkey_type is HKEY)

 (FYI, this technique is described in
 http://www.windevnet.com/documents/win0304f/)

 For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
 GetLastError return 6 (ERROR_INVALID_HANDLE).

 After much jiggery pokery, I have got a work around for DMC++ that simply
 calls RegOpenKey(). However, this then loses the ability to specify
 different access rights.

 Clearly, this must be a bug in DMC++'s code generation, since all exes,
 irrespective of compiler, use the same system library ADVAPI32.LIB.

 Cheers


 -- 
 Matthew Wilson

 Director, Synesis Software
     (www.synesis.com.au)
 STLSoft moderator
     (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
     (www.synesis.com.au/articles.html#columns)

 -----------------------------------------------------

Feb 13 2004

"Walter" <walter digitalmars.com> writes:

That came about because of a bug fix where temporaries are supposed to be
destructed at the next sequence point.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c0jps3$og6$1 digitaldaemon.com...
 Amazingly, several hours of debugging later, this is actually DMC++'s
 failure to properly deal with holding temporaries around when a const
 reference is placed on them.

 The code looks like

     void iterate_recurse(reg_key_sequence::const_iterator from,
 reg_key_sequence::const_iterator to, int &found, int &total)
     {
         for(; from != to; ++from)
         {
             const reg_key       &key = *from;
 // The temporary '*from' is destroyed HERE!
             reg_key_sequence    keys(key);

             ++total;
             if(key.name() == "Settings")
             {
                 ++found;
             }
             iterate_recurse(keys.begin(), keys.end(), found, total);

 // But it should be destroyed HERE!
         }
     }

 I can't remember which bit of the standard this is in, but I know for a

fact
 it is standard C++.

 The fix for the moment is to change key from a reference to a value. But
 this should be fixed asap, as I know several libs, e.g. loki, use it, and

I
 use it in client code from time to time


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c0jjmr$fci$1 digitaldaemon.com...
 I'm writing a test program - which is used with Borland 5.6.4,


CodeWarrior
 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC
 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly


for
 all compilers except DMC++.

 For DMC++, the function reg_traits<> function key_dup() fails. It is

 defined
 as:

     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
 KEY_ALL_ACCESS)
     {
         hkey_type   hkeyDup;
         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
 &hkeyDup);

         if(res != ERROR_SUCCESS)
         {
             hkeyDup = NULL;
         }

         return hkeyDup;
     }

     (hkey_type is HKEY)

 (FYI, this technique is described in
 http://www.windevnet.com/documents/win0304f/)

 For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
 GetLastError return 6 (ERROR_INVALID_HANDLE).

 After much jiggery pokery, I have got a work around for DMC++ that


simply
 calls RegOpenKey(). However, this then loses the ability to specify
 different access rights.

 Clearly, this must be a bug in DMC++'s code generation, since all exes,
 irrespective of compiler, use the same system library ADVAPI32.LIB.

 Cheers


 --
 Matthew Wilson

 Director, Synesis Software
     (www.synesis.com.au)
 STLSoft moderator
     (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
     (www.synesis.com.au/articles.html#columns)

 -----------------------------------------------------

Feb 13 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Do you mean the standard behaviour, or DMC++'s behaviour?

Is it going to be fixed for 8.39? Pretty please. :)


"Walter" <walter digitalmars.com> wrote in message
news:c0ju27$uhj$1 digitaldaemon.com...
 That came about because of a bug fix where temporaries are supposed to be
 destructed at the next sequence point.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c0jps3$og6$1 digitaldaemon.com...
 Amazingly, several hours of debugging later, this is actually DMC++'s
 failure to properly deal with holding temporaries around when a const
 reference is placed on them.

 The code looks like

     void iterate_recurse(reg_key_sequence::const_iterator from,
 reg_key_sequence::const_iterator to, int &found, int &total)
     {
         for(; from != to; ++from)
         {
             const reg_key       &key = *from;
 // The temporary '*from' is destroyed HERE!
             reg_key_sequence    keys(key);

             ++total;
             if(key.name() == "Settings")
             {
                 ++found;
             }
             iterate_recurse(keys.begin(), keys.end(), found, total);

 // But it should be destroyed HERE!
         }
     }

 I can't remember which bit of the standard this is in, but I know for a

 fact
 it is standard C++.

 The fix for the moment is to change key from a reference to a value. But
 this should be fixed asap, as I know several libs, e.g. loki, use it,


and
 I
 use it in client code from time to time


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c0jjmr$fci$1 digitaldaemon.com...
 I'm writing a test program - which is used with Borland 5.6.4,


 CodeWarrior
 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC
 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly


 for
 all compilers except DMC++.

 For DMC++, the function reg_traits<> function key_dup() fails. It is

 defined
 as:

     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
 KEY_ALL_ACCESS)
     {
         hkey_type   hkeyDup;
         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
 &hkeyDup);

         if(res != ERROR_SUCCESS)
         {
             hkeyDup = NULL;
         }

         return hkeyDup;
     }

     (hkey_type is HKEY)

 (FYI, this technique is described in
 http://www.windevnet.com/documents/win0304f/)

 For some reason, with DMC++ only, the call to RegOpenKeyExA() fails,



and
 GetLastError return 6 (ERROR_INVALID_HANDLE).

 After much jiggery pokery, I have got a work around for DMC++ that


 simply
 calls RegOpenKey(). However, this then loses the ability to specify
 different access rights.

 Clearly, this must be a bug in DMC++'s code generation, since all



exes,
 irrespective of compiler, use the same system library ADVAPI32.LIB.

 Cheers


 --
 Matthew Wilson

 Director, Synesis Software
     (www.synesis.com.au)
 STLSoft moderator
     (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
     (www.synesis.com.au/articles.html#columns)

 -----------------------------------------------------

Feb 13 2004

"Walter" <walter digitalmars.com> writes:

That's supposed to be standard behavior.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c0ka8e$1i7d$1 digitaldaemon.com...
 Do you mean the standard behaviour, or DMC++'s behaviour?

 Is it going to be fixed for 8.39? Pretty please. :)


 "Walter" <walter digitalmars.com> wrote in message
 news:c0ju27$uhj$1 digitaldaemon.com...
 That came about because of a bug fix where temporaries are supposed to


be
 destructed at the next sequence point.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c0jps3$og6$1 digitaldaemon.com...
 Amazingly, several hours of debugging later, this is actually DMC++'s
 failure to properly deal with holding temporaries around when a const
 reference is placed on them.

 The code looks like

     void iterate_recurse(reg_key_sequence::const_iterator from,
 reg_key_sequence::const_iterator to, int &found, int &total)
     {
         for(; from != to; ++from)
         {
             const reg_key       &key = *from;
 // The temporary '*from' is destroyed HERE!
             reg_key_sequence    keys(key);

             ++total;
             if(key.name() == "Settings")
             {
                 ++found;
             }
             iterate_recurse(keys.begin(), keys.end(), found, total);

 // But it should be destroyed HERE!
         }
     }

 I can't remember which bit of the standard this is in, but I know for



a
 fact
 it is standard C++.

 The fix for the moment is to change key from a reference to a value.



But
 this should be fixed asap, as I know several libs, e.g. loki, use it,


 and
 I
 use it in client code from time to time


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c0jjmr$fci$1 digitaldaemon.com...
 I'm writing a test program - which is used with Borland 5.6.4,


 CodeWarrior
 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1,




VectorC
 2.06 - that uses the WinSTL reg_key_sequence class. It works




correctly
 for
 all compilers except DMC++.

 For DMC++, the function reg_traits<> function key_dup() fails. It is

 defined
 as:

     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
 KEY_ALL_ACCESS)
     {
         hkey_type   hkeyDup;
         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
 &hkeyDup);

         if(res != ERROR_SUCCESS)
         {
             hkeyDup = NULL;
         }

         return hkeyDup;
     }

     (hkey_type is HKEY)

 (FYI, this technique is described in
 http://www.windevnet.com/documents/win0304f/)

 For some reason, with DMC++ only, the call to RegOpenKeyExA() fails,



 and
 GetLastError return 6 (ERROR_INVALID_HANDLE).

 After much jiggery pokery, I have got a work around for DMC++ that


 simply
 calls RegOpenKey(). However, this then loses the ability to specify
 different access rights.

 Clearly, this must be a bug in DMC++'s code generation, since all



 exes,
 irrespective of compiler, use the same system library ADVAPI32.LIB.

 Cheers


 --
 Matthew Wilson

 Director, Synesis Software
     (www.synesis.com.au)
 STLSoft moderator
     (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
     (www.synesis.com.au/articles.html#columns)

 -----------------------------------------------------

Feb 13 2004

D Programming

C/C++ Programming

Other

c++.windows.32-bits - Problem with RegOpenKeyEx() only experienced by DMC++