| 1 |
On Thu, Sep 20, 2012 at 2:13 PM, Pacho Ramos <pacho@g.o> wrote: |
| 2 |
> El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió: |
| 3 |
>> On Thu, 20 Sep 2012 19:54:43 +0200 |
| 4 |
>> Pacho Ramos <pacho@g.o> wrote: |
| 5 |
>> > That isn't necessary what could occur if the behavior changes |
| 6 |
>> > unexpectedly: as current behavior is already being assumed in |
| 7 |
>> > eclasses/ebuilds, portage couldn't change it without, before, porting |
| 8 |
>> > ebuilds/eclasses to use that new hypothetical behavior. |
| 9 |
>> |
| 10 |
>> Sure it can. Portage supports what's in the spec. If you're relying |
| 11 |
>> upon undefined behaviour, it's your problem when it stops working. |
| 12 |
>> |
| 13 |
> |
| 14 |
> It cannot break the tree, only square-headed people can think somebody |
| 15 |
> would force a breakage and don't try to fix it before. |
| 16 |
|
| 17 |
Isn't this why there are stable and unstable versions of PMs? And why |
| 18 |
we have things like 'undefined behavior' in language specs? And why |
| 19 |
depending on them is considered a bad thing? At least in the C world, |
| 20 |
it's considered within the compiler's rights to take a UB dependency |
| 21 |
in your code and stick in a routine to play salsa music in an infinite |
| 22 |
loop while driving your laptop's hard drive to dance across the table. |
| 23 |
(More frequently, it just omits the code entirely, but that's |
| 24 |
typically less amusing.) |
| 25 |
|
| 26 |
If I'm writing a PM, and I have to make sure my code conforms to some |
| 27 |
condition, something static like a spec is the only thing I can really |
| 28 |
depend on. If I use "does this break anything in the tree" as a test, |
| 29 |
then I have to re-test every time some someone makes a change to the |
| 30 |
tree, in case someone stumbled into more undefined behavior that works |
| 31 |
for the PM they test against, but not for mine. And there's no |
| 32 |
guarantee somebody else won't commit a different breaking UB-dependent |
| 33 |
change to the tree in the two hours I spent changing my code to act |
| 34 |
more like the one they're testing against--assuming they even tested |
| 35 |
correctly! |
| 36 |
|
| 37 |
On the other hand, if there's a spec document, I can say "that ebuild |
| 38 |
is depending on undefined behavior," and then come to an agreement |
| 39 |
whether the ebuild needs to be changed, or whether the behavior needs |
| 40 |
to be defined. And if the behavior is defined, then either my PM code |
| 41 |
or the ebuild code changes to conform. |
| 42 |
|
| 43 |
This sounds exactly like a classic "de jure" vs "de facto" standards |
| 44 |
debate...and "de facto" really only works well when the number of |
| 45 |
implementations that need to conform with each other is very |
| 46 |
small--ideally one. |
| 47 |
|
| 48 |
-- |
| 49 |
:wq |
Archives