Copilot commented on code in PR #3599:
URL: https://github.com/apache/brpc/pull/3599#discussion_r4250134531


##########
src/butil/endpoint.cpp:
##########
@@ -442,13 +442,8 @@ short kqueue_to_poll_events(int kqueue_events) {
 }
 #endif
 
-int pthread_fd_wait(int fd, unsigned events,
-                    const timespec* abstime) {
-#if defined(OS_LINUX)
-    const short poll_events = epoll_to_poll_events(events);
-#elif defined(OS_MACOSX)
-    const short poll_events = kqueue_to_poll_events(events);
-#endif
+static int pthread_fd_wait_impl(int fd, short poll_events,
+                                const timespec* abstime) {

Review Comment:
   `pthread_fd_wait_impl` is a good refactor, but the new non-static macOS 
overload introduced below (`int pthread_fd_wait(int fd, int events, ...)`) adds 
an externally visible symbol that (from this diff) is not declared in a shared 
header. This commonly triggers `-Wmissing-declarations`/`-Wmissing-prototypes` 
style builds and makes the effective API surface differ across translation 
units. Consider either (mandatory) declaring the macOS `int` overload in the 
appropriate public header under `#if defined(OS_MACOSX)`, or (alternative) 
keeping only the `unsigned` public API and having macOS callers (including 
`pthread_timed_connect`) call `pthread_fd_wait_impl(..., POLLIN/POLLOUT, ...)` 
directly so no extra exported overload is needed.



##########
test/endpoint_unittest.cpp:
##########
@@ -16,19 +16,30 @@
 // under the License.
 
 #include <gtest/gtest.h>
+#include <atomic>
+#include <pthread.h>
+#include <signal.h>
 #include <butil/fd_guard.h>
 #include <butil/fd_utility.h>
 #include "butil/errno.h"
 #include "butil/endpoint.h"
 #include "butil/logging.h"
+#include "butil/memory/scope_guard.h"
 #include "butil/containers/flat_map.h"
 #include "butil/details/extended_endpoint.hpp"
 #include <netinet/tcp.h>
-#if defined(OS_MACOSX)
+#if defined(OS_LINUX)
+#include <sys/epoll.h>
+#elif defined(OS_MACOSX)
+#include <sys/event.h>
 #include <netinet/tcp_fsm.h>
 #endif
 
 namespace butil {
+int pthread_fd_wait(int fd, unsigned events, const timespec* abstime);
+#if defined(OS_MACOSX)
+int pthread_fd_wait(int fd, int events, const timespec* abstime);
+#endif

Review Comment:
   The test adds manual forward declarations for `butil::pthread_fd_wait` 
(including a macOS-only overload). This is brittle: the test can silently drift 
from the real declarations/`#if` guards, and it effectively relies on a 
non-header-declared symbol. Prefer (mandatory) including the header that 
declares `pthread_fd_wait`, and if the `int` overload is intended to be used 
outside `endpoint.cpp` then declare it in that header as well; otherwise 
(alternative) adjust the macOS tests to exercise the existing `unsigned` API 
(e.g., via `static_cast<unsigned>(EVFILT_READ/WRITE)`) without depending on the 
overload.



##########
test/run_tests.sh:
##########
@@ -46,6 +46,23 @@ if [ $test_num -eq 0 ]; then
 fi
 
 print_bt () {
+    case "${2-}" in
+        ''|*[!0-9]*) return ;;
+    esac
+    # Assertion failures exit normally. A passing death test may have left a
+    # core in this binary, so only consider statuses that can represent a 
signal.
+    if [ "$2" -le 128 ] || [ "$2" -gt 255 ]; then
+        return
+    fi
+    # Strip leading zeros so shell arithmetic does not interpret them as octal.
+    signal_number=$2
+    while [ "${signal_number#0}" != "$signal_number" ]; do
+        signal_number=${signal_number#0}
+    done
+    signal_number=$((signal_number - 128))

Review Comment:
   `signal_number` is introduced as a function-scoped working variable, but in 
shell functions variables are global by default. This can unintentionally 
clobber a same-named variable outside `print_bt` (especially in larger 
scripts). Consider using a uniquely prefixed variable name (e.g., 
`bt_signal_number`) or, if this script is guaranteed to run under Bash, declare 
it as `local signal_number`.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to