> Allright, enough, seems I should reply again, since Patrik
> has obviously
> blown his case of heuristics out of proportion in his
> fruitless attempts
> to rationalize, motivate, and defend his ludicruous argument,
> keeping his
> signal/noise ratio at an all-time low no matter how
> irrelevant and silly I
> kept telling him that treating this excuse as a legitimate issue is.
Heuristics haven't really much to do with the problem at hand
I just used to word to try to communicate fact the fact that
I had read somewhere that somebody claimed that GNU C at higher
optimization levels sometimes tries to be _too_ clever.
This attempt obvious failed and the allegation might not even
be true, I don't know. However now I have explain what I meant.
> I did not reply to this before because *I* strive to be a
> rational person,
> which means following Socrates's advice: if the person you're
> discussing
> with is, despite numerous attempts, incapable of rational
> thought, then
> the best thing to do is to stop wasting your time, simply get up and
> leave, everyone would be better off - even if the left-behind
> party keeps
> insulting your back, there's nothing that staying would
> rectify anyway.
Well, _you_ insulted me first. I you hadn't done that I probably
had dropped the subject as well, but your insults made it impossible
for me to do that.
I wonder what Socrates said about insulting people?
> I only have to refer to facts - the macro WINE_UNUSED, expanding to
> __attribute__((unused)), is spread all over the Wine .h
> files, as a simple
> grep can tell.
Speaking of facts, you missed the fact that all use in Wine of
__attribute__((unused)) in the header files is combined with
the use of inline of which I never proposed a change in
semantics for.
The few in the .c files can easily be fixed if we really want
to save a few extra bytes with a potential future compiler that
uses my suggested semantics.
> Obviously because otherwise Wine would get all sorts of
> unused warnings - at least in earlier gcc versions (probably 2.7.2).
> And there are the docs, which states exactly what the
> attribute does do.
Sure, it suppresses the warnings. I never said it shouldn't do that.
That was not something we argueed about.
> When Patrik has neither checked nor been deterred by such facts in his
> quest to eliminate established 'de-facto' semantics he doesn't like in
> vital infrastructure components such as compilers, and prefer to put
Sure compilers are vital, byt what will happend at worst will be a
few extra bytes larger executable and this can always, as I explained,
quite easily be fixed by people who _really_ care.
> forward irrelevant, marginal, and illogically backed issues
> (applying his
> own personal definition of "heuristics" to gcc docs to prove
> gcc buggy)
I never used "heuristics" to prove GNU C was buggy.
You just blow my admittedly ambigeuous statement
out of all proportions.
Read what I have written and try again. Or don't,
it was no relevance to Wine or whether GNU C should
changed at all.
I have claimed that GNU C ignores constrains that it probably
should have taking in account. This might been intentional
but that still doesn't make it set in stone for all times to
come.
> to
> defend his stance, what can I do? I just go away, of course,
> point out why
> (maybe coming across as "because he doesn't think"), and if he becomes
> disappointed by my lack of further objective response, too
> bad for him,
> and forging my 'departure reason' into a weapon against me
> isn't going to
> do much good for him. So that's what happened. Live with it.
You haven't _really_ read what I have written, have you?
In any case you certainly haven't understood it.
> EOD from here. (And the technical issue was solved by
> Alexandre anyway.)
Yes, I noticed that. Regardless of whether GNU C is changed in
the future we are probably forced to do it somehow like that
way because of compabillity reasons.
The _only_ reason I didn't drop the subject was that your
insults _forced_ me the respond.
