APL\360

[Antonio Carlini]

On 30/01/2021 00:13, Guy Sotomayor via cctalk wrote:
> In a lot of industry standard coding practices (MISRA, CERT-C) that 
> type of statement is prohibited and *will* result in an error being 
> reported by the checker/scanner.
>
> The if statement in your example has at least 2 errors from MISRA's 
> perspective:
>
>  * assignment within a conditional statement
>  * the conditional not being a boolean type (that is you can't assume 0
>    is false and non-0 is true...you actually need to compare...in this
>    case against NULL)
>
>
> On 1/29/21 3:59 PM, Fred Cisin via cctalk wrote:
>> On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:
>>
>>> In the past (and occasionally today, I use the following construct:
>>>
>>> FILE *myfile;
>>>
>>> if ( !(myfile = fopen( filename, "r"))
>>> {
>>>  fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
>>>  exit (1);
>>> }
>>>
>>> Yes, it only saves a line, but neatly describes what's being done.
>>>
>>> --Chuck
>>
>> Yes.
>> That is another excellent example of where you DO want to do an 
>> assignment AND a comparison (to zero).  A better example than my 
>> strcpy one, although yours does not need to save that extra line, but 
>> a string copy can't afford to be slowed down even a little.
>>
>> That is why it MUST be a WARNING, not an ERROR.
>> Of course, the error is when that wasn't what you intended to do.
>>

I'm pretty sure that while modern compilers will correctly complain 
about an assignment in a conditional, they also recognise the idiom and 
don't warn when the extra set of brackets is present. So when you really 
do want an assignment and a conditional all in one go, you use the extra 
set of brackets and everyone (you, the compiler, future you) know that 
you really meant it.


Antonio


-- 
Antonio Carlini
antonio at acarlini.com