From 6b975a8a4015211214517cdd42905ae396975a1f Mon Sep 17 00:00:00 2001 From: Mattias Andrée Date: Sun, 22 Feb 2026 12:53:48 +0100 Subject: m fixes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Mattias Andrée --- Makefile | 6 ++++-- README | 6 +++--- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 1841767..5dfe86f 100644 --- a/Makefile +++ b/Makefile @@ -1,9 +1,9 @@ .POSIX: -CC = cc +CC = c99 CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -CFLAGS = -std=c99 -Wall -O2 +CFLAGS = LDFLAGS = -s BIN = yes limit measure @@ -22,3 +22,5 @@ clean: .SUFFIXES: .SUFFIXES: .c .o + +.PHONY: all clean diff --git a/README b/README index 25bd242..0c3f81c 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ GNU yes(1) is not that fast! -This implementaion is not only about 8 +This implementation is not only about 8 times as fast[0], it uses half as much CPU. Note that this implementation is not even @@ -9,7 +9,7 @@ the pipe and fill that buffer and only do one write(2) or vmsplice(2) to the pipe. Speaking of this overhead, this implementation is completely useless[1] unless the other -program is will even read {PIPE_BUF} bytes +program will even read {PIPE_BUF} bytes (4096 on Linux, 512 on POSIX) + 2²⁰−2¹⁶ bytes (on Linux, unspecified for POSIX). Therefore, this implementation of yes(1) is just silly @@ -19,5 +19,5 @@ and should not be used by anyone. [0] On my computer. If you get different results please leave a comment. -[1] Has no benefits what so every in any +[1] Has no benefits whatsoevery in any aspect at all. -- cgit v1.2.3-70-g09d2