progress.c does not compile under Mac OS X

progress.c does not compile under Mac OS X

[Torsten Bögershausen]

progress.c:66: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)

You can not cast a undeclared into void in git-compat-uitl.h:
#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), errno 


Removing the cast of a define into (void) makes the compilation error in line 66 go away:
 #ifdef NO_TIMER_SETTIME
-#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), errno = ENOSYS, -1)
+#define timer_create(clockid, sevp, timerp) ((void) (sevp), (void) (timerp), errno = ENOSYS, -1)
 
But now we have a bunch of other problems:

progress.c:71: warning: assignment makes integer from pointer without a cast
progress.c:71: error: invalid operands to binary / (have ‘long int *’ and ‘long int’)
progress.c:71: warning: statement with no effect
progress.c:71: error: ‘_ivalue_it_value’ undeclared (first use in this function)
progress.c:71: error: (Each undeclared identifier is reported only once
progress.c:71: error: for each function it appears in.)
progress.c:71: error: invalid operands to binary / (have ‘long int *’ and ‘long int’)
progress.c:74: error: expected ‘while’ before ‘static’
progress.c:82: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:82: error: invalid storage class for function ‘display’
progress.c: In function ‘display’:
progress.c:92: warning: implicit declaration of function ‘clear_progress_signal’
progress.c: In function ‘set_progress_signal’:
progress.c:126: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:126: error: invalid storage class for function ‘throughput_string’
progress.c:135: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:199: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:205: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:225: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:230: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:235: error: nested functions are disabled, use -fnested-functions to re-enable
progress.c:264: error: expected declaration or statement at end of input


----------------
And then we have the question why we do not check the return value of timer_create() in progress.c#66:

timer_create(CLOCK_MONOTONIC, &sev, &progress_timer);

value.it_interval.tv_sec = 1;
value.it_interval.tv_nsec = 0;
value.it_value = value.it_interval;
timer_settime(progress_timer, 0, &value, NULL);
--------------
Should it be something like this ?
if (!timer_create(CLOCK_MONOTONIC, &sev, &progress_timer)) {
  value.it_interval.tv_sec = 1;
  value.it_interval.tv_nsec = 0;
  value.it_value = value.it_interval;
  timer_settime(progress_timer, 0, &value, NULL);
}

(And possibly more changes to handle errors when calling
timer_delete(progress_timer)


(Sorry, no, I don't have a patch at hand.
 It feels as if the macros in git-compat-util.h could be converted into real functions,
 in compat/timer_settime.c (or so) so that we can test-compile under Linux)

Re: progress.c does not compile under Mac OS X

[Jonas 'Sortie' Termansen]

Oh,

I'm a bit confused here - lots of things happening. Submitting patches to
projects is usually fairly simple; it's excitingly fresh to get a bunch of
replies, having the patch set revised, more replies, then a further revised
patch set gets merged to a development branch, and then I get suddenly get
emails about breaking the build on OS X. Let's see if I can figure this out. :-)

My original patch had a minor bug where it forgot to compatibility-wrap the
CLOCK_MONOTONIC constant. Surprisingly, it turns out even in 2014 OS X doesn't
have the clock_gettime interface. What a silly operating system.

Jacob Keller revised my patch set and added compatibility macros that emulate
timer_foo using setitimer. Turns out, it had a few typos of its own.

The revised patch set got slightly changed and was merged to the pu branch,
which is where you are having build trouble now.

Alright, so to recover, first appropriately add this to git-compat-util.h:

+#ifndef CLOCK_MOTOTONIC
+#define CLOCK_MONOTONIC 1 /* dummy */
+#define

Secondly, there is a typo where an underscore is used instead of a period.

-       _ivalue_it_value.tv_usec = value.it_value.tv_nsec / 1000L;              \
+       _ivalue.it_value.tv_usec = value.it_value.tv_nsec / 1000L;              \

Third, there needs to be an end brace before the while:

-while (0)
+} while (0)

That should fix the immediate breakage, I believe.

Looking closer, there are a bunch of additional issues here:

+#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), errno = ENOSYS, -1)
+#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp), (void) (timerp), 0)

This emulates a timer_create that always fails. That's not what we are trying to
do, we want to emulate one that always works. It should return 0 instead of
setting errno to ENOSYS and returning -1. (My original patch set made the
replacement timer_create this this way, but at that time I was not trying to
emulate the interface, just stub it.)

Finally patch set also fails to break with platforms with a broken timer_settime
but a working setitimer. If that is something we want to support? Might as well.

On 08/30/2014 10:37 PM, Torsten Bögershausen wrote:
> And then we have the question why we do not check the return value of
> timer_create() in progress.c#66:

It's because the old code didn't check the result value. Secondly it's because
this code is non-essential, if it fails, there is really no choice but to carry
on anyways. I admit it's probably not a good idea to make timer_settime time
with an uninitialized timer id. The likelihood is low though as git only needs
one timer - but I agree it's prudent to check the error codes.

On 08/30/2014 10:37 PM, Torsten Bögershausen wrote:
> It feels as if the macros in git-compat-util.h could be converted into real
> functions, in compat/timer_settime.c (or so) so that we can test-compile under
> Linux)

This is my preferred route as well.

I hope that sorts things out. I'll be submitting a full V2 of my patch set
shortly that should work reliably on all systems. For now, you can fix the build
by applying the above fixes, or perhaps revert the commits as they are
troublesome. :-)

Jonas