mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Robert Clausecker <>
Subject: [musl] strcmp() guarantees and assumptions
Date: Sun, 16 Jul 2023 19:22:38 +0200	[thread overview]
Message-ID: <> (raw)


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

    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

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.

Robert Clausecker


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

             reply	other threads:[~2023-07-16 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-16 17:22 Robert Clausecker [this message]
2023-07-16 17:49 ` NRK
2023-07-16 17:59   ` Robert Clausecker
2023-07-16 19:24     ` Pedro Falcato
2023-07-16 19:29       ` Pedro Falcato
2023-07-16 19:33     ` Markus Wichmann
2023-07-16 21:13       ` Robert Clausecker
2023-07-17 16:22         ` Adhemerval Zanella Netto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).