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

Assigned to


9 years ago
6 years ago


(Reporter: sgautherie, Assigned: Wan-Teh Chang)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)





9 years ago
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
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?
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

Comment 2

9 years ago
(In reply to comment #1)
> (Why the code doesn't call unsetenv escapes me.)

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

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?

Comment 4

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.