On Mon 2019-06-24 20:02:13 -0700, William Casarin wrote:
> dkg wrote:
>> +    if ((protected_headers = g_mime_object_get_header_list (payload), protected_headers) &&
>> +	(legacy_display = GMIME_TEXT_PART (first), legacy_display) &&
>> +	(legacy_display_header_text = g_mime_text_part_get_text (legacy_display), legacy_display_header_text) &&
>> +	(stream = g_mime_stream_mem_new_with_buffer (legacy_display_header_text, strlen (legacy_display_header_text)), stream) &&
>> +	(g_mime_stream_write (stream, "\r\n\r\n", 4) == 4) &&
>> +	(g_mime_stream_seek (stream, 0, GMIME_STREAM_SEEK_SET) == 0) &&
>> +	(parser = g_mime_parser_new_with_stream (stream), parser) &&
>> +	(legacy_header_object = g_mime_parser_construct_part (parser, NULL), legacy_header_object) &&
>> +	(legacy_display_headers = g_mime_object_get_header_list (legacy_header_object), legacy_display_headers)) {
>> +	/* walk through legacy_display_headers, comparing them against
>
> This may be a noob question, but why the comma operators after the
> assignment expressions? Wouldn't they evaluate to the same thing?

Yes, they do evaluate to the same thing.

But A sensible compiler will warn when it sees "if (foo = bar)" because
most people who write that actually mean "if (foo == bar)".

So using the comma operator signals to the compiler "yes, I meant to
test the result of this particular assignment, and it is not just a
buggy attempt at a comparison".

     --dkg

PS if you leave out the comma, gcc's actual warning with -Wall is
   disappointingly opaque:

    warning: suggest parentheses around assignment used as truth value [-Wparentheses]

   This suggests that you could also work around it by using a construct
   like"if ((foo = bar))".  But i think that is harder to read, and
   doesn't really describe what the intent is as well.

   As Hal Abelson said, "Programs must be written for people to read,
   and only incidentally for machines to execute."