mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-07-16 06:31:10 +02:00
POSIX specifies that jrand48() returns a signed 32-bit value (in the range [-2^31, 2^31)), but our code was returning an unsigned 32-bit value (in the range [0, 2^32)). This doesn't actually matter to any existing call site, because they all cast the "long" result to int32 or uint32; but it will doubtless bite somebody in the future. To fix, cast the arithmetic result to int32 explicitly before the compiler widens it to long (if widening is needed). While at it, upgrade this file's far-short-of-project-style comments. Had there been some peer pressure to document pg_jrand48() properly, maybe this thinko wouldn't have gotten committed to begin with. Backpatch to v10 where pg_jrand48() was added, just in case somebody back-patches a fix that uses it and depends on the standard behavior. Discussion: https://postgr.es/m/17235.1545951602@sss.pgh.pa.us |
||
---|---|---|
.. | ||
.gitignore | ||
chklocale.c | ||
crypt.c | ||
dirent.c | ||
dirmod.c | ||
erand48.c | ||
fls.c | ||
fseeko.c | ||
getaddrinfo.c | ||
getopt_long.c | ||
getopt.c | ||
getpeereid.c | ||
getrusage.c | ||
gettimeofday.c | ||
inet_aton.c | ||
inet_net_ntop.c | ||
isinf.c | ||
kill.c | ||
Makefile | ||
mkdtemp.c | ||
noblock.c | ||
open.c | ||
path.c | ||
pg_crc32c_armv8_choose.c | ||
pg_crc32c_armv8.c | ||
pg_crc32c_sb8.c | ||
pg_crc32c_sse42_choose.c | ||
pg_crc32c_sse42.c | ||
pg_strong_random.c | ||
pgcheckdir.c | ||
pgmkdirp.c | ||
pgsleep.c | ||
pgstrcasecmp.c | ||
pqsignal.c | ||
pthread-win32.h | ||
qsort_arg.c | ||
qsort.c | ||
quotes.c | ||
random.c | ||
README | ||
rint.c | ||
snprintf.c | ||
sprompt.c | ||
srandom.c | ||
strerror.c | ||
strlcat.c | ||
strlcpy.c | ||
strnlen.c | ||
system.c | ||
tar.c | ||
thread.c | ||
unsetenv.c | ||
win32.ico | ||
win32env.c | ||
win32error.c | ||
win32security.c | ||
win32setlocale.c | ||
win32ver.rc |
src/port/README libpgport ========= libpgport must have special behavior. It supplies functions to both libraries and applications. However, there are two complexities: 1) Libraries need to use object files that are compiled with exactly the same flags as the library. libpgport might not use the same flags, so it is necessary to recompile the object files for individual libraries. This is done by removing -lpgport from the link line: # Need to recompile any libpgport object files LIBS := $(filter-out -lpgport, $(LIBS)) and adding infrastructure to recompile the object files: OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \ connect.o misc.o path.o exec.o \ $(filter snprintf.o, $(LIBOBJS)) The problem is that there is no testing of which object files need to be added, but missing functions usually show up when linking user applications. 2) For applications, we use -lpgport before -lpq, so the static files from libpgport are linked first. This avoids having applications dependent on symbols that are _used_ by libpq, but not intended to be exported by libpq. libpq's libpgport usage changes over time, so such a dependency is a problem. Windows, Linux, and macOS use an export list to control the symbols exported by libpq.