getenv and carriage returns

[Chad Paquette]

Hi,
We have a legacy cgi app that's written in C. We are encountering
an error when we try to retrieve a cgi environment variable. The
variable we are getting contains a Base64 encoded distinguished name.
If the distinguished is greater than 57 characters in length, a
carriage return is appended to the 58th character. This of course
causes the Base64 decoder to bomb because a carriage return is not a
valid Base64 character. We are using the getenv() function. Is there
some sort of limit on the size of string getenv can return without
placeing a CR?

Any help would be appreciated.

Thanks

Chad

 

[Martin Dickopp]

We have a legacy cgi app that's written in C. We are encountering
an error when we try to retrieve a cgi environment variable. The
variable we are getting contains a Base64 encoded distinguished name.
If the distinguished is greater than 57 characters in length, a
carriage return is appended to the 58th character. This of course
causes the Base64 decoder to bomb because a carriage return is not a
valid Base64 character. We are using the getenv() function. Is there
some sort of limit on the size of string getenv can return without
placeing a CR?

No. `getenv' just returns whatever is provided by the host enviroment;
it never modifies it in any way.

Most likely, whatever sets the envrionment variable (the web server?)
already sets it to a string which contains the carriage return
character.

Martin

 

[Kenneth Brody]

Hi,
We have a legacy cgi app that's written in C. We are encountering
an error when we try to retrieve a cgi environment variable. The
variable we are getting contains a Base64 encoded distinguished name.
If the distinguished is greater than 57 characters in length, a
carriage return is appended to the 58th character. This of course
causes the Base64 decoder to bomb because a carriage return is not a
valid Base64 character. We are using the getenv() function. Is there
some sort of limit on the size of string getenv can return without
placeing a CR?

This is off-topic for c.l.c, but...

getenv() isn't modifying the string. If it's returning a string with
CRs in it, it's because CRs are in the environment variable's value.

As for your decoder bombing on this, your decoder is broken. You are
supposed to skip whitespace, as I understand it. Reread the specs.

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

 

[nrk]

Hi,
We have a legacy cgi app that's written in C. We are encountering
an error when we try to retrieve a cgi environment variable. The
variable we are getting contains a Base64 encoded distinguished name.
If the distinguished is greater than 57 characters in length, a
carriage return is appended to the 58th character. This of course
causes the Base64 decoder to bomb because a carriage return is not a
valid Base64 character. We are using the getenv() function. Is there
some sort of limit on the size of string getenv can return without
placeing a CR?

Any help would be appreciated.

No, getenv shouldn't be imposing such any limits, other than the
implementation limits. Keep in mind that you shouldn't try to modify the
string pointer returned by getenv.

<OT>
Looks like its your base64 decoder that's broken. base64 encoding means
lines of 76 characters or less (and yes, you can insert a line break at 58
if you desire). Your decoder should ignore line breaks and other
whitespace and any other character not part of the base64 encoding
(although you should flag an error in the last case). Even if you find the
problem elsewhere, considering you are using it in a CGI environment, I
would fix the decoder to be RFC 1521 compliant.
</OT>

-nrk.

 

[Peter Nilsson]

... `getenv' just returns whatever is provided by the host enviroment;
it never modifies it in any way.

Do you have chapter and verse on that?

From a C89 draft...

"The getenv function searches an environment list, provided by the
host environment, for a string that matches the string pointed to
by name . The set of environment names and the method for
altering
the environment list are implementation-defined."

Of course, it rather depends on what you mean by 'modify', but the
getenv function certainly doesn't return the entire 'environment list'
(whatever that may be); it has to perform _some_ sort of translation.
What that translation is isn't specified by the standard.

But consider if the 'environment list' is stored in unicode, in that
case a getenv function may have to modify the result for characters
not representable by char objects.

 

[Martin Dickopp]

Do you have chapter and verse on that?

C99 7.20.4.5#2, which is the same as the text you quoted.

From a C89 draft...

"The getenv function searches an environment list, provided by the
host environment, for a string that matches the string pointed to
by name. The set of environment names and the method for altering
the environment list are implementation-defined."

IMHO, the "provided by the host environment" part means that if the host
evironment doesn't already impose a requirement that environment strings
must contain certain characters at certain points, the C implementation
is not allowed to insert such characters (as the OP was suspecting might
be happening). There is certainly no requirement in the C language that
strings must contain a carriage return character after the inital 58
characters.

Of course, it rather depends on what you mean by 'modify', but the
getenv function certainly doesn't return the entire 'environment list'
(whatever that may be);

Conceptually, the environment list is a list of key-value-pairs (that
follows from the "a string that matches the string" part and the
statement "The getenv function returns a pointer to a string associated
with the matched list member." in paragraph #4, IMHO). The `getenv'
function just returns a value-item from the list.

it has to perform _some_ sort of translation.

I don't see why. In fact, there is at least one implementation where
the environment list is passed to the program as a consecutive list of
('\0' terminated) strings followed by an empty string. Each string
contains at least one '=' character; everthing up to, but not including,
the first '=' character is the key, and everything following it is the
associated value.

In this implementation, no translation of any kind is performed; the
`getenv' function simply returns a pointer to the character after the
'=' character.

Martin