Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #160091

Re: Which side of bitwise OR is evaluated first?

Show all headers | View raw

On 14/04/2021 09:51, Oğuz wrote:
> On Wednesday, April 14, 2021 at 10:42:47 AM UTC+3, David Brown wrote:
>> (Please try to get a proper newsreader and newsserver, rather than 
>> google groups - gg is particularly inconvenient when you have code 
>> snippets, making it hard to fix gg's broken formatting.)
>> On 14/04/2021 07:43, Oğuz wrote: 
>>> I wrote this: 
>>>
>>> fp = fopen(optarg, "r"); 
>>> if (!fp || (readfrom(fp), ferror(fp)|fclose(fp))) 
>>> perror(optarg) 
>>>
>>> `readfrom' is a function of type `void' that calls `getline' until 
>>> it returns -1. 
>>>
>> C guarantees that the left side of || and && is evaluated (including 
>> side-effects) first, and the right side is then evaluated only if 
>> necessary (depending on the first side). So the check of !fp first is 
>> safe. Similarly, the comma operator evaluates the left side first, then 
>> the right side. 
>>
>> Other operators, such as | and &, have no such rules. The evaluation of 
>> the left and right sides are unsequenced, meaning not only that their 
>> order of evaluation is not fixed, but the can be interleaved and it can 
>> vary between runs of the code. Thus the "ferror(fp)" and "fclose(fp)" 
>> can be done in any order - and the code can in theory do half of 
>> fclose() first, then ferror(), then the rest of fclose().
> 
> I had no idea. Thanks.
> 
>>> The reason why I wrote it this way is that I wanted to handle all 
>>> errors and close the file pointer in a single block.
>> Why?
> 
> Purely aesthetic reasons, nothing else. I like grouping related
> instructions in that manner, but it sometimes make the code a real mess.
> 
>>> But I'm not sure 
>>> if `ferror' is guaranteed to be called before `fclose' there, and the 
>>> standard says once `fclose' is called on `fp', what `ferror(fp)' will 
>>> do is unspecified or something like that. 
>>>
>>> So, should I change this or is it good (except being a bit 
>>> unreadable)? 
>>>
>> IMHO, you should change it /because/ it is unreadable. The fact that 
>> you need to ask if the ordering is correct is a sure sign that you have 
>> written it in a "smart-arse" manner that requires a lot of thought to 
>> see if it does the right thing. There may be exceptional circumstances 
>> dictating your needs here, but I would write this with generous use of 
>> named local variables holding the function returns (or flags indicating 
>> their success or failure), clear conditionals, and braces so that the 
>> flow of the code is absolutely obvious at a glance, and you are sure 
>> that the /apparent/ flow is the same as a the /actual/ flow.
> 
> Yeah, I'm now convinced that I should rewrite it that way. Thanks again.
> 

My personal preference is that if code relies on knowledge of language
details that some C programmers might have to look up or think about
carefully, then I would consider re-arranging it.  C has a set of rules
for operator precedence, and for order of evaluation, which are well
documented and clear.  However, they are not always easily memorised,
and it can be very difficult to see what complex expressions with mixed
operators actually do.  If it is not immediately clear at a glance, add
parenthesis or break it up into multiple parts.  Local variables cost
nothing.

The same applies to code flow.  People vary about their preferences, of
course, but I rarely like to have more than one piece of "do something"
code (such as function calls with side-effects) in the same expression.
 "foo(), bar();" may have the same effect as "foo(); bar();", but I
greatly prefer the second as clearer code, split on two lines.

Local variables are free.  Vertical space is free.  Brackets and
parenthesis are free.  Time taken to figure out if code really does what
you think it does, is not free.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Which side of bitwise OR is evaluated first? Oğuz <oguzismailuysal@gmail.com> - 2021-04-13 22:43 -0700
  Re: Which side of bitwise OR is evaluated first? Barry Schwarz <schwarzb@delq.com> - 2021-04-14 00:04 -0700
  Re: Which side of bitwise OR is evaluated first? David Brown <david.brown@hesbynett.no> - 2021-04-14 09:42 +0200
    Re: Which side of bitwise OR is evaluated first? Oğuz <oguzismailuysal@gmail.com> - 2021-04-14 00:51 -0700
      Re: Which side of bitwise OR is evaluated first? David Brown <david.brown@hesbynett.no> - 2021-04-14 11:25 +0200
    Re: Which side of bitwise OR is evaluated first? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-14 03:27 -0700
      Re: Which side of bitwise OR is evaluated first? David Brown <david.brown@hesbynett.no> - 2021-04-14 13:28 +0200
        Re: Which side of bitwise OR is evaluated first? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-04-14 10:31 -0700
          Re: Which side of bitwise OR is evaluated first? David Brown <david.brown@hesbynett.no> - 2021-04-14 19:40 +0200
    Re: Which side of bitwise OR is evaluated first? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-04-14 10:26 -0700
  Re: Which side of bitwise OR is evaluated first? Richard Damon <Richard@Damon-Family.org> - 2021-04-14 07:22 -0400
    Re: Which side of bitwise OR is evaluated first? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-04-14 07:54 -0700
    Re: Which side of bitwise OR is evaluated first? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-04-14 14:23 -0400
  Re: Which side of bitwise OR is evaluated first? scott@slp53.sl.home (Scott Lurndal) - 2021-04-14 14:33 +0000
    Re: Which side of bitwise OR is evaluated first? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-04-14 13:15 -0400
  Re: Which side of bitwise OR is evaluated first? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-04-14 08:06 -0700
    Re: Which side of bitwise OR is evaluated first? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-04-14 10:34 -0600
      Re: Which side of bitwise OR is evaluated first? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:24 -0700

csiph-web