Open Bug 497667 Opened 15 years ago Updated 2 years ago

Add a PR_GetEnv variant that returns NULL instead of an empty value string

Categories

(NSPR :: NSPR, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: sgautherie, Unassigned)

References

()

Details

Bug 306840 comment 24:
{
From  Serge Gautherie (:sgautherie)   2006-03-20 10:30:45 PDT

Would adding another function like "PR_GetEnv2()" which would call PR_GetEnv()
and filter out the null-string case, that clients/callers could decide to use
or not, be acceptable, or is it not the NSPR way either ?
}
I confirm that this is an RFE (:-)  but not that we're going to implement it.
(We may.)

After studying tons of material on this subject from Google, it appears to me
that all OSes that have environments allow environment variables to have empty
value strings.  They differ in the behavior that occurs when you call
   putenv("VAR=");
On most systems, that places (or replaces) a variable named VAR in the environment, giving it an empty value string.  But one SOME systems, that 
call will unset the variable VAR from the environment if it exists.  

Lots of software apparently assumes that the behavior will be to unset the 
variable, and when that software runs on a system where that is not the 
behavior, the result is lots of variables with empty values strings.  
(Why the code doesn't call unsetenv escapes me.)

To deal with these behavioral differences and be maximally portable, lots 
of software has taken to the practice of testing for environment variables
in a way that treats empty value strings the same as being not defined, e.g.
   char * foo = getenv("VAR");
   if (foo && *foo) {
       behave as if VAR is defined
   } else {
       behave as if VAR is undefined
   }

But Mozilla software has not yet widely adopted that latter practice.  
So, this bug requests that we implement a variant of PR_GetEnv that returns
NULL in the case where the value string is empty, e.g. 

const char *
PR_GetNonEmptyEnv(const char * name)
{
    const char * value = PR_GetEnv(name);
    return (value && *value) ? value : NULL;
}

I'm ambivalent about this suggestion.  
Wan-Teh, whast do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Add a |PR_GetEnv(char*, PRBool)| which (can) filters out a '\0' value → Add a PR_GetEnv variant that returns NULL instead of an empty value string
(In reply to comment #1)
> (Why the code doesn't call unsetenv escapes me.)

Note that, within NSPR, there is no "PR_UnsetEnv()".

Also
{
126 ** PR_SetEnv() -- set, unset or change an environment variable
...
132 **   string -- pointer to a caller supplied
133 **   constant, persistent string of the form name=value. Where
134 **   name is the name of the environment variable to be set or
135 **   changed; value is the value assigned to the variable.
}
advertise but does not explain how to _unset_ (for sure)...
Is this still needed?
(In reply to Marco Castelluccio from comment #3)
> Is this still needed?

Why not? I don't think anything has changed since this bug was filed.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: wtc → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.