Remove undefined behavior from safe_strerror_posix.cc

Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589
Committed: https://crrev.com/36e38a244f1292bc22c94d0ab13f300fda124cef
Cr-Commit-Position: refs/heads/master@{#369872}

[Nico, 2016-01-14 14:43:50]

thakis@chromium.org changed reviewers:
+ brettw@chromium.org

[Nico, 2016-01-14 14:43:50]

imho it's very surprising and annoying that this is undefined behavior, but
since compilers do have different behavior on this in practice…

[Nico, 2016-01-14 14:44:22]

Description was changed from

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=none
==========

to

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=none
==========

[Nico, 2016-01-14 18:20:44]

Description was changed from

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=none
==========

to

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589
==========

[brettw, 2016-01-15 21:18:48]

lgtm

[Nico, 2016-01-15 21:19:53]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2016-01-15 21:20:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1584203002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1584203002/1

[commit-bot: I haz the power, 2016-01-15 22:49:45]

Description was changed from

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589
==========

to

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589
==========

[commit-bot: I haz the power, 2016-01-15 22:49:46]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-15 22:50:37]

Description was changed from

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589
==========

to

==========
Remove undefined behavior from safe_strerror_posix.cc

[cpp.cond]p4:
  Prior to evaluation, macro invocations in the list of preprocessing
  tokens that will become the controlling constant expression are replaced
  (except for those macro names modified by the 'defined' unary operator),
  just as in normal text. If the token 'defined' is generated as a result
  of this replacement process or use of the 'defined' unary operator does
  not match one of the two specified forms prior to macro replacement, the
  behavior is undefined.
This isn't an idle threat, consider this program:
  #define FOO
  #define BAR defined(FOO)
  #if BAR
  ...
  #else
  ...
  #endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch.

This works fine in this file since it's not built on Windows, but relying
on that seems a bit risky.

(I'm prototyping a compiler warning for this -- not sure yet a compiler warning
is worth it, but fixing this file is.)

No behavior change.

BUG=428589

Committed: https://crrev.com/36e38a244f1292bc22c94d0ab13f300fda124cef
Cr-Commit-Position: refs/heads/master@{#369872}
==========

[commit-bot: I haz the power, 2016-01-15 22:50:37]

Patchset 1 (id:??) landed as
https://crrev.com/36e38a244f1292bc22c94d0ab13f300fda124cef
Cr-Commit-Position: refs/heads/master@{#369872}