[PATCHES v2] Fix FreeBSD developer build

Andrew Bartlett abartlet at samba.org
Wed Nov 22 20:56:37 UTC 2017

On Wed, 2017-11-22 at 22:05 +0200, Uri Simchoni via samba-technical
> On 11/22/2017 03:02 PM, Stefan Metzmacher wrote:
> > 
> > I'm not so happy with the cflags_end change.
> > Shouldn't we fix pidl to avoid generating unused functions?
> > 
> > I'm also wondering what an actual example error message is.
> > As I guess we already make sure we don't have any unused static
> > functions with the master autobuild.
> > 
> Here's the build result with the patch removed:
> [1836/3977] Compiling default/librpc/gen_ndr/py_misc.c
> default/librpc/gen_ndr/py_misc.c:34:25: error: unused function
> 'ndr_sizeof2intmax' [-Werror,-Wunused-function]
> static inline long long ndr_sizeof2intmax(size_t var_size)
>                         ^
> default/librpc/gen_ndr/py_misc.c:50:25: error: unused function
> 'ndr_PyLong_FromLongLong' [-Werror,-Wunused-function]
> static inline PyObject *ndr_PyLong_FromLongLong(long long v)
>                         ^
> Thanks,
> Uri.

So, we got the unused function in this commit:

commit e6fbeb860638ad1113914b9460a618025d950d08
Author: Stefan Metzmacher <metze at samba.org>
Date:   Tue Sep 1 10:30:49 2015 +0200

    pidl/python: also add a ndr_PyLong_FromLongLong() for symnetric reasons
    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11429
    Signed-off-by: Stefan Metzmacher <metze at samba.org>
    Reviewed-by: Stefan Metzmacher <metze at samba.org>

diff --git a/pidl/lib/Parse/Pidl/Samba4/Python.pm b/pidl/lib/Parse/Pidl/Samba4/Python.pm
index 056ab21e9c4..180b6b20089 100644
--- a/pidl/lib/Parse/Pidl/Samba4/Python.pm
+++ b/pidl/lib/Parse/Pidl/Samba4/Python.pm
@@ -1280,7 +1280,7 @@ sub ConvertScalarToPython($$$)
        $ctypename = expandAlias($ctypename);
        if ($ctypename =~ /^(int64|dlong)$/) {
-               return "($cvar > LONG_MAX || $cvar < LONG_MIN) ? PyLong_FromLongLong($cvar) : PyInt_FromLong($cvar)";
+               return "ndr_PyLong_FromLongLong($cvar)";
        if ($ctypename =~ /^(uint64|hyper|NTTIME_hyper|NTTIME|NTTIME_1sec|udlong|udlongr|uid_t|gid_t)$/) {
@@ -1535,6 +1535,15 @@ static inline long long ndr_sizeof2intmax(size_t var_size)
        return 0;
+static inline PyObject *ndr_PyLong_FromLongLong(long long v)
+       if (v > LONG_MAX || v < LONG_MIN) {
+               return PyLong_FromLongLong(v);
+       } else {
+               return PyInt_FromLong(v);
+       }
 static inline PyObject *ndr_PyLong_FromUnsignedLongLong(unsigned long long v)
        if (v > LONG_MAX) {

The explanation (in short, to shut up Coverity) is in the previous one:

commit d1416d65a3cc61e4e56d1a43bb634d12f418ba0e
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Tue Sep 1 14:33:35 2015 +1200

    pidl/python: Provide static inline helper function ndr_PyLong_FromUnsignedLongLong
    This should isolate any coverity warnings on 64-bit platforms
    (where LONG_MAX is larger than any possible 32 bit value) to
    a single spot, or possibly eliminate it.
    This is needed for the unsigned 64 bit case, and on 32 bit
    systems, as PyInt_FromLong is limited to a signed "long" int.
    The compiler should be able to eliminate many of these calls
    with the embedded type knowlege.
    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11429
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Stefan Metzmacher <metze at samba.org>

When we finally are python3 only this won't matter, it doesn't have a
different long integer type.

We could go back to the inline, or we could make all intergers Long in

Unless we do that, we need to keep the condition somewhere, as the PIDL
output is not target arch specific, but generic C.

Of course we could somehow note if the function is ever called in the
output and so not include the function, but I've not looked into how
much work that is.

I hope this provides the background.

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   

More information about the samba-technical mailing list