Re: Remove pg_strtouint64(), use strtoull() directly
От | Tom Lane |
---|---|
Тема | Re: Remove pg_strtouint64(), use strtoull() directly |
Дата | |
Msg-id | 822554.1639406672@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Remove pg_strtouint64(), use strtoull() directly (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Remove pg_strtouint64(), use strtoull() directly
Re: Remove pg_strtouint64(), use strtoull() directly |
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 10.12.21 16:25, Tom Lane wrote: >> Our experience with the variable size of "long" has left a sufficiently >> bad taste in my mouth that I'm not enthused about adding hard-wired >> assumptions that "long long" is identical to int64. So this seems like >> it's going in the wrong direction, and giving up portability that we >> might want back someday. > What kind of scenario do you have in mind? Someone making their long > long int 128 bits? Yeah, exactly. That seems like a natural evolution: short -> 2 bytes int -> 4 bytes long -> 8 bytes long long -> 16 bytes so I'm surprised that vendors haven't done that already instead of inventing hacks like __int128. Our current hard-coded uses of long long are all written on the assumption that it's *at least* 64 bits, so we'd survive OK on such a platform so long as we don't start confusing it with *exactly* 64 bits. regards, tom lane
В списке pgsql-hackers по дате отправления: