From ratkaisut at gmail.com  Tue Apr  8 06:19:25 2025
From: ratkaisut at gmail.com (Sten Kultakangas)
Date: Mon Apr 14 06:20:16 2025
Subject: [odb-users] reading value from default-constructed odb::nullable<T>
 causes undefined behaviour
Message-ID: <CA+jNci5R_pqTDfURhhhVWLuEefqg=uhi1CnpTVrRuvuL921_7g@mail.gmail.com>

Hello

I noticed random crashes of our application at the following line of code:
call->station_ext = seg.rdnis.get();

The type of rdnis is odb::nullable<std::string>

Apparently, the functionality of odb::nullable<T> (where T is non-trivially
constructible) has changed since commit 3795f78 ("Improve odb::nullable for
C++11 and later") for the cases when the ODB_CXX11 macro is enabled.

Since I don't know when the ODB_CXX11 macro was enabled by default, I am
not sure whether this change affected the production code that uses version
v2.5.0-b.27 or a later version. Could somebody confirm whether this
affected all the versions from v2.5.0-b.27 onwards?

Since calling get() of std::nullable<T> is a bad practice without checking
for the value returned by the null() member function first, I suggest
either throwing an exception or returning a default value of T, because
undefined behaviour is hard to track.

Best regards,
Sten Kultakangas
From boris at codesynthesis.com  Mon Apr 14 08:43:47 2025
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Apr 14 08:42:14 2025
Subject: [odb-users] reading value from default-constructed
	odb::nullable<T> causes undefined behaviour
In-Reply-To: <CA+jNci5R_pqTDfURhhhVWLuEefqg=uhi1CnpTVrRuvuL921_7g@mail.gmail.com>
References: <CA+jNci5R_pqTDfURhhhVWLuEefqg=uhi1CnpTVrRuvuL921_7g@mail.gmail.com>
Message-ID: <boris.20250414143804@codesynthesis.com>

Sten Kultakangas <ratkaisut@gmail.com> writes:

> Apparently, the functionality of odb::nullable<T> (where T is non-trivially
> constructible) has changed since commit 3795f78 ("Improve odb::nullable for
> C++11 and later") for the cases when the ODB_CXX11 macro is enabled.

Specifically, in C++11 it can be used with types that are not default-
constructible


> Since I don't know when the ODB_CXX11 macro was enabled by default, I am
> not sure whether this change affected the production code that uses version
> v2.5.0-b.27 or a later version. Could somebody confirm whether this
> affected all the versions from v2.5.0-b.27 onwards?

The ODB_CXX11 macro is defined when your C++ compiler is in the C++11 mode
or later, which, these days, is the case with the recent versions of all
the major compilers.


> Since calling get() of std::nullable<T> is a bad practice without checking
> for the value returned by the null() member function first, I suggest
> either throwing an exception or returning a default value of T, because
> undefined behaviour is hard to track.

Yes, that's true. By analogy with std::optional::value(), this function
should be checked. Though perhaps the better solution is to deprecate
odb::nullable in favor of std::optional (which we plan to support out
of the box in the next release of ODB). I've filed an issue to track
this:

https://github.com/codesynthesis-com/odb/issues/10

Thanks for the report.

From PStath at jmawireless.com  Tue Apr  1 17:59:24 2025
From: PStath at jmawireless.com (Paul Stath)
Date: Mon Apr 14 08:49:47 2025
Subject: [odb-users] ODB 2.5.0 compiler error
Message-ID: <SA2PR08MB6713650DB4674670A59F44FAD9AC2@SA2PR08MB6713.namprd08.prod.outlook.com>

Hi Boris,

I'm porting one of our ODB projects from Redhat 8 to Redhat 9.
As part of that effort, I'm trying to upgrade to the ODB 2.5.0 release.

I have compiled the build2 toolchain and also:
* odb
* libodb
* libodb-sqlite
* libodb-boost

The compiler is GCC v 11.3.1:
$ g++ --version 
g++ (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ rpm -qa | grep gcc
libgcc-11.3.1-4.3.el9.x86_64
gcc-11.3.1-4.3.el9.x86_64
gcc-plugin-annobin-11.3.1-4.3.el9.x86_64
gcc-c++-11.3.1-4.3.el9.x86_64
gcc-plugin-devel-11.3.1-4.3.el9.x86_64

The bpkg tests run successfully:
$ bpkg test odb
ld odb-2.5.0/odb/plugin{odb}      
ld odb-2.5.0/odb/exe{odb}         
test odb-2.5.0/tests/testscript{testscript}
tested odb/2.5.0      

$ bpkg test --all --recursive
ld libodb-boost-2.5.0/odb/boost/libs{odb-boost}
ld libodb-sqlite-2.5.0/odb/sqlite/libs{odb-sqlite}
ld libodb-boost-2.5.0/tests/basics/exe{driver}
ld libodb-sqlite-2.5.0/tests/basics/exe{driver}
test libodb-2.5.0/tests/basics/exe{driver}
test libodb-boost-2.5.0/tests/basics/exe{driver}
test libodb-sqlite-2.5.0/tests/basics/exe{driver}
tested libodb/2.5.0   
tested libodb-sqlite/2.5.0
tested libodb-boost/2.5.0

I am using the PRAGMA_DB() inline macros in my hxx files.

PRAGMA_DB(object readonly)
class Passwd : public std::enable_shared_from_this<Passwd> {

public:
    static constexpr unsigned int CRYPT_ITERATIONS = 10000;
    using pointer = std::shared_ptr<Passwd>;
    using key_t = unsigned long;

    ~Passwd();

    static pointer                                  create(const std::string& plainText, bool strict = true);
    bool                                            authenticate(const std::string& plainText) const;
    static void                                     validatePasswd(const std::string& passwd, bool strict = true);

    key_t                                           key() const { return key_; }

private:
    friend std::ostream& operator<<(std::ostream&, const Passwd&);
    friend class odb::access;
    friend class User;

    Passwd(); // Requited by ODB

    PRAGMA_DB(id auto)
    key_t                                           key_;

    PRAGMA_DB(not_null)
    std::weak_ptr<User>                             user_;

    PRAGMA_DB(type("TEXT"))
    crypt_buff                                      salt_;

    unsigned int                                    iterations_;

    PRAGMA_DB(type("TEXT"))
    crypt_buff                                      digest_; // password digest
};

When I attempt to use the odb compile command, I get errors like the following:
    Auth.hpp:60:5: error: db pragma 'id' is not associated with a declaration
    Auth.hpp:63:5: error: db pragma 'not_null' is not associated with a declaration
    Auth.hpp:66:5: error: db pragma 'type' is not associated with a declaration
    Auth.hpp:66:5: error: db pragma 'type' is not associated with a declaration
    Auth.hpp:71:5: error: db pragma 'type' is not associated with a declaration
    Auth.hpp:71:5: error: db pragma 'type' is not associated with a declaration

It doesn't complain about the "PRAGMA_DB(object readonly) line located right before the class.
If comment out the positioned pragmas and add named parameters, the ODB code is generated properly.

It looks like the positioned pragmas are not being matched up with the data member variables.

Hopefully I'm just missing something simple?

If you need more information, please ask.

Thanks,

--- Paul

From boris at codesynthesis.com  Wed Apr 16 05:38:17 2025
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Apr 16 05:36:46 2025
Subject: [odb-users] ODB 2.5.0 compiler error
In-Reply-To: <SA2PR08MB6713650DB4674670A59F44FAD9AC2@SA2PR08MB6713.namprd08.prod.outlook.com>
References: <SA2PR08MB6713650DB4674670A59F44FAD9AC2@SA2PR08MB6713.namprd08.prod.outlook.com>
Message-ID: <boris.20250416112758@codesynthesis.com>

Paul Stath <PStath@jmawireless.com> writes:

> I have compiled the build2 toolchain and also:
> * odb
> * libodb
> * libodb-sqlite
> * libodb-boost

FYI, we provide rpm packages for RHEL 9 (and 8):

https://www.codesynthesis.com/products/odb/download.xhtml

(Though there is nothing wrong with building them from source.)


> It looks like the positioned pragmas are not being matched up
> with the data member variables.

I've tried it on a basic test like this:

#include <odb/core.hxx>

PRAGMA_DB(object)
class person
{
public:
  PRAGMA_DB(id auto)
  unsigned long long id_;
};

But it works fine for me, though with GCC 14, not 11. Could you
provide a minimal but complete reproducer for this?

From boris at codesynthesis.com  Wed Apr 16 05:55:01 2025
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Apr 16 05:53:27 2025
Subject: [odb-users] Object already persistent but it's not true
In-Reply-To: <CADPyhbDgmbfnFiv2yhBs6g0bBdHhNDWSwfkgO2GjHzvxwg6QgA@mail.gmail.com>
References: <CADPyhbDgmbfnFiv2yhBs6g0bBdHhNDWSwfkgO2GjHzvxwg6QgA@mail.gmail.com>
Message-ID: <boris.20250416115407@codesynthesis.com>

roberto minarelli <roberto.minarelli.de@gmail.com> writes:

> I got a serious and strange problem using odb.2.5..0-b.25 after passing
> from Oracle 11g to Oracle 19c

Can you try the final 2.5.0 release of ODB? We have fixed a few
Oracle-related issues since b.25.

From boris at codesynthesis.com  Wed Apr 16 06:01:17 2025
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Apr 16 05:59:43 2025
Subject: [odb-users] Compilation Error with ODB Qt Profile: C++11
	Requirement and Missing QDateTime Header
In-Reply-To: <SJ0PR11MB71530120E67F35DFD90D303DABA22@SJ0PR11MB7153.namprd11.prod.outlook.com>
References: <SJ0PR11MB71530120E67F35DFD90D303DABA22@SJ0PR11MB7153.namprd11.prod.outlook.com>
Message-ID: <boris.20250416115620@codesynthesis.com>

>   *
> ODB Version: 2.4.0

The latest released ODB version is 2.5.0, I suggest you switch to
that.


> Why does Qt still report a missing C++11 support even with
> --std c++11?

I am not sure. With --std c++11 the ODB compiler will invoke GCC
in the C++11 mode so it must be something to do with Qt. You can
try running the ODB compiler with -v to see the options passed to
GCC.


> The QDateTime header is not found despite providing -I QT_ROOT/include.

Qt headers can be included as either <QDateTime> or <QtCore/QDataTime>.
Depending on the style, you may need to provide a different -I path (or
both). Again, this is really a Qt question, not ODB.