From owner-svn-src-all@freebsd.org Tue Feb 11 18:18:57 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 243C323E69C; Tue, 11 Feb 2020 18:18:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48H9yS6wtlz4RMG; Tue, 11 Feb 2020 18:18:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ot1-f65.google.com with SMTP id 77so11067151oty.6; Tue, 11 Feb 2020 10:18:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=VcqLhY+MQuQRiyO7d+oAQBFakxrXgeO2gti0+CEXS2Q=; b=p3KiMFGQ7kh7tIs6HsuCN8MApFrCXolSKrdPYCrFbVLD+s6wpYwBIKYblKzoOt0zCz HkhvWyJOLMBTGslKPNrkesoqeVdIHUPlw9N/L9A5AvDMVkSBbAISs5Afxj5bq7w9Z3Xa apKee2iEch/wvvlVbcRPY9d7aHFkzZA8A7oqgGPP828GXG1lXTuURYh7wEcb+W2cuMCY 8mTd7iFR+cMvq0BL5OpL/ZVP2kOK0RgRPU0X5qdKfMu8bhnR2+zUiWifJ2xHYuNFeyvw LsS+X4JrbkcVPKgEm4dBm4VLd/wBNL4Pf91LYbPB9mR2QDq168meUoMbkHEQFY1+g/om 9k0w== X-Gm-Message-State: APjAAAV2i9K7wCv1CZiMDxiGxftLGOjcuu0uwQ6VjzXOM2Q2NdZKAM21 nFy3Np+mpe5IPzUwmxj0UNZqznKt X-Google-Smtp-Source: APXvYqzD9eKiR7gu1dD3hcUpd9iNQ05I6VhrduqEEBHpNb+UTt9svGiYEoavLC05VlvLBYXCWGY/4g== X-Received: by 2002:a9d:6f8f:: with SMTP id h15mr5909982otq.1.1581445135283; Tue, 11 Feb 2020 10:18:55 -0800 (PST) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com. [209.85.210.47]) by smtp.gmail.com with ESMTPSA id g5sm1443428otp.10.2020.02.11.10.18.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2020 10:18:55 -0800 (PST) Received: by mail-ot1-f47.google.com with SMTP id 77so11067106oty.6; Tue, 11 Feb 2020 10:18:54 -0800 (PST) X-Received: by 2002:a9d:7f8d:: with SMTP id t13mr5842579otp.175.1581445134621; Tue, 11 Feb 2020 10:18:54 -0800 (PST) MIME-Version: 1.0 References: <202002111400.01BE0R3I009898@repo.freebsd.org> In-Reply-To: <202002111400.01BE0R3I009898@repo.freebsd.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Tue, 11 Feb 2020 10:18:43 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r357761 - head/sys/netinet To: Michael Tuexen Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48H9yS6wtlz4RMG X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 18:18:57 -0000 Hi Michael, On Tue, Feb 11, 2020 at 6:00 AM Michael Tuexen wrote: > > Author: tuexen > Date: Tue Feb 11 14:00:27 2020 > New Revision: 357761 > URL: https://svnweb.freebsd.org/changeset/base/357761 > > Log: > Use an int instead of a bool variable, since bool is not supported > on all platforms the stack is running on in userland. Maybe the platforms stuck in time before 1999 can be worked around with something trivial like: #if __STDC_VERSION__ < 199901L # warn Really really consider getting a new compiler typedef unsigned char _Bool; # define bool _Bool # define true ((_Bool)1) # define false ((_Bool)0) #endif Rather than inflicting the 80s on FreeBSD tree code? This commit seems like a step in the wrong direction and just for example, contravenes style(9). SCTP is already one of the buggiest areas of the kernel, and it can't be touched by outsiders for fear of breaking compatibility with the purported myriad other platforms it is also ported to. By transitive property, it also prevents modifying _any_ APIs SCTP consumes that happen to be implemented on other platforms. This hamstrings the kernel for what is obviously not functional code (throw a dart at a syzkaller report and better than 90% odds it's a SCTP panic), much less code a reasonable person would want to use in a security-sensitive context. If SCTP is intended to be a port from some legacy platform, perhaps it should live in ports rather than base? Thanks, Conrad