From patchwork Fri Sep 27 16:12:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 1990342 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LaAqr2Rm; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4XFb935tSxz1xst for ; Sat, 28 Sep 2024 02:12:55 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AA7C8385DDC1 for ; Fri, 27 Sep 2024 16:12:52 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id E767C3858C5F for ; Fri, 27 Sep 2024 16:12:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E767C3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E767C3858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727453557; cv=none; b=lBIJBpwHpSzRq/dn+OtO1EojBp3MZVsGK07rarA3+yXvwoklnccrH5sSzuAB+ApjVx6921IIy4Qa8nKntvvysuPcFA+PuydZctTEEiw9epSgSGVeDhVHDCxbjtszicPDjoGYDUrk7PwEQHz2OvI5mUin1z6qcC2ggXX8EEA4QGE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727453557; c=relaxed/simple; bh=rrzD5sLh6phgQEVMvrYnUSSw2U1bq928cjZNxdFo5qc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=YvjFsNz8dNnyZNa0c4XoudtMLcrMxrEVbExJM4wvgCtnOZB+DQMNv/PcO9IjZ8yzw5POtK267+K02dF9YLF81XCDVhdEB8qELj36wRolQWTV0RE1M0qWB3u+P6X5N1JhKUmbLG3W9LCK2XIwilhN4tt2CO1w3aeBCymOqMWSVuc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727453555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=JOZXd5GCADDGdUtdhsuZe+2pQHITF3lFktW9mjv1WeI=; b=LaAqr2Rmu99Bzd8A3c9ctkGGFtf+zjjwTVW2P3zLqOdCrbLkWQbZVVGQ02flArGQ1BcC2Z GGd78yHIHA61Es9y/AjqgIMNX/lQoyW8fRfpXq/nlNXpra52V/XbP3jWr3FFnnHPtcEs1q du3etgyePbKYXUJuCTJaUoxShpxSo94= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-425-7xRjfMdfODGVTThZpeWFdw-1; Fri, 27 Sep 2024 12:12:34 -0400 X-MC-Unique: 7xRjfMdfODGVTThZpeWFdw-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (unknown [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 843C8191041A for ; Fri, 27 Sep 2024 16:12:33 +0000 (UTC) Received: from prancer.redhat.com (unknown [10.42.28.28]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E04D81979061 for ; Fri, 27 Sep 2024 16:12:32 +0000 (UTC) From: Nick Clifton To: libc-alpha@sourceware.org Subject: [PATCH v2 0/1] stdio-common: Add more tests of the setvbuf() function. Date: Fri, 27 Sep 2024 17:12:30 +0100 Message-ID: <8734llkrdd.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org Hi Everyone, As part of ongoing work at Red Hat to improve the quality of the glibc testsuite I am submitting this patch to extend the test coverage of the setvbuf() function. The current test (tst-setvbuf1.c) only checks that full buffering can be enabled on stderr. The new tests extend this to cover line buffering and no buffering for stderr and stdout as well as buffering for non-terminal I/O files. There is one issue however. One of the new tests fails. tst-setvbuf4.c attempts to check that when full buffering is enabled on a non-terminal file, writing a single byte to the file does not cause the byte to appear in the file. (At least not until a flush or some other similar file operation is performed). The test however shows that the byte *does* appear. The test is correct I believe, and I think that it does indicate that there is a underlying bug in glibc's file buffering mechanisms. But knowledge of glibc's code base is insufficient to allow me to say where or why. It is possible that the same bug is affecting the tst-setvbuf5.c which checks that line buffering on non-terminal files works. But the POSIX standard explicitly states that line buffering does not have to work for these kind of files, so the test does not fail if line buffering is found to be unsupported. Cheers Nick PS As a new contributor I just wish to confirm that as an engineer working at Red Hat this contribution is covered by a blanket FSF copyright assignment. Nick Clifton (1): stdio-common: Add more tests of the setvbuf() function. stdio-common/Makefile | 23 +++++ stdio-common/tst-setvbuf2.c | 85 +++++++++++++++ stdio-common/tst-setvbuf2.expect | 3 + stdio-common/tst-setvbuf3.c | 111 ++++++++++++++++++++ stdio-common/tst-setvbuf3.expect | 3 + stdio-common/tst-setvbuf4.c | 154 ++++++++++++++++++++++++++++ stdio-common/tst-setvbuf5.c | 171 +++++++++++++++++++++++++++++++ stdio-common/tst-setvbuf6.c | 136 ++++++++++++++++++++++++ 8 files changed, 686 insertions(+) create mode 100644 stdio-common/tst-setvbuf2.c create mode 100644 stdio-common/tst-setvbuf2.expect create mode 100644 stdio-common/tst-setvbuf3.c create mode 100644 stdio-common/tst-setvbuf3.expect create mode 100644 stdio-common/tst-setvbuf4.c create mode 100644 stdio-common/tst-setvbuf5.c create mode 100644 stdio-common/tst-setvbuf6.c