All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] tools/nolibc/stdlib: fix getenv() with empty environment
Date: Wed, 16 Oct 2024 14:17:08 +0200	[thread overview]
Message-ID: <Zw+uxLIklMHSSxTu@1wt.eu> (raw)
In-Reply-To: <20241016-nolibc-getenv-v1-1-8bc11abd486d@linutronix.de>

Hi Thomas!

On Wed, Oct 16, 2024 at 01:14:51PM +0200, Thomas Weißschuh wrote:
> The environ pointer itself is never NULL, this is guaranteed by crt.h.
> However if the environment is empty, environ will point to a NULL
> pointer.

Good point, however from what I'm seeing on glibc, if the user sets
environ to NULL, getenv() safely reports NULL and doesn't crash. I
don't know what the spec says about environ being NULL, though. I
just tested on freebsd to compare and also get a NULL in this case
as well. So I'd be tempted by keeping the check.

>  	int idx, i;
>  
> -	if (environ) {
> +	if (*environ) {
>  		for (idx = 0; environ[idx]; idx++) {
>  			for (i = 0; name[i] && name[i] == environ[idx][i];)
>  				i++;

However as a quick note, if we decide we don't care about environ being
NULL, and since this is essentially a cleanup, why not even get rid of
the whole "if" condition, since the loop takes care of it ?

FWIW I tested glibc with this:

  #include <stdlib.h>


  int main(int argc, char **argv)
  {
        extern char **environ;

        environ=NULL;
        return getenv("HOME") == NULL;
  }

Cheers,
Willy

  reply	other threads:[~2024-10-16 12:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-16 11:14 [PATCH] tools/nolibc/stdlib: fix getenv() with empty environment Thomas Weißschuh
2024-10-16 12:17 ` Willy Tarreau [this message]
2024-10-16 13:01   ` Thomas Weißschuh
2024-10-16 14:49     ` Willy Tarreau

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=Zw+uxLIklMHSSxTu@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=paulmck@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.