bug#40226: sort: expected sort order when -c in use

[Richard Ipsum]

On Wed, Mar 25, 2020 at 01:17:19PM -0500, Eric Blake wrote:
> On 3/25/20 12:37 PM, Richard Ipsum wrote:
[snip]
> 
> See the difference?  In the first case, sort is doing its default
> case-insensitive comparison of the entire line (because you passed -f but
> not -k), AND a stability comparison of the byte values of the entire line
> (as shown by the two ____ lines per input).  But in the second case, when
> you add -s, the stability comparison is omitted.  The two lines are indeed
> different when the stability comparison is performed, explaining why -c
> choked when -s is absent.  Or put another way, -f affects only -k, including
> the implied -k1 when you don't specify anything, and not -s.  So now that we
> know that, let's return to your example:

I'm trying to understand this relative to POSIX, which makes no mention
of stability as far as I can see (and there is no -s in POSIX). POSIX
says that -f should override the default ordering rules. I don't
understand why the last-resort comparison is required when -c is in use,
since we're not sorting with -c, just checking if the input is already sorted?

Put another way should -c imply -s ?

Thanks,
Richard