NTSTATUS trick for NTTIME?

[tridge at samba.org]

Hi Volker,

 > Compiling with -Wconversion gives tons of warnings in S3. I
 > doubt that fixing all of them is less effort than using the
 > struct approach.

We could filter it so we only see the NTTIME/time_t ones if you would
prefer that. It depends how many there are of the others.

 > Well, except that we get them as additional warnings instead
 > of having them hidden between hundreds of other warnings.

thus the filtering :-)

 > To be useful in development, I don't think relying on waf magic in
 > autobuild is good enough. 

in autobuild it would just be a matter of checking a list of regular
expressions or egrep rules on the compile log. If we get a match, we
reject the build and the user gets an email.

This basic mechanism would allow us to catch others errors as well if
we want to.

 > The round-trip time there is just too high. Doing some waf magic on
 > top of the structure approach is probably very worthwile too.

I think its worth investigating the filtering approach and autobuild
rules. I know we have had bugs between NTTIME and time_t, which is why
you started on this, but I'd be surprised if the rate we introduce new
bugs of this type is high. The key is to ensure that we don't get any
new ones in the tree. We can do that in autobuild, and not pay any
price in terms of code complexity or runtime overhead.

Note that I suggested several possible mechanisms. The waf based
filtering would be directly in the build, so the developer sees it
immediately. That would basically gives us a custom compiler wrapper
that says "make this specific warning about NTTIME and time_t an
error, but hide all the other -Wconversion warnings". If we wanted to,
the same could be done in the autoconf build by making the .c.o rule
in Makefile.in a bit more complex (ie. calling to a compiler wrapper
script).

The autobuild approach is different, and doesn't involve waf. That
would be a set of regular expressions in script/autobuld.py that says
"don't let any build with the following patterns in the build log into
the master tree".

Cheers, Tridge