| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: 64 bit numbers vs format strings |
| Date: | 2025-03-04 09:02:57 |
| Message-ID: | 57075986-61ff-4f80-aecf-3b052daf3bef@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02.03.25 22:08, Thomas Munro wrote:
> And one more thing like that: in a couple of places we see warnings on
> macOS CI that I'd missed: when printing the result of i64abs() as
> PRId64, because it happens to use labs() and it happens to define
> int64_t as long long, and when printing a Datum as PRIx64, because
> Datum is uintptr_t and it happens to define that as unsigned long. I
> suppose we should cast to int64 in the definition of c.h's i64abs()
> macro and a couple of similar things,
agreed
> and cast Datum to uint64 in that
> one place that wants to print it out.
Since Datum is uintptr_t, it should be printed using the format PRIxPTR.
Then it should work out.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2025-03-04 09:10:40 | Re: encode/decode support for base64url |
| Previous Message | jian he | 2025-03-04 08:57:49 | Re: tests for pg_stat_progress_copy.tuples_skipped |