Thus said Richard Hipp on Mon, 15 Jan 2018 11:27:20 -0500: > I will accept check-ins to a branch that invoke the fossil_pledge(X,Y) > utility function. The fossil_pledge(X,Y) function is a macro that > evaluates to a no-op except when compiled with -DFOSSIL_HAVE_PLEDGE. > If the FOSSIL_HAVE_PLEDGE macro is defined, then a routine is called > when invokes pledge() and errors out if there is a problem.
I was going to experiment a little with fossil_pledge, but apparently the pledge(2) interface has changed. The one that is in use in Fossil's trunk is for OpenBSD-current (which isn't yet released). Notice that with -current the interface has execpromises: http://man.openbsd.org/pledge But with 6.2 and earlier it was called paths and was a different data type: http://man.openbsd.org/OpenBSD-6.2/pledge Should Fossil only care about one of the interfaces? I suspect the answer to this is yes. I checked OpenBSD sources and it looks like paths wasn't ever used and indeed it sounds like it may have even been unimplemented. I don't have OpenBSD-current installed anywhere, so it doesn't build cleanly: cc -I. -I./src -Ibld -Wall -DFOSSIL_DYNAMIC_BUILD=1 -I/usr/include -DFOSSIL_HAVE_FUSEFS -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -DFOSSIL_HAVE_PLEDGE -o bld/util.o -c bld/util_.c ./src/util.c: In function 'fossil_pledge_impl': ./src/util.c:498: warning: passing argument 2 of 'pledge' from incompatible pointer type Can I safely ignore that warning as long as the second argument to all fossil_pledge() calls are NULL? Thanks, Andy -- TAI64 timestamp: 400000005a5d0889 _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
