| 1 |
On Sun, 26 Jan 2014 12:43:37 -0800 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
> I don't buy that. The behavior appears to be currently undefined. |
| 4 |
> Changing it to different undefined behavior is allowed. |
| 5 |
|
| 6 |
The point of undefined behaviour is that anything that is relying upon |
| 7 |
undefined behaviour doing a particular thing is broken. PMS doesn't |
| 8 |
define what happens to XDG_*, so if your ebuilds need a particular |
| 9 |
thing done for it then they must be fixed. |
| 10 |
|
| 11 |
Perhaps PMS should be more explicit in stating this -- we lifted the |
| 12 |
concept of undefined behaviour from the C and C++ standards, and just |
| 13 |
assumed that people would know what it meant. Maybe we need a bit more |
| 14 |
text to clear up the misconception we see every now and again that |
| 15 |
"undefined" somehow means "it's ok to assume what some version of |
| 16 |
Portage happens to do, since the specification doesn't say you can't |
| 17 |
do that"... |
| 18 |
|
| 19 |
-- |
| 20 |
Ciaran McCreesh |
Archives