h ESMTPS id 44LE79Vd013036
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 21 May 2024 14:07:09 GMT
	(envelope-from saper@saper.info)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014;
	t=1716300429; bh=T+IZRG3NLlSVpVto76GAnwTgTHMqILyq0or0CdnEJ3I=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=iqIMSqPa+dAdd+V4B+pu3OCN4N05l4zDxQI34IeAewrlG9E5UTdkWpWOk6Fks9M4e
	 vN9kfi2v5Q9SZxJLVvxzdFkTfV6C1qRyJUPun8auT3VgDtri+PzmqgDThEpmtgNXDU
	 24oMsycV1JOnLjgEEeZcBznz0F75zkrtpuph5oOY=
Received: from localhost (saper@localhost)
	by q.saper.info (8.18.1/8.18.1/Submit) with ESMTP id 44LE797R013033;
	Tue, 21 May 2024 14:07:09 GMT
	(envelope-from saper@saper.info)
X-Authentication-Warning: q.saper.info: saper owned process doing -bs
Date: Tue, 21 May 2024 14:07:09 +0000
From: Marcin Cieslak <saper@saper.info>
To: Warner Losh <imp@bsdimp.com>
cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= <des@freebsd.org>,
        current@freebsd.org
Subject: Re: __memcpy_chk family of functions
In-Reply-To: <CANCZdfrMYu5L4np+0kiAJCMOEugAgVeY0N5Tm++OkFR8U9VY8Q@mail.gmail.com>
Message-ID: <18p47p63-5no5-p6r9-30rq-srpqpp196522@fncre.vasb>
References: <20qspnq2-8qp0-pq49-rq65-986n0q4r6rqq@fncre.vasb> <86msojvgfb.fsf@ltc.des.dev> <CANCZdfrMYu5L4np+0kiAJCMOEugAgVeY0N5Tm++OkFR8U9VY8Q@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US]
X-Rspamd-Queue-Id: 4VkGTb5Ff1z4Kf8

On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav <des@freebsd.org>
wrote:

> The purpose of UPDATING is to document changes that break backward
> compatibility, i.e. running old binaries on a newer world.
> happened here is that you tried to run newer binaries on an older world,

On Tue, 21 May 2024, Warner Losh wrote:

> Also, our forward compatibility guarantees are extremely weak.

Just for clarification: I am not complaining about my breakage.
It was my stunt and it didn't work out, I got punished by
sitting there and waiting for llvm to compile.

I think this (useful) change should go into the future release notes
as a new feature. Where and how should this be documented?
Shall FreeBSD_version be bumped for this one?

For example, when libsys got introduced, we could learn about
this from the UPDATING file. I do not want UPDATING to be come
unreadable or a copy of git log, though.

Marcin