From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: cast pid_t to int when using *printf |
Date: | 2004-09-24 10:31:59 |
Message-ID: | 4153F79F.2080609@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut wrote:
> Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett:
>
>>Neil Conway wrote:
>>
>>>On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote:
>>>
>>>>gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is
>>>>formatted with %d by a printf-family function.
>>>
>>>For curiosity's sake, what formatting escape does gcc prefer?
>>
>>I don't think there is an escape for pid_t, you always have to cast it.
>
>
> I think what he was asking is this: Since pid_t has to be a signed integer
> type, but gcc does not accept %d for it, then it could be that pid_t is wider
> than an int, so casting it to int would potentially lose information.
pid_t on the Solaris/sparc system is a long (but both int and long are
32 bits). Some experimentation shows that gcc is happy with a %ld format
specifier. But compiling the same code on a Linux/x86 system makes gcc
complain when applying %ld to pid_t, so we will need a cast there either
way.
I notice that elog.c casts MyProcPid to long and uses %ld. Amusingly,
MyProcPid is explicitly an int..
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-09-24 10:34:24 | Re: cast pid_t to int when using *printf |
Previous Message | Peter Eisentraut | 2004-09-24 09:30:07 | Re: cast pid_t to int when using *printf |