musl - strcmp() guarantees and assumptions

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZLQnXpumUgwUmKhl@fuz.su>
Date: Sun, 16 Jul 2023 19:22:38 +0200
From: Robert Clausecker <fuz@....su>
To: musl@...ts.openwall.com
Cc: mjg@...ebsd.org
Subject: strcmp() guarantees and assumptions

Greetings,

I am currently developing SIMD-enhanced implementations of libc
functions for the FreeBSD libc.  One of the next functions I want to
tackle is strcmp().  There, the following question obtains:

    Is strcmp() permitted to assume that its arguments are NUL
    terminated strings?

Or to phrase it differently, is the following a legal implementation of
strcmp()?

    int strcmp(char *a, char *b) {
    	size_t la = strlen(a), lb = strlen(b);

    	if (la != lb)
    		return ((la > lb) - (lb > la));

    	return memcmp(a, b, la);
    }

A situation I dimly recall where this assumption did not hold was in a
program that used strcmp() to compare two buffers known to have a
mismatch somewhere, but without guaranteed NUL termination.  A naïve
strcmp() implementation processed this just fine, but this one might
crash.

I have previously asked the ISO/IEC 9899:2023 editor [1] who indicated
that he believes my interpretation to be correct, but asked me to look
for a second opinion.

Assuming that my assumption on strcmp() is correct, is this an
assumption common libc implementations make?  Or is it generally
agreed upon that libc implementations support strcmp() calls on
unterminated strings?

Thank you for your help.

Yours,
Robert Clausecker

[1]: https://twitter.com/__phantomderp/status/1680614038567354370

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.