Environment variable issue

Adrian Sendroiu molecula2788 at gmail.com
Mon Aug 19 22:47:05 CEST 2013


Marc Lehmann <schmorp at schmorp.de> writes:

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

I don't expect anything for the invalid entries. I expect valid entries
to remain valid.

> Try it with your root inode/allocation table/directory entries and be
> surprised...
>
> 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.

For the filesystem example that would mean that the entire data is still
there, even if you corrupt the /usr's inode. Whether it is visible or
not it's not relevant for this analogy. A filesystem is a more complex
structure, with various links between items. There is no connection
between environment entries.

Unfortunately, not even the "the data is still there" assertion holds
in this case. You pass 100 valid entries and 1 invalid entry and end up
with 101 invalid entries. This sounds like corrupting the majority of
the data to me. Especially when there should be no relation between
those items.




More information about the rxvt-unicode mailing list