Environment variable issue

Marc Lehmann schmorp at schmorp.de
Mon Aug 19 20:09:12 CEST 2013

On Mon, Aug 19, 2013 at 05:31:10PM +0300, Adrian Sendroiu <molecula2788 at gmail.com> wrote:
> > or accessible by normal means. That expectation assumes that corrupting
> > data has no effect on other data that hasn't been corrupted, which
> > generally isn't the case.
> I don't see this as a comparable example. This would be equivalent
> with "randomly corrupting the RAM and then expecting the environment
> to be preserved", which is clearly an invalid assumption.

It's a comparable example to the env variable corruption example I gave.
> But in our case we're not talking about raw data. The environment has,
> after all, a relatively structured form, an array of entries. I don't
> see why an error in one entry should propagate into every other.

The inability to see is fine, but that doesn't mean expectations of
specific semantics for those invalid entries are in any way reasonable.

> If you corrupt one inode in the filesystem, the large majority of the
> rest still remains intact right?

Try it with your root inode/allocation table/directory entries and be

However, "majority" is a red herring - we are not talking about corrupting
the majority of the data, but about passing in corrupted data and
expecting that to be interpreted in a specific way. For the filesystem
example, that would mean /usr is corrupted but the directories inside are
still visible.

The only reasonable solution is to not corrupt the data in the first
place, rather than having an expectation of another program guessing whats
wrong and fixing it.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

More information about the rxvt-unicode mailing list