Deutsch   English   Français   Italiano  
<874j9ns382.fsf@bsb.me.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Thu, 20 Jun 2024 22:39:57 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <874j9ns382.fsf@bsb.me.uk>
References: <v494f9$von8$1@dont-email.me> <20240613002933.000075c5@yahoo.com>
	<v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
	<v4okn9$flpo$2@dont-email.me> <20240617002924.597@kylheku.com>
	<v4pddb$m5th$1@dont-email.me> <20240618115650.00006e3f@yahoo.com>
	<v4rv0o$1b7h1$1@dont-email.me> <20240618184026.000046e1@yahoo.com>
	<v4sd75$1ed31$1@dont-email.me>
	<877celzx14.fsf@nosuchdomain.example.com>
	<v4u85k$1t2pu$2@dont-email.me> <v4ucmn$1u14i$1@dont-email.me>
	<v4v2br$22c0m$1@dont-email.me> <v4v5nu$230rh$2@dont-email.me>
	<v4vfrn$24rv6$1@dont-email.me> <v50n9s$2fkko$1@dont-email.me>
	<v50poh$2g4ha$1@dont-email.me> <87iky3svqh.fsf@bsb.me.uk>
	<874j9nxsdy.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 20 Jun 2024 23:39:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5613304b27b832cdc5fb7680d1fb5c1d";
	logging-data="2905524"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19gm4HhxY4lIOkYG757DSGwOiET+os6MoY="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:xZOa8Jx/tD2KsdvlONKCrAGUfss=
	sha1:TQ+sk55tiMfZPG0KSFqKljNo1VQ=
X-BSB-Auth: 1.f64ae9b3a892ebc4ea49.20240620223957BST.874j9ns382.fsf@bsb.me.uk
Bytes: 3155

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben@bsb.me.uk> writes:
> [...]
>> On a C language point, I don't think the standard says anything about
>> sorting with non-order functions like the one above.  Is an
>> implementation of qsort permitted to misbehave (for example by not
>> terminating) when the comparison function does not implement a proper
>> order relation?
>
> N1570 7.22.5p4 (applies to bsearch and qsort):
> """
> When the same objects (consisting of size bytes, irrespective of
> their current positions in the array) are passed more than once to
> the comparison function, the results shall be consistent with one
> another. That is, for qsort they shall define a total ordering on
> the array, and for bsearch the same object shall always compare
> the same way with the key.
> """
>
> That's a "shall" outside a constraint, so violating it results in
> undefined behavior.

I think it should be clearer.  What the "that is" phrase seems to
clarify in no way implies a total order, merely that the repeated
comparisons or the same elements are consistent with one another.  That
the comparison function defines a total order on the elements is, to me,
a major extra constraint that should not be written as an apparent
clarification to something the does not imply it: repeated calls should
be consistent with one another and, in addition, a total order should be
imposed on the elements present.

-- 
Ben.