On 08/09/2016 10:44 PM, Andrei Borzenkov wrote:

10.08.2016 05:55, David C. Rankin пишет:

...

...

/usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’ extern int pthread_cond_wait (pthread_cond_t *__rdstrict __cond, Is it really __rDstrict? It is suposed to be __rEstrict.

...

Yes, really is...

...

...

(side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with

G_PARAM_DEPRECATED = 1 << 31

which is definitely not an 'int' constant [by +1])

What it is? Floating point? String?

INT_MAX = (1 << 31) - 1; Evidently the shifts 0-30 were used and instead of finding some nice number in the range of int, they just shifted by 31 and left it. The solved part of the response can be chocked up to a big "I have no clue what was broke", but `zypper up -r update` pulled in an update for pcre-tools, and attempting the build again -- worked fine. So all is well again. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Aug 10, 2016 at 12:44 AM, David C. Rankin wrote:

Andrei correctly pointed out the __rDstrict v. __rEstrict strangeness in error reporting. pthread.h was in fact correct:

That's only a 1-bit flip error. That happens on rare occasion in ram. If you can't reproduce it on a different machine, I'd say you have a hardware issue (or were the unlucky recipient of a cosmic ray). Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Aug 10, 2016 at 6:55 AM, David C. Rankin wrote:

...

...

...

(side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with

G_PARAM_DEPRECATED = 1 << 31

which is definitely not an 'int' constant [by +1])

What it is? Floating point? String?

INT_MAX = (1 << 31) - 1;

Note that in C90 this is implementation defined. Further standards explicitly call this undefined behavior. GCC documentation on implementation defined aspects: --><-- o The results of some bitwise operations on signed integers (C90 6.3, C99 and C11 6.5). Bitwise operators act on the representation of the value including both the sign and value bits, where the sign bit is considered immediately above the highest-value value bit. Signed ‘>>’ acts on negative numbers by sign extension. GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined, but this is subject to change. --><-- [I admit to not full understand the last sentence being non-native English speaker, but I take it as "the behavior is not undefined"] And if you look at generated assembly, this expression is replaced by -1 integer constant which is pretty much legal in this context. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org