Page 1 of 1

Re: [Nagios-devel] macro_x madness heads up

Posted: Fri Nov 05, 2010 8:45 am
by Guest
On 11/05/2010 12:57 AM, Ton Voon wrote:
> Hey Andreas,
>
> On 29 Oct 2010, at 11:38, Andreas Ericsson wrote:
>
>> On 10/29/2010 11:05 AM, Ton Voon wrote:
>>>
>>> On 28 Oct 2010, at 13:42, Andreas Ericsson wrote:
>>>
>>>> As I have promised, I have delivered. Notifications are still not
>>>> thread-safe, because I simply couldn't follow how the macros are
>>>> modded
>>>> and managed both locally and globally around 4am this morning.
>>>> Perhaps I
>>>> needed more red bull or, quite possibly, sleep.
>>>
>>> Sleep is always good!
>>>
>>> I notice lots of test changes - cool. However, tests are currently
>>> failing due to test-stubs.c being missing. Can you add in?
>>>
>>
>> Will do. Actually, it's done.
>
> Thanks
>
>>
>>> Shouldn't this change be in a different branch? It sounds too risky
>>> for a stable branch.
>>>
>>
>> Not really. It works basically like it used to, but all volatile
>> macros
>> are passed around in a stack-allocated struct that matches
>> s/macro_/mac->/ exactly. I have, and still do, test it extensively as
>> we plan on releasing this for use in production at our customers.
>
> I get these since the recent changes:
>
> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCORE -c -o checks.o checks.c
> checks.c: In function ‘run_async_service_check’:
> checks.c:523: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’
> checks.c:821: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’
> checks.c: In function ‘run_async_host_check_3x’:
> checks.c:3028: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’
> checks.c:3147: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’
> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCORE -c -o config.o config.c
> ...
> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCORE -c -o utils.o utils.c
> utils.c: In function ‘service_check_sighandler’:
> utils.c:1823: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’
> utils.c: In function ‘host_check_sighandler’:
> utils.c:1863: warning: format ‘%lu’ expects type ‘long unsigned int’,
> but argument 4 has type ‘__darwin_suseconds_t’

__darwin_suseconds_t... What madman at apple invented that sick type?
Every other unixy system has 'unsigned long' as time_t.

> utils.c: In function ‘my_fdcopy’:
> utils.c:3054: warning: format ‘%ld’ expects type ‘long int’, but
> argument 4 has type ‘off_t’

That's weird. off_t should always be the same as long, unless long
isn't the same size as (void *), which would violate pretty much the
most sacrosanct pointer-to-counter linkage in the history of C.

> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCORE -c -o retention-base.o
> sretention.c
> ...
> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCGI -c -o macros-cgi.o ../common/
> macros.c
> ../common/macros.c: In function ‘process_macros_r’:
> ../common/macros.c:149: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> ../common/macros.c:176: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> ../common/macros.c:183: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> ../common/macros.c:219: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> ../common/macros.c:230: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> ../common/macros.c:238: warning: format ‘%d’ expects type ‘int’, but
> argument 4 has type ‘size_t’
> gcc -Wall -g -O2 -DHAVE_CONFIG_H -DNSCGI -c -o skiplist.o ../common/
> skiplist.c
>
> Can you fix those? This is on a mac os 10.5 system.
>

Those warnings are a pure pain to deal with, since size_t is typedef'ed
as 'long' on 64-bit systems (should be %ld) and 'int' on 32-bit systems
(should be %d). If they we

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]