> > + int user_key =
> > +((opt & (1 << (USER_BITS - 1))) ? ~USER_MASK : 0) | (opt &
> > USER_MASK);
>
> Yes, thanks, that's simpler than what is there now, and (in theory at least)
> is
> more portable.
OK, pushed.
Bruno Haible wrote:
+ int user_key =
+((opt & (1 << (USER_BITS - 1))) ? ~USER_MASK : 0) | (opt & USER_MASK);
Yes, thanks, that's simpler than what is there now, and (in theory at least) is
more portable.
> The intended operation (in terms of bits) is:
>
> z...abcdefghijklmnopqrstuvwx
> ->abcdefghijklmnopqrstuvwx
Correction: It is like this:
abcdefghijklmnopqrstuvwx
->abcdefghijklmnopqrstuvwx
Bruno
Hi Paul,
> > The message "Saw a #BR!" is a bit cryptic
> > Does someone understand this argp-help.c code?
>
> I didn't, but after looking at the code for a bit I see a problem that
> could explain the symptoms you observe. hol_append subtracts pointers
> into different arrays, which has undefin
On 05/19/2017 08:27 AM, Bruno Haible wrote:
The message "Saw a #BR!" is a bit cryptic
An understatement to be sure. In my experience, even when you know
exactly which machine instruction is trapping and know which source-code
statement it corresponds to, it's often tricky to puzzle out why a
Here are the results of running a gnulib testdir with
CFLAGS="-O -ggdb -fcheck-pointer-bounds -mmpx"
on Linux/x86_64.
The interesting finding is in test-argp-2.sh. The message
"Saw a #BR!" is a bit cryptic, but is explained in
https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryPr
