lighttpd 1.4.x https://www.lighttpd.net/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

301 lines
8.0 KiB

/* _XOPEN_SOURCE >= 500 for vsnprintf() */
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 700
#endif
#include "first.h"
#include "ck.h"
#include "log.h"
#include <sys/types.h>
#include "sys-time.h"
#include <errno.h>
#include <string.h>
#include <stdarg.h>
#include <stdio.h> /* vsnprintf() */
#include <stdlib.h> /* malloc() free() */
#include <unistd.h>
#ifdef HAVE_SYSLOG_H
# include <syslog.h>
#endif
/* log_con_jqueue instance here to be defined in shared object (see base.h) */
connection *log_con_jqueue;
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
unix_time64_t log_epoch_secs = 0;
unix_time64_t log_monotonic_secs = 0;
#if !defined(HAVE_CLOCK_GETTIME) || !HAS_TIME_BITS64
int log_clock_gettime (const int clockid, unix_timespec64_t * const ts) {
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#ifdef HAVE_CLOCK_GETTIME
#if HAS_TIME_BITS64
return clock_gettime(clockid, ts);
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#else
struct timespec ts32;
int rc = clock_gettime(clockid, &ts32);
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
if (0 == rc) {
/*(treat negative 32-bit tv.tv_sec as unsigned)*/
ts->tv_sec = TIME64_CAST(ts32.tv_sec);
ts->tv_nsec = ts32.tv_nsec;
}
return rc;
#endif
#else
/* Mac OSX before 10.12 Sierra does not provide clock_gettime()
* e.g. defined(__APPLE__) && defined(__MACH__)
* && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101200 */
struct timeval tv;
gettimeofday(&tv, NULL);
UNUSED(clockid);
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#if HAS_TIME_BITS64
ts->tv_sec = tv.tv_sec;
#else /*(treat negative 32-bit tv.tv_sec as unsigned)*/
ts->tv_sec = TIME64_CAST(tv.tv_sec);
#endif
ts->tv_nsec = tv.tv_usec * 1000;
return 0;
#endif
}
int log_clock_gettime_realtime (unix_timespec64_t *ts) {
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#ifdef HAVE_CLOCK_GETTIME
return log_clock_gettime(CLOCK_REALTIME, ts);
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#else
return log_clock_gettime(0, ts);
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
#endif
}
#endif /* !defined(HAVE_CLOCK_GETTIME) || !HAS_TIME_BITS64 */
/* retry write on EINTR or when not all data was written */
ssize_t write_all(int fd, const void * const buf, size_t count) {
ssize_t written = 0;
ssize_t wr;
do {
wr = write(fd, (const char *)buf + written, count);
} while (wr > 0 ? (written += wr, count -= wr) : wr < 0 && errno == EINTR);
if (__builtin_expect( (0 == count), 1))
return written;
else {
if (0 == wr) errno = EIO; /* really shouldn't happen... */
return -1; /* fail - repeating probably won't help */
}
}
static int log_buffer_prepare(const log_error_st *errh, const char *filename, unsigned int line, buffer *b) {
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
static unix_time64_t tlast;
static uint32_t tlen;
static char tstr[24]; /* 20 "%F %T" incl '\0' +3 ": (" */
switch(errh->errorlog_mode) {
case ERRORLOG_PIPE:
case ERRORLOG_FILE:
case ERRORLOG_FD:
if (-1 == errh->errorlog_fd) return -1;
/* cache the generated timestamp */
if (__builtin_expect( (tlast != log_epoch_secs), 0)) {
struct tm tm;
tlast = log_epoch_secs;
tlen = (uint32_t)
strftime(tstr, sizeof(tstr), "%F %T",
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
12 months ago
localtime64_r(&tlast, &tm));
tstr[ tlen] = ':';
tstr[++tlen] = ' ';
tstr[++tlen] = '(';
/*tstr[++tlen] = '\0';*//*(not necessary for our use)*/
}
buffer_copy_string_len(b, tstr, tlen);
break;
case ERRORLOG_SYSLOG:
/* syslog is generating its own timestamps */
buffer_copy_string_len(b, CONST_STR_LEN("("));
break;
}
buffer_append_string(b, filename);
buffer_append_string_len(b, CONST_STR_LEN("."));
fix buffer, chunk and http_chunk API * remove unused structs and functions (buffer_array, read_buffer) * change return type from int to void for many functions, as the return value (indicating error/success) was never checked, and the function would only fail on programming errors and not on invalid input; changed functions to use force_assert instead of returning an error. * all "len" parameters now are the real size of the memory to be read. the length of strings is given always without the terminating 0. * the "buffer" struct still counts the terminating 0 in ->used, provide buffer_string_length() to get the length of a string in a buffer. unset config "strings" have used == 0, which is used in some places to distinguish unset values from "" (empty string) values. * most buffer usages should now use it as string container. * optimise some buffer copying by "moving" data to other buffers * use (u)intmax_t for generic int-to-string functions * remove unused enum values: UNUSED_CHUNK, ENCODING_UNSET * converted BUFFER_APPEND_SLASH to inline function (no macro feature needed) * refactor: create chunkqueue_steal: moving (partial) chunks into another queue * http_chunk: added separate function to terminate chunked body instead of magic handling in http_chunk_append_mem(). http_chunk_append_* now handle empty chunks, and never terminate the chunked body. From: Stefan Bühler <stbuehler@web.de> git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2975 152afb58-edef-0310-8abb-c4023f1b3aa9
8 years ago
buffer_append_int(b, line);
buffer_append_string_len(b, CONST_STR_LEN(") "));
return 0;
}
static void log_write(const log_error_st *errh, buffer *b) {
switch(errh->errorlog_mode) {
case ERRORLOG_PIPE:
case ERRORLOG_FILE:
case ERRORLOG_FD:
buffer_append_string_len(b, CONST_STR_LEN("\n"));
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
write_all(errh->errorlog_fd, BUF_PTR_LEN(b));
break;
case ERRORLOG_SYSLOG:
syslog(LOG_ERR, "%s", b->ptr);
break;
}
}
static void
log_buffer_append_encoded (buffer * const b,
const char * const s, const size_t n)
{
size_t i;
for (i = 0; i < n && ' ' <= s[i] && s[i] <= '~'; ++i) ;/*(ASCII isprint())*/
if (i == n)
buffer_append_string_len(b, s, n); /* common case; nothing to encode */
else
buffer_append_string_c_escaped(b, s, n);
}
__attribute_format__((__printf__, 2, 0))
static void
log_buffer_vprintf (buffer * const b,
const char * const fmt, va_list ap)
{
/* NOTE: log_buffer_prepare() ensures 0 != b->used */
/*assert(0 != b->used);*//*(only because code calcs below assume this)*/
/*assert(0 != b->size);*//*(errh->b should not have 0 size here)*/
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
size_t blen = buffer_clen(b);
size_t bsp = buffer_string_space(b)+1;
char *s = b->ptr + blen;
size_t n;
va_list aptry;
va_copy(aptry, ap);
n = (size_t)vsnprintf(s, bsp, fmt, aptry);
va_end(aptry);
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
if (n < bsp)
buffer_truncate(b, blen+n); /*buffer_commit(b, n);*/
else {
s = buffer_extend(b, n);
vsnprintf(s, n+1, fmt, ap);
}
size_t i;
for (i = 0; i < n && ' ' <= s[i] && s[i] <= '~'; ++i) ;/*(ASCII isprint())*/
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
if (i == n) return; /* common case; nothing to encode */
/* need to encode log line
* copy original line fragment, append encoded line to buffer, free copy */
char * const src = (char *)malloc(n);
memcpy(src, s, n); /*(note: not '\0'-terminated)*/
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
buffer_truncate(b, blen);
buffer_append_string_c_escaped(b, src, n);
free(src);
}
__attribute_noinline__
static void
log_error_append_strerror (buffer * const b, const int errnum)
{
char buf[1024];
errno_t rc = ck_strerror_s(buf, sizeof(buf), errnum);
if (0 == rc || rc == ERANGE)
buffer_append_str2(b, CONST_STR_LEN(": "), buf, strlen(buf));
}
__attribute_format__((__printf__, 4, 0))
static void
log_error_va_list_impl (log_error_st * const errh,
const char * const filename,
const unsigned int line,
const char * const fmt, va_list ap,
const int perr)
{
const int errnum = errno;
buffer * const b = &errh->b;
if (-1 == log_buffer_prepare(errh, filename, line, b)) return;
log_buffer_vprintf(b, fmt, ap);
if (perr)
log_error_append_strerror(b, errnum);
log_write(errh, b);
errno = errnum;
}
void
log_error(log_error_st * const errh,
const char * const filename, const unsigned int line,
const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
log_error_va_list_impl(errh, filename, line, fmt, ap, 0);
va_end(ap);
}
void
log_perror (log_error_st * const errh,
const char * const filename, const unsigned int line,
const char * const fmt, ...)
{
va_list ap;
va_start(ap, fmt);
log_error_va_list_impl(errh, filename, line, fmt, ap, 1);
va_end(ap);
}
void
log_error_multiline_buffer (log_error_st * const restrict errh,
const char * const restrict filename,
const unsigned int line,
const buffer * const restrict multiline,
const char * const restrict fmt, ...)
{
if (multiline->used < 2) return;
const int errnum = errno;
buffer * const b = &errh->b;
if (-1 == log_buffer_prepare(errh, filename, line, b)) return;
va_list ap;
va_start(ap, fmt);
log_buffer_vprintf(b, fmt, ap);
va_end(ap);
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
const size_t prefix_len = buffer_clen(b);
const char * const end = multiline->ptr + multiline->used - 2;
const char *pos = multiline->ptr-1, *current_line;
do {
pos = strchr(current_line = pos+1, '\n');
if (!pos)
pos = end;
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
1 year ago
buffer_truncate(b, prefix_len);
log_buffer_append_encoded(b, current_line, pos - current_line);
log_write(errh, b);
} while (pos < end);
errno = errnum;
}
log_error_st *
log_error_st_init (void)
{
log_error_st *errh = calloc(1, sizeof(log_error_st));
force_assert(errh);
errh->errorlog_fd = STDERR_FILENO;
errh->errorlog_mode = ERRORLOG_FD;
return errh;
}
void
log_error_st_free (log_error_st *errh)
{
if (NULL == errh) return;
free(errh->b.ptr);
free(errh);
}