Use our own openmode_t datatype

[fmartian]

Description

Under Linux, std::ios_base::openmode is defined as an enum, which makes handling flags, which this parameter really represents, rather cumbersome. So we use our own datatype which is simply an integer.

[Ansariel]

Why not overload the bitwise-or operator instead of reinventing the wheel by re-defining an enum as integers?

[fmartian]

Why not overload the bitwise-or operator instead of reinventing the wheel by re-defining an enum as integers?

A nice idea in theory. In practice the Linux STL headers already do that and it is still a mess.

  _GLIBCXX_NODISCARD _GLIBCXX_CONSTEXPR
  inline _Ios_Openmode
  operator&(_Ios_Openmode __a, _Ios_Openmode __b) _GLIBCXX_NOTHROW
  { return _Ios_Openmode(static_cast<int>(__a) & static_cast<int>(__b)); }

  _GLIBCXX_NODISCARD _GLIBCXX_CONSTEXPR
  inline _Ios_Openmode
  operator|(_Ios_Openmode __a, _Ios_Openmode __b) _GLIBCXX_NOTHROW
  { return _Ios_Openmode(static_cast<int>(__a) | static_cast<int>(__b)); }

.....

The whole idea of trying to force an enum into submission though static_casts all over to place to allow it to represent a flag collection is IMHO misguided but at least under Linux by now a historical fact that won't be possible to get fixed ever.

[akleshchev]

 WARNING # llxml/llcontrol.h(238) LLControlGroup::get : Control TestSetting not found.
[control_group, 2] fail: 'value of changed setting: expected '13' actual '0''

I haven't digged in yet, but my assumption is that there is a problem with reading/writing.

[fmartian]

 WARNING # llxml/llcontrol.h(238) LLControlGroup::get : Control TestSetting not found.
[control_group, 2] fail: 'value of changed setting: expected '13' actual '0''

I haven't digged in yet, but my assumption is that there is a problem with reading/writing.

Just before this happens:

WARNING #LLFile# llcommon/llfile.cpp(268) warnif : Couldn't mkdir '/tmpllcontrol-test-08dcffe6-6c1e-7f69-b039-49ff7cf255a3/' (errno 13): Permission denied
WARNING #Settings# llxml/llcontrol.cpp(1000) LLControlGroup::loadFromFile : Cannot find file /tmpllcontrol-test-08dcffe6-6c1e-7f69-b039-49ff7cf255a3/settings.xml

So it seems that the directory can't be created and then the settings file inside neither. However not sure you can just create a directory in the root. Looks at least weird to me. I would rather guess that this path should be: '/tmp/llcontrol-test-08dcffe6-6c1e-7f69-b039-49ff7cf255a3/' instead. The slash after tmp somehow got lost.

I think I know how:
LLFile::tmpdir() did in the past explicitly add a path seperator if it was not already present:

        if (utf8path[utf8path.size() - 1] != sep)
        {
            utf8path += sep;
        }

That got lost!

The code here then causes problems.

In llxml/tests/llcontrol_test.cpp (line 54)
mTestConfigDir = STRINGIZE(LLFile::tmpdir() << "llcontrol-test-" << random << "/");

Seems that LLFile::tmpdir() is elsewhere only used with LLDir::append() to append paths when combining it with other path elements. Will need to check, but I think it would be best to use LLDir::append() in the llcontrol_test AND also add the explicit backslash to the end of LLFile::tmpdir()

[akleshchev]

            mTestConfigDir = STRINGIZE(LLFile::tmpdir() << "llcontrol-test-" << random << "/");
            mTestConfigFile = mTestConfigDir + "settings.xml";
            LLFile::mkdir(mTestConfigDir);

Old tmpdir explicitly adds a slash at the end, new one doesn't.

[fmartian]

            mTestConfigDir = STRINGIZE(LLFile::tmpdir() << "llcontrol-test-" << random << "/");
            mTestConfigFile = mTestConfigDir + "settings.xml";
            LLFile::mkdir(mTestConfigDir);

Old tmpdir explicitly adds a slash at the end, new one doesn't.

Strictly speaking is LLFile::tmpdir() a bit misplaced as it is logically more an LLDir:: thing.

[akleshchev]

Agree, either way trying a build with an added separator.

[akleshchev]

My branch builds now on linux, but there is an odd problem with mac builds (out of disk memory?).

[fmartian]

My branch builds now on linux, but there is an odd problem with mac builds (out of disk memory?).

I got something similar too, but it seems to have something to do with a "Secondlife Test" subproject that it tries to build even if I disable LL_TESTS in autobuild.

[akleshchev]

"Secondlife Test"

That's channel, not tests. The default way to build viewer on GH out of release and project branches.

[akleshchev]

Rebase it on top of current andreyk/apr_cleanup please.