User forums > Nightly builds

The 02 November 2012 build (8500) is out.

<< < (3/8) > >>

ollydbg:

--- Quote from: oBFusCATed on November 04, 2012, 10:37:20 am ---This line is a bit strange:

--- Code: ---     char buffer[stl_putenv_var.length()+1];

--- End code ---
because this is not a valid c++, but probably uses some language extension of gcc.

--- End quote ---
Maybe, morten can say something about this.


--- Quote ---About the issue: have you looked at the code of wxsetenv? What does it do?
--- End quote ---
see below:

--- Code: ---bool wxSetEnv(const wxString& WXUNUSED_IN_WINCE(var),
              const wxChar *WXUNUSED_IN_WINCE(value))
{
    // some compilers have putenv() or _putenv() or _wputenv() but it's better
    // to always use Win32 function directly instead of dealing with them
#ifdef __WXWINCE__
    // no environment variables under CE
    return false;
#else
    if ( !::SetEnvironmentVariable(var, value) )
    {
        wxLogLastError(_T("SetEnvironmentVariable"));

        return false;
    }

    return true;
#endif
}

--- End code ---

I can not see any reason why SetEnvironmentVariable failed.

--- Quote ---Have this problem been reported to wx devs?
--- End quote ---
I will report it if I have time.


--- Quote ---They think it is fixed: http://trac.wxwidgets.org/ticket/1413

--- End quote ---
It said:

--- Quote --- Changed 4 years ago by neis
Fixed by revision 42471, which should have ensured that it's correct in 2.8.0 and later.

--- End quote ---
But it appears that the bug is still here in wx2.8.12.


Edit:
See here: http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__env.html


--- Quote ---bool wxSetEnv    (    const wxString &     var,
      const wxString &     value
   )       

Sets the value of the environment variable var (adding it if necessary) to value.

Notice that under Windows platforms the program may have two different environment blocks: the first one is that of a Windows process and is always present, but the CRT may maintain its own independent copy of the environment. wxSetEnv() will always update the first copy, which means that wxGetEnv(), which uses it directly, will always return the expected value after this call. But wxSetEnv() only updates the second copy for some compilers/CRT implementations (currently only MSVC and MinGW which uses the same MSVC CRT) and so using wxGetenv() (notice the difference in case) may not return the updated value.

Parameters
    var   The environment variable to be set, must not contain '=' character.
    value   New value of the variable.

Returns
    true on success or false if changing the value failed.

See Also
    wxUnsetEnv()

Include file:

#include <wx/utils.h>



--- End quote ---
But I do not quite understand this description.

MortenMacFly:

--- Quote from: ollydbg on November 04, 2012, 11:55:16 am ---
--- Quote from: oBFusCATed on November 04, 2012, 10:37:20 am ---This line is a bit strange:

--- Code: ---char buffer[stl_putenv_var.length()+1];
--- End code ---
because this is not a valid c++, but probably uses some language extension of gcc.

--- End quote ---
Maybe, morten can say something about this.

--- End quote ---
Nope I can't other than it compiles and works just fine w/o specific extension (and why is it no C++, btw?!):
http://www.cplusplus.com/reference/string/string/length/
Its that same as char buffer[64]; or alike...

oBFusCATed:

--- Quote from: MortenMacFly on November 04, 2012, 05:11:45 pm ---Its that same as char buffer[64]; or alike...

--- End quote ---
No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?

p2rkw:
Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
'64' is compile time constant, string::length is run time constant. 'const' qualifier only allow to call length() on const object.

MortenMacFly:

--- Quote from: oBFusCATed on November 04, 2012, 05:14:53 pm ---No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?

--- End quote ---
No, why should I?


--- Quote from: p2rkw on November 04, 2012, 05:24:02 pm ---Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

--- End quote ---
So - according this its OK. And yes, of course I know its a variable and not a constant. I thought oBFusCATed meant the length() method not being standard and I wanted to point put that it returns a const size_t.

BTW: I think we are getting off-topic ...

Navigation

[0] Message Index

[#] Next page

[*] Previous page