From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 1C8456FC8F; Tue, 23 Mar 2021 09:56:54 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1C8456FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616482614; bh=tNl30rXpM3S619p+2o6xLf194O37dQydc6Wyub3QQus=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=wFBgg0UpDyR7+DWCIH0W3rmrJa/X7gGj1DrlhlszTlpa8968psn8K/5iXrQsUG4ks v5h334FQVoc1BIcn42eQjdHSRVnY32AvjS3QSBcJNIdY+M0mhs/TnT8kcoyzGEGNly lJ76/wof1APkHbcLExhstt/LAksxx+0W3vKc6kNw= Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id ED9DB6FC8F for ; Tue, 23 Mar 2021 09:56:51 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org ED9DB6FC8F Received: by mail-lf1-f45.google.com with SMTP id b14so11798735lfv.8 for ; Mon, 22 Mar 2021 23:56:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XfcWXH48+xU1oxeNQfTOqBrh+dz4iB+pkN3VZ4wpPkQ=; b=Vfraex+Q+PBMPPv9l6l4KJXcipKa4Xd3FLv7w600Vwo/HUzghdxhgBlhUZwKMtShgL 93hoL4vQSRYx4DvIXVeD0y7aijzq4k+G2XViymjPacf2fm1oRJLrDEs2MliigvFx+2Bo iuhBUFNZ7xq2ubOco3SERjMHIeFw1ubH7yihRMjBoCk+4AmQWXWgZbrNWMPOxAVKiqRa BJ1iWMb/0YeADvriui/vWP1sqnK41v8naY04a7yPtVWYIkDoJN5Lhz/lXLdQ49K+6bUL WH2ElDHxfvA8FgGbpLeyDPLPoIXllYCWL9X/BospUOGW0q+ZAE+5eUl9ExqzsY8gVHXF u38w== X-Gm-Message-State: AOAM530nzYmic9On6Nks5DUB6aZWYLvvV8wdV1diMA9aDA9NgDKFIGSg /SZkaUNijmnA1TKUoA26xIVTjKhT8ic= X-Google-Smtp-Source: ABdhPJzlPU4MstENKNxRkO6CicnJPhjLXOtYKU9l5PxAgTBwAxKF+aoxKo6M4qFnjLXucBzF5Uk6QQ== X-Received: by 2002:a05:6512:34c9:: with SMTP id w9mr1758573lfr.267.1616482610764; Mon, 22 Mar 2021 23:56:50 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id u22sm2205270ljk.6.2021.03.22.23.56.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 23:56:49 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 58811560175; Tue, 23 Mar 2021 09:56:48 +0300 (MSK) Date: Tue, 23 Mar 2021 09:56:48 +0300 To: Vladislav Shpilevoy Message-ID: References: <9ab1c358c2fda852d7f241dc7ccd3ca4381017bd.1616200860.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH 14/16] sio: increase SERVICE_NAME_MAXLEN size X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Mon, Mar 22, 2021 at 11:32:14PM +0100, Vladislav Shpilevoy wrote: > > > > Actually IPv6 may include a scope as well. Currently at least > > libc indeed does limit it to 45 symbols plus eos mark so we're > > safe. Still 200 seems to be much over the top, maybe 128 instead? > > I decided to be paranoid and made it 200 deliberately. Anyway it is > not used in any swarm allocations. 128 seems right on the edge. You > can have 108 bytes of Unix socket path, + strlen("unix/:"). It is > already 114. > > Also it is used for sio_socketname(), where you have addr str (114) > + strlen(", aka ")(6) + strlen(", peer of ")(10), which is already > 130 total. Aha! Thanks for explanation. > > Also pow2 gonna be easier to manage by any memory manager. > > It would matter if the buffer would be ever allocated on its own. > But it is always either on the stack, or inside of another structure, > where total size is not a power of 2 anyway, most likely. FWIW the data on stack always allocated by size of stack line, ie pow2. But dosn't matter, 200 should be fine, thanks!