On 21 December 2011 18:03, Jonathan Wakely wrote:
> On 21 December 2011 02:00, Jim Avera wrote:
>> Ok, here is a patch which improves the example:
>>
>> --- gcc/doc/extend.texi.ORIG 2011-12-20 17:35:32.236578828 -0800
>> +++ gcc/doc/extend.texi 2011-12-20 17:37:10.460583316 -0800
>> @@ -7932,7 +7932,7 @@
>>
>> @smallexample
>> if (__builtin_expect (ptr != NULL, 1))
>> - error ();
>> + ptr->do_something();
>> @end smallexample
>>
>> @noindent
>
> In order to follow the GCC coding style (a space between the function
> name and opening parenthesis) and to match the first example for
> __builtin_expect, I propose this patch instead:
>
> Index: extend.texi
> ===================================================================
> --- extend.texi (revision 182452)
> +++ extend.texi (working copy)
> @@ -7932,7 +7932,7 @@ expressions for @var{exp}, you should us
>
> @smallexample
> if (__builtin_expect (ptr != NULL, 1))
> - error ();
> + ptr->foo ();
> @end smallexample
>
> @noindent
Then again, maybe foo (*ptr) would be even better, so it looks more
like C not C++ code.
> I've CC'd the gcc-patches list, which is where patches should be sent
> for review, and included a ChangeLog entry:
>
> 2011-12-21 Jonathan Wakely <[email protected]>
> Jim Avera <[email protected]>
>
> * doc/extend.texi (__builtin_expect): Improve example.
>
>
> Can I get approval to check this in to trunk?
>
>
>
>>
>>
>> ________________________________
>> From: Jonathan Wakely <[email protected]>
>> To: Segher Boessenkool <[email protected]>
>> Cc: [email protected]; [email protected]
>> Sent: Tuesday, December 20, 2011 5:22 AM
>> Subject: Re: Possible wrong-way example in gcc4-4-2 documentation of
>> __builtin_expect
>>
>> On 20 December 2011 12:49, Segher Boessenkool wrote:
>>>
>>> The point of the example is that you cannot write
>>>
>>> if (__builtin_expect (ptr, 1))
>>> error ();
>>>
>>> so the "!= NULL" is important here. But you are right that
>>> "error ()" is a bit unexpected; care to send a patch that changes
>>> it to e.g. "do_something ()"?
>>
>> or even ptr->do_something() since that would depend on the value of ptr
