From patchwork Fri Mar 8 20:46:33 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 1053708 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-100515-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="CTJ5v8VU"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 44GKKz2W6wz9ryj for ; Sat, 9 Mar 2019 07:46:47 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:to:subject:mime-version:content-type :content-transfer-encoding:message-id:from; q=dns; s=default; b= n01gawpDFW3kN+FE7s0j2eDQJWkzUBuewyN3Lc6PbcYkpy7u09LgdzQ1+5iHQyaK +qT7Lz8ULaQ5yKp2M2XPts31qzxPN6nVFoacsozvkv2A7ImXKJWcwBKZkPmkVtKX oPbyjcNiiIW9SELPdDVHvMgmU8bga2HlzSMYSS4vERo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:to:subject:mime-version:content-type :content-transfer-encoding:message-id:from; s=default; bh=vp1/rR aDg935OfSRG+P5d7flskw=; b=CTJ5v8VUB4aceDKRCEOAGS3jGPrAaC8piv9IT0 hd5JuiDLikQ4+o/GO1kXfHPtWFR3ie2VQViSAq1r9aEmmMiARkqUgZSAOFd7Evxh XstFm/3cziUrmLuU8tmfm900J2MJdNcTHcJ8LhW8bhNlVVru9MADJPKX0DQ8gHTI pu0hk= Received: (qmail 23532 invoked by alias); 8 Mar 2019 20:46:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 23433 invoked by uid 89); 8 Mar 2019 20:46:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-20.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS, UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1993 X-HELO: mx1.redhat.com Date: Fri, 08 Mar 2019 21:46:33 +0100 To: libc-alpha@sourceware.org Subject: [PATCH] alloc_buffer: Return unqualified pointer type in alloc_buffer_next User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Message-Id: <20190308204633.49DCE80DD6B5@oldenburg2.str.redhat.com> From: Florian Weimer alloc_buffer_next is useful for peeking to the remaining part of the buffer and update it, with subsequent allocation (once the length is known) using alloc_buffer_alloc_bytes. This is not as robust as the other interfaces, but it allows using alloc_buffer with string-writing interfaces such as snprintf and ns_name_ntop. 2019-03-08 Florian Weimer * include/alloc_buffer.h (alloc_buffer_alloc_bytes): Update comment. (alloc_buffer_next): Change return type to non-const. Reviewed-by: Carlos O'Donell Reviewed-by: Carlos O'Donell diff --git a/include/alloc_buffer.h b/include/alloc_buffer.h index f27cbb65ca..7f68f46eac 100644 --- a/include/alloc_buffer.h +++ b/include/alloc_buffer.h @@ -183,7 +183,7 @@ alloc_buffer_add_byte (struct alloc_buffer *buf, unsigned char b) NULL is returned if there is not enough room, and the buffer is marked as failed, or if the buffer has already failed. (Zero-length allocations from an empty buffer which has not yet - failed succeed.) */ + failed succeed.) The buffer contents is not modified. */ static inline __attribute__ ((nonnull (1))) void * alloc_buffer_alloc_bytes (struct alloc_buffer *buf, size_t length) { @@ -302,9 +302,13 @@ __alloc_buffer_next (struct alloc_buffer *buf, size_t align) alloc_buffer_alloc returns the same pointer). Note that the buffer is still aligned according to the requirements of TYPE. The effect of this function is similar to allocating a zero-length array from - the buffer. */ + the buffer. It is possible to use the return pointer to write to + the buffer and consume the written bytes using + alloc_buffer_alloc_bytes (which does not change the buffer + contents), but the calling code needs to perform manual length + checks using alloc_buffer_size. */ #define alloc_buffer_next(buf, type) \ - ((const type *) __alloc_buffer_next \ + ((type *) __alloc_buffer_next \ (buf, __alloc_buffer_assert_align (__alignof__ (type)))) /* Internal function. Allocate an array. */