►
From YouTube: C/C++ Compiler Options Best Practices (April 12, 2023)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
All
right,
I'll
put
a
link
to
the
Google
Docs
with
the
meeting
notes
in
the
meeting
chat.
So
please
record
please
record
if
you're
present
in
the
table,
do
we
have
anyone
who
would
be
willing
to
make
notes.
D
A
D
Hello,
I'm
not
sure
if
I've
been
on
previous
calls,
but
yeah
hello,
I'm,
Jack,
I
work
at
control,
plane,
I
have
an
interest
in
in
building
software
I'm
familiar
with
some
of
the
hardening
steps
that
we
take
in
next
packages,
where
we
build
a
bunch
of
software
and
I.
Just
want
to
double
check
for
everything.
We've
got
is
in
this
document,
and
everything
in
the
document
is
also
added
to
to
what
we've
got
so
yeah
nice
to
meet.
You.
A
Nice
to
meet
you
too
and
welcome
you
were
also.
You
were
also
commenting
on
some
of
these
open
pull
requests
right
earlier.
Yes,.
D
A
So
what
I
would
so?
What
I
would
actually
suggest
that
we
have
a
number
of
these
open,
open,
pull
request
and
I
think
it
would
be
like
a
good
to
check
in
on
the
status
of
those
I
had
a
quick
look
through
them
yesterday
and
try
to
make
some
notes
into
the
into
the
agenda,
but
also,
if
anyone
has
any
other
opens,
they
want
to
record.
Please
go
ahead
and
note
them
in
today.
A
Note
them
into
the
meeting
notes,
but
I
I
thought
that
we
could
maybe
sort
of
really
coldly
just
go
through
this
pull
requests
in
like
the
order
they
were
submitted
and
see
how
we
are
how
we
are
on
doing
I
think
we
had.
We
had
the
changes
related
to
the
changes
related
to
the
the
now.
My
now
my
brain
is
brain
is
escaping
me.
A
I
just
came
from
cheering
another
two-hour
Workshop,
so
I
getting
reclamatized,
but
we
got
the
the
pull
request
from
cdash
merged
from
last
week
on
the
on
some
of
the
some
of
the
hardening
options,
and
then
we
have
then
what
we
also
had
this
number
128,
which
was
the
G
lib
cxx
assertions,
option
that
was
initially
submitted
by
David
and
I.
A
Did
some
suggestions
in
a
separate
pull
requests
number
142
to
sort
of
bring
this
section
aligned
so
that
we
provide
the
corresponding
information
both
for
the
GCC
provided,
C
plus
plus
standard
Library
and
the
llvm
standard
library
implementations?
But
maybe
like
one
of
my
concerns
where
that
I
I
hope
that
I
didn't
sort
of
broaden
the
scope
of
this
unnecessarily.
But
maybe
you
can
give
your
impressions
David
on
how
you
feel
about
how
you
feel
about
the
state
of
state
of
this.
A
Should
I
should
I
pull
up?
This
should
I
pull
up
this
full
request
and
we
can
have
a
week.
A
A
So
I
I
think
that
I
think
that
the
background
for
this
was
basically
this
in
your
original.
In
your
original
pull
request,
we
had
this
offline
discussion
about
whether
this
is
when
this
feature
was
added
to
GCC
and
whether
it
when
it
was
added
to
added
to
see
Lang,
but
because
this
is
like
a
this
is
effectively
like
a
macro
definition.
That's
passed
to
the
underlying
underlying
C
plus
plus
standard
Library
header
I.
A
A
A
Do
on
some
additional
suggestions,
which
we
can
also
also
go
through,
but
I
can
sort
of
briefly
give
a
briefly
note:
the
changes
that
I
I
did
first,
so
the
first
commit
basically
adds
these
so
change
the
attribution
for
this
not
for
Jesus
young
Clan,
but
basically
call
out
the
best,
TDC,
plus
plus
and
lib
C,
plus
plus
with
the
corresponding
versions,
and
then
add
the
leadership
PPP
assert
option
both
into
the
main
table
and
then
this
and
then
the
sort
of
the
Feature
Feature,
specific
description
and
I
sort
of
had.
A
Then
then
the
then
this
sort
of
that
other
other
change
I
was
proposing,
which
is
also
on
the
which
is
the
other
commit
here.
Is
that
a
lot
of
the
a
lot
of
the
documentation
around
this?
They
don't
call
this
out
a
specifics,
runtime
bounce
checking
for
C
plus
plus
strings,
but
they
talk
about
this
precondition
checks
and
what
how
it
seems
to
be
like
for
this
llvm.
A
They
specifically
only
use
this
for
constant
time
precondition
checks
which
proposed
at
least
for
or
suppose
at
least
for
performance
reasons,
whereas
then
for
this
gccs
I
think
it's
a
little
bit
more
complex
and
I
think
it's
also
like
in
both
cases.
This
has
also
evolved
over
time.
A
So,
but
but
basically
the
synopsis
and
then
the
performance
implications
have
been
sort
of
restructured
based
on
based
on
that
it
covers
the
covers.
Both
cases
like
like
one
thing
that
I
was
a
little
bit
sort
of
I
I
was
sort
of
going
a
bit
back
and
forth.
In
my
mind,
was
that
so
also
like
this
note
here
in
the
main
table
that
can
impact
performance
and
I,
wonder
that
we
have
like
a
lot
of
options
that
can
potentially
impact
performance.
A
So
I
wonder
that
if
we
list
it
in
like
the
main
table,
is
that
at
least
now
we
are
not
doing
it
consistently.
So
I
guess
this
is
sort
of
at
least
one
something
that
I
wanted
to
brought
up
that
do.
We
feel
it's
necessary
to
point
this
out
for
specific
options
and
in
in
that
case,
what
that,
like?
What
criteria
do
we
use,
or
are
we
happy
with
just
having
the
performance
implication
section
for
each
of
them
and
sort
of
like
deferring
to
description
description?
There.
F
As
the
CPU
guy
in
the
room,
we
are
constantly
asked
about
performance
and,
if
there's
ever
any
trade-offs,
so
I
would
recommend
that
this
group
consider
adding
that
could
impact
performance.
Qualifier
I
think
that's
important
to
note
for
people,
because
we
get
a
ton
of
questions
about
that.
F
I
I
think
if
we
know
and
it's
you
know,
approvable
I
think
we
definitely
should
provide
that
feedback
for
people
as
they're
kind
of
weighing
their
their
options.
A
G
Yeah
I
I
would
say
you
know,
I
I
would
agree,
I
agree
with
probe
and
I
would
say
the
details
go
into
the
performance.
You
know
into
that
section.
Performance
announcement
there's
no
way.
You
can
summarize
that
in
a
high
level
table
but
having
you
know,
Canon
pack
performance
on
and
then
all
the
details
down
below
I
seems
like
the
right
call.
G
You
know
unless
it's
like
you
know,
you
know,
came
severely
impact
performance
or
something
like
that
which
hopefully
very
few
of
these
do
I
think
Chrome's,
absolutely
right
performance
matters
and
in
particular
really
now
the
reason
most
people
write
code
and
see
is
well.
Most
is
probably
too
hard,
but
you
know
many
many
people
do
see
specifically
because
they're
worried
about
performance.
A
So
then,
then,
maybe
like
a
follow-up
to
this
would
then
be
that
should
be
just
sort
of
use
this
for
all
the
options
that
have
an
impact
on
like
code
like
so,
if
you
emit
checks,
but
I
think
that
this
is
sort
of
a
little
bit,
what
I'm,
what
I'm
struggling
with
this
right
so
because
a
lot
of
this
mechanism
are
trying
to
minimize
the
performance
impact
right,
so
it
will
be
maybe
helpful
if
we
can
come
up
with
some
criteria
for
where
we
actually
a
note
this
and
where
we
are
not
loading
it
or
should
we
noted
for
everything
that
has
like
an
emit
some
code
as
additional
checks?
C
Yeah
so
from
CPU
perspective,
there
are
flags
that
had
overhead
all
over
the
place
and
then
there
are
flags
that
overhead
ad
overhead
at
specific
points
like,
for
example,
if
you
have
frame
pointers,
same
point
of
flags,
add
or
remove
overhead
all
over
the
place
like
at
every
single
function,
call
whereas
things
like
Philips
assertions
or
lipstick,
ppsr
or
45
source
for
that
matter.
They
they
may
add
overhead
at
specific
points
in
the
library.
So
the
scope
is
very,
very
limited.
C
So
when
you,
when
you
document
performance
overhead
concerns
about
him,
it's
it's
necessary
to
add
that
caveat
as
well,
because
it's
it's
the
kind
of
stuff
that
won't
be
visible
on,
like
a
a
general
in
a
Slowdown
like
you,
you
won't
see
it
in
spec,
for
example,
you
will
have
to
do
application
workload,
specific
tests
to
find
out
what
the
actual
impact
is,
because
otherwise
you're
not
you're
not
going
to
see
that
overhead
at
all.
C
A
A
But
then,
as
you
said,
there
should
be
maybe
like
this
reference
to
the
to
the
to
the
specific
sections
where
you
should
get
a
better
idea
of
where,
where
like
the
corner
cases
and
where,
like
the
problematic
cases,
lie.
C
Yeah
I
mean
like
for
for
flights
that
impact
like
all
of
Cogen.
It
makes
sense
to
add
performance
overhead
of,
like
a
brief,
may
impact
performance
in
a
note,
but
for
everything
else
I
think
we
should.
C
We
should
stick
to
only
the
details,
but
where
you
say
that
there
may
be
overhead
in
some
very
specific
cases,
but
in
general
it
should
not
be
noticeable
because,
from
from
past
experience,
I've
I've
realized
that
there's
there's
a
tendency
to
kind
of
be
alarmed
at
any
kind
of
any
any
mention
of
performance,
and
because
of
that,
this
there's
this
reticence
to
using
that
flag
instead
of
actually
doing
those
additional
tests.
C
Because
testing
for
performance
impactor
for
for
Galaxy
sessions,
for
example,
is
going
to
be
it's
it's
not
something
that
would
be
possible
at
the
hardware
vendor
level.
It's
gonna
have
to
be
at
the
application
render
level
where
the
application
vendor
looks
at
their.
B
C
Decides
whether
their
workloads
get
impacted
by
that
that
the
assertion
Flags
or
the
fortification,
if
you
likes
it,
it
cannot
be
done
at
a
general
purpose
level.
D
Yeah,
maybe
just
like
a
general
comment
about
like
getting
worried
and
kind
of
premature
optimization.
That
kind
of
thing
might
be
useful,
just
kind
of
encouraging
people
to
turn
on
the
flags
run
benchmarks
and
actually
see
if
this
impacts
them
in
a
real
way,
because
yeah,
it's
all
well
and
good.
D
Seeing
you
know
some
synthetic
tests
says
it's
a
big
deal
and
someone
says
this
isn't
a
big
deal,
but,
depending
on
what
your
actual
code
does,
you
should
probably
measure
something
so
yeah
just
encouraging
people
to
try
it
and
Benchmark
and
get
some
real
numbers
might
be
a
good
idea.
A
Right
then,
I
I
think
that
we
have
sort
of
like
the
way
we
were
trying
to
address.
This
was
that
we
had
this
sort
of
this
separation
into
like
these
two
tables,
one
which
is
sort
of
reserved
for
the
warnings
that
don't
have
that
you
can
be
sure
that
don't
have
any
impact
and
then
the
other
and
then
then
the
other
table
with
this,
which
is
the
options
that
have
some
kind
of
impact
on
the
generated
code.
A
But
I,
guess
that
then,
based
on
this
discussion,
it
would
seem
that
there
would
also
be
like
an
interest
to
do
like
some
kind
of
like
more
fine-grained
division
within
that
second
table
on,
like
which
of
these.
We
should
note
that,
like
you
should
really,
you
know
test
for
this,
for
your
performance
impact
foreign.
A
C
Yeah
I
think
that's
that's
been
one
of
the
issues.
I
mean
things
like
stack
protector,
for
example,
they're,
they're
accepted
as
being
in
necessary
security
mitigation,
and
it
has
a
Slowdown
associated
with
it,
but
it
almost
never
comes
up
today
because
it's
it's
in
whole
technology.
So
it
doesn't
really
come
up
today
as
a
performance
concern,
because
everybody
all
applications
have
absorbed
that
performance,
overhead
and
then
kind
of
move,
Beyond
it
and
trying
to
do
do
other
things.
So.
B
C
There's
the
the
focus
on
performance
is
necessary,
but
I
think
we
probably
need
to
take
these
things
into.
Are
these
like
application
specific
contexts
into
into
this.
A
So
so
would
it
be
so
in
order
to
go
forward
this?
Would
it
be
sort
of
fruitful
if
we
take,
we
review
the
text,
what
we
say
about
this
testing,
and
maybe
we
can
emphasize
that
further?
Maybe
it
will
be
useful
to
then
have
some
kind
of
proposal
on
this.
That
which
option
should
have
this
performance
impact
note
in
the
in
at
least
this
recommended
options
table,
and
then
we
can
discuss
specific
specific
options,
whether
based
on
based
on
some
initial
proposal.
A
All
right,
but
how
about?
If
I,
then,
if
I,
if
I,
try
to
make
an
initial
stab
at
this
and
I
put
up
a
PR
just
in
draft
mode
with
no
intent
on
merging
it
yet,
and
we
can
have
some
an
offline
discussion
on
this.
That
I'll
put
some
proposal
and
we
can.
We
can
discuss
it
that
which
one
should
have
and
which
one
should
have.
And
then
we
can
review
review
in
a
few
in
a
future
meeting
that.
A
All
right,
I
think,
maybe
maybe
that
gives
us-
maybe
a
more
Focus
discussion
around
specific
options
then
going
forward.
Are
there
any
other
notes
on
this
now
on
the
pr
one
to
eight
or
one
for
two
or
do
we
feel
that
this
goes
into
into
the
right
direction?
I
saw
that
Jack
has
already
also
contributed
something
to
this,
partly
partly
cosmetic,
but
thanks
thanks
for
the
fixes,
did
you
have
any
comments
on
the
content
itself.
D
A
A
All
right,
then,
we
can
probably
move
on
to
the
yeah.
A
I
I'm
not
sure
whether
I
got
I.
Think
crop
asked
more
asked
access
for
me
yesterday,
but
I
think
I
haven't
gotten
a
confirmation,
email.
F
As
I
said,
Thomas,
hopefully
we'll
hear
back
from
operations
today
to
get
you
the
permission
so
that
you
can
go
ahead
and
do
that
in.
A
The
future
thanks
yeah
thanks
a
lot
for
the
help,
Mike
and
also
contribute
on
doing
this
housekeeping
after
this
after
this
meeting.
So
then,
next
one
was
one
three
two
and
this
we
already
briefly
talked
about
talked.
A
Yeah,
so
this
was
so
this
was
this
GCC
V
section
that
was
proposed
by
Randall
and
I
think
that
we
were
overall
happy
with
this,
at
least
during
the
last
meeting,
but
I
think
that
one
sort
of
thing
that
came
out
of
the
discussion
discussion
was
that
we
should
add
a
recommendation
to
explicitly
enable
the
hardening
flags
on
the
command
line,
rather
than
rely
on
the
default
profile
or
distro
defaults
and
I.
A
Think
we
decided
that
it
could
go
into
the
same
the
same
PR
but
sorry,
I,
I,
didn't
I,
didn't
go
ahead
and
update
update
this.
So
maybe
this
is
still
something
that
we
can.
A
We
can
work
on
offline,
but
are
there
any
I
think
that
we
have
like
a
little
bit
of
a
different
set
of
participants
this
time?
So
I
don't
know
if
there
are
any
other
comments
on
this
one.
Three
two.
D
So
is
this
about
Flags
inherited
from
like
when
you
build
GCC
to
then
get
kind
of
preserved
into
future
builds
or
exactly
yeah?
Exactly
yes,
because
in
terms
of
specifying
stuff
by
hand,
I'd
say
yeah
if
you're
just
kind
of
picking
up
these
flags
from
GCC
itself,
and
it's
probably
best
to
just
set
it
yourself
as
well,
but
for
certain
distributions.
D
A
Yeah
I
I
think
that
this
is
like
something
that
we
had
a
little
bit
of
sort
of
discussion
previously
on
the
scope
of
this
document
and-
and
we
like,
based
on
those
discussions,
at
least
of
my
takeaway,
has
been
that
we
sort
of
felt
that
we
went
a
little
bit
stay
away
from
the
distro
discussions,
because
to
this,
of
course,
have
their
own
ways
of
managing
this
already,
and
this
guy.
This
may
be
more
geared
towards
the
developers
who
are
doing
their
building
themselves
rather
than
packaging
for
distros
right.
So
the
so.
A
H
Another
thing
another
thing
to
add
to
that
was
that
as
a
packager,
the
my
intent
with
this
was
that
I
noticed
that
a
lot
of
people
use
the
distro
containers
just
because
they're
easy
in
their
CI
CD
and
they
get
GC
seeds
through
app
or
whatever
they're
using
just
because
it's
simply
easier,
and
it's
just
one
of
those
things
that
we
wanted
to
put
it
in
there,
that
if
you
are
going
to
do
that,
just
make
sure
that
you
are
aware
that
there
could
be
things
that
are
turned
on
by
default,
but
I.
H
A
Yeah
and
and
then
then
Randa
also
started
compiling
compiling
this
very
nice
document
on
the
default
configurations
in
different
distributions,
which
can
have
some
value
on
its
own,
even
though
it's
a
little
bit
outside
the
scope
of
this,
this
guide
document
as
well.
The
link
to
that
should
be
in
the
in
the
meeting,
notes
and.
H
Also
Thomas,
this
just
to
add
more
to
this.
This
also
comes
from
my
background,
like
in
packaging,
where
a
lot
of
people
just
think:
okay
I'm
going
to
download
GCC,
and
it
should
be
inherently
secure
because
I
see
a
lot
of
that
attitude
in
packaging
that
they
think
that,
because
you're,
getting
it
from
Divi
and
Debian
has
a
responsibility
to
basically
have
your
bag
or
enable
saying
security
Flags.
But
the
definition
of
sane
obviously
differs
from
group
to
group
to
group.
So.
A
Yeah,
that's
a
that's
excellent
point:
yeah
go
ahead,
Jack.
D
So
with
the
like
compiled
set
of
defaults
for
different
distros,
is
that
going
to
live
somewhere
separate
from
this
document?
I'm
just
worried
it
might
get
out
of
sync
quite
quickly.
H
H
Decided
that
this
would
be
better
because,
just
because
of
the
fact
that
yeah,
it
would
get
out
of
date
and
somebody
would
have
to
maintain
it
and
the
end
of
the
day,
it's
kind
of
an
edge
case.
You
know
for
this
document.
D
So
yeah
so
I
guess
this
would
be
rather
than
going
through
and
grabbing
all
this
we
can
just
teach
someone
how
to
do
it
themselves:
correct,
okay,
awesome
and
then
yeah.
Something
that's
not
quite
related,
but
I
feel
is
is
tangential
is
maybe
a
mention
on
not
duplication
of
flags,
but
the
ordering
of
flags
I
found
that,
like
Dash,
W
all
and
then
like
setting
levels
for
other
things,
certain
Flags,
override
other
flag
values
and
it's
important
to
get
the
order.
Correct.
A
Yeah,
that's
actually
an
excellent
point,
so
this
was
also
I
was
also
like
wondering
about
this.
That
I
had
a
I
have
to
do
on
myself
to
check
what
happens
if
you
do
stack,
protect
stack
protector,
strong,
but
then
do
like
regular
stack
protector
after
that,
so
which
one
takes
precedence.
So
is
this
the
better
one
or
is
the
one
that
specified
specify
last
yeah.
D
We'll
probably
get
to
this
a
bit
later
on
on
some
of
the
next
PRS,
but
I
was
doing
a
bit
of
research
and
yeah
I
found
someone
trying
to
reproduce
an
example,
and
it
wasn't
working
because
they
did
a
strict
overflow,
5
and
nwl
and
wole
is
overwriting
that
value.
So
you
had
to
have
it
the
right
way
round
later.
G
B
E
D
Oh
about
the
ordering
I
haven't,
read
everything
but
I,
don't
think
so.
I.
E
E
A
Yeah
I
I
think
that
we
have
quite
a
lot
of
this
related
discussion.
So
maybe
we
can
take
a
stab
at
this
and
using
this
pr13
to
add
these
additional
aspects
to
it
and
continue
the
discussion
there,
but
I
think
that
overall
I
think
the
Direction
seems
to
be
seems
to
be
good.
I
think
we
just
have.
We
have
also
just
add
this
additional
observation
to
the
to
the
kavits,
and
then
we
can.
A
I
don't
know
if
I
don't
know
if
anyone,
if
no
one
else
volunteers
I'd
be
happy
to
take
a
stab
at
this
wording
as
well.
But
how
do
you
feel
Randall?
You
made
the
initial
suggestion.
Did
you
did
you
want
to
continue
on
this.
A
A
G
So,
just
in
general
I
think
we
should
be
citing
information.
You
know
for
the
particular
Flags
if
we
knew
something
these
are
citations,
that
other
people
think
it's
a
good
idea:
how
to
have
these
kinds
of
flags,
so
hopefully
that'll
can
help
convince
people
that
oh,
this
is
a
good
idea
in
general,
yeah.
A
I'm
I'm
also
very
happy
with
this
suggestion.
One
sort
of
tangential
discussion
I
think
we
there
was
some
discussion
in
the
comments
was
that
we
are
not.
We
don't
have
a
very
consistent
citation
style
and
I
take
full
responsibility
for
that,
because
initially
I
did
this
numbering,
which
is
of
course
like
a
very
bad
idea
when
we
are
adding
citations
in
the
middle.
So
what
I?
A
What
I
would
sort
of
suggest
that
we
sort
of
try
to
stick
to
this
source
and
year
style
citations
where,
where
possible
or
then
the
document
identifier
we're
not,
and
we
can
in
sort
of
slowly,
maybe
move
the
other
citations
to
this
style.
But
as
long
as
the
links
aren't
broken,
I
think
that
I
think
we
can
manage.
We
can
manage
this
as
long
as
the
new
ones
are
are
added.
G
A
huge
fan
of
author
date:
let's
do
that,
but
I
would
say:
let's
let's
review
this
as
it
is,
it
uses
the
existing
format
and
then
we
can
have
a
separate
change
for
switching
around
to
author
date.
Format,
I
agree
with
you
by
the
way
on
author
date,
you
know
what
one
two
three
doesn't
really
clear:
anything
yeah.
A
Yeah,
that
was
I
will
admit.
That
was
laziness
on
my
part
too,
since
I
did
the
initial,
like
initial
conversion
in
a
batch
mode
from
the
from
the
original
Word
document.
So
sorry
about
that,
oh.
G
No,
no,
no,
no,
no
apologies
necessary.
This
is
it.
This
is
a
common
format.
I
I
agree
with
you
the
advantages
of
the
other,
so
just
just
on
this
I'm
hoping
this
is
a
straightforward
one.
It's
just
you
know.
Hopefully
we
all
agree
that
hardening
is
good.
This
just
adds
some
citations.
That
say
other
people
say
hardening
is
good.
A
Crop
had
some
comments
on
the
citation
in-text
citation
may
be
easier.
This
isn't
an
academic
paper
yeah.
F
G
Yeah
actually
I
I.
If
you
don't
mind,
I
I'm
gonna
disagree
with
a
little
bit
here,
because
that's
all
true
as
long
as
nobody
ever
changes
links
well.
B
G
It
one
third
of
all,
Supreme
Court
links,
don't
work
anymore
already,
so
I
I
think
it's
valuable
to
have
a
list
in
the
bottom,
not
if,
but
when
the
links
get
screwed
up.
So
you
can
find
more
well.
F
G
Right,
but
that's
okay,
this
one
literally,
is
I
would
do
that
as
a
separate
step
right
now.
This
is
just
adding
the
citations
using
existing
citation
format
and
I
would
propose,
let's
argue,
separately,
the
how
to
change
the
citation
format.
B
G
And
and
walk
through
that
I
do
agree
with
you
that
if
you
can
click
and
jump
straight
to
it,
that's
awesome.
E
D
A
D
A
Yeah
but
yeah
I,
like
I
I,
maybe
I'm
more
in
sort
of
David's
camp
on
on
this
inline
versus
citation.
Also,
partly
because
of
this
reason
that
we
can
have
this
I
can
have
this
additional
information
and
I
think
that
this,
if
you
use
the
inline
sorry,
if
you
use
the
citations,
you
also
get
this
works
cited
page
for
free
effectively,
because
those
are
good
that
the
at
the
end
of
the
document
automatically
but
yeah,
maybe
also
like
in
the
interest
of
time
on
my
side.
A
I'm
happy
with
this
happy
with
this
change,
and
maybe
we
can
put
the
citation
style,
Holy
Wars
on
the
agenda
for
a
future
meeting
and
everything
yeah.
A
Yep,
so
I
guess
that
we
are
if
there
is
no
concerns
about
the
content
here,
I
guess
this
one
is
also
ready
to
be
merged.
G
G
Basically,
the
Linux
kernel
has
a
couple
flags
that
change
what
code
is
generated,
because
what
they
found
was
that
there's
some
constructs
that
if
you
just
optimize
out
your
basically
are
creating
vulnerabilities.
G
So,
while
in
general
you
want
to
optimize
as
much
as
you
can,
there
are
some
checks
which,
if
you
optimize
them
away
they're
likely
to
lead
to
a
vulnerability.
This
one
is
basically
removing
deleting
null
pointer
checks.
No
pointer
checks
from
in
most
cases
are
basically
free.
Anyway,
you
mean
you
either
have
them
in
the
register
or
in
a
cache.
So
while
technically,
this
is
a
performance
impact,
it's
usually
nearly
zero,
because
it's
in
a
cache
line
or
in
a
register,
but
all
too
well
for
the
compiler
realizes
that.
B
G
If
it
was
null
it'd,
be
undefined
behavior
and
programmers
never
make
mistakes
so
we'll
just
remove
the
check,
and
this
has
resulted
previously
in
vulnerabilities,
which
is
why
the
kernel
folks
enable
this-
and
you
can
see
the
details
here
and
I,
even
included
a
code
example
in
the
sample
code,
because
I
think
I
think
it's
easy
to
understand
with
the
code
example
and
hard
to
understand.
Without
it.
A
Yeah
I,
like
from
from
my
side
I,
think
this
seems
like
a
valuable
thing.
I
don't
have
first-hand
experience
with
this,
so
I
feel
that
I
cannot
really
comment
on
like
the
like
the
value
outside
the
Linux
kernel.
So
if
anyone
has
any
opinions,
I
think
that
that
would
be.
That
would
be
valuable,
but
it
seems
like
a
reasonable
addition.
C
Right,
in
fact,
it
looks
like
a
pattern
that
the
compiler
should
be
looking
up
closely
at
so
I
I
would
I,
would
probably
I'll
probably
file
a
bug
in
GCC
or
or
basically
have
someone
on
my
team.
Look
at
this
a
little
closer
and
see
if
we
can
actually
detect
and
warn
about
this.
G
That
that
would
be
good,
but
that
that
comes
down
to
detecting
iubs
oops,
and
we
have
other
folks.
I
Yeah
I
was
going
to
say
that
this
is
in
the
same
bucket
as
let's
say,
minus
F,
no
strict,
aliasing
and
a
bunch
of
other
flags
that
were
added
later
when
the
optimizer
folks
started
exploring
optimizations
to
generate
better
code,
and
they
have
been
very
problematic
for
the
kernel
code.
So,
even
if
you
know
we
can
still
confuse
our
friends
over
in
the
GCC
document
to
to
fix
some
other
bugs.
I
It
is
the
general
problem
here,
which
is
that
kernel
code
is
very
different
from
application
codes
and
and
in
in
color
code
like
in
this
example.
There
are
things
that
are
happening
at
the
hardware
level.
You
know
what
is
going
on,
but
they
don't
really
follow
the
rules
of
the
C,
abstract
machine.
I
G
If
I,
if
I
may
respond
real
quick,
yeah
I'd,
rather
talk
about
each
flag
completely
separately
on
its
own
I'm,
not
talking
about
aliasing
it
I'm,
specifically
talking
about
deleting
null
pointer
checks.
I,
don't
have
like
you
know,
academic
data,
but
checking
for
null
pointers
is
pretty
much
a
universal
in
C
code.
G
I,
don't
think
it's
currently
unique
at
all
to
say
you
know,
have
some
function
that
says
first
check
with
null.
If
it
is
do
something
if
it
isn't
do
something
else,
I
also
don't
think
it's
unusual
at
all
to
have
to
have
a
declare,
a
variable
where
you
set
its
value
based
on
some
computation
and
unfortunately,
that
computation
could
actually
accidentally
dereference
a
null
pointer.
That's
what's
happening
in
this
particular
example
right
here.
G
So,
while
I
agree
with
you
that
kernel
code
is
different
from
other
kind
of
from
application
code,
I,
don't
think
that
the
problem
in
this
particular
flag
is
unique
to
Kernel
code
at
all.
If
you
look
at
the
example,
we've
we've
got
a
dereference
of
Dev
followed
by
is
Dev
null
or
not,
and
unfortunately
that's
an
easy
mistake
to
make
in
any
c
code
and
therefore
I
think
this
flag
applies
to
any
c
code
as
well.
Okay,.
B
I
What
you're
talking
about
here?
So
what
we're
talking
about
here
is
the
same
bucket
as
Swift
aliasing
I,
understand,
I,
I
agree
with
your
argue
with
that.
We
should
discuss
each
of
these
options
separately.
I
agree
with
that,
but
I
want
to
push
back
on
the
structure
of
the
arguments.
What
is
happening
is
that
the
program
has
undefined
Behavior
right.
I
Okay.
So
when
you
have
the
difference
there,
what
is
happening
is
that
it
there
is
an
implicit
assumption
that
says
this
quarter
is
not
now
right
and
and
then
the
optimization
goes
on
and
start
pushing
those
assumptions.
Those
increased
options
to
download
control
for
graph,
whether
it
is
explicit
remove
the
a
an
extra
check.
There
are
some
other
assumptions
that
come
from
having
that
null
pointer
being
like
now
is,
like
you
can't
just
say:
oh
always
put
it
there,
it'll
be
it'll,
be
okay!
I
Then,
because
you
have
this
fly,
then
the
compiler
will
not
optimize
me
with
that
that
that
surprises,
you
and
and
I
would
hate
that
we
we're
putting
in
here
a
recommendation
plus
a
reasoning
that
makes
people
believe
that,
because
they
have
those
options,
they
have
those
compiler
options
and
because
of
the
code
pattern,
nothing
bad
will
happen.
G
I
G
G
The
goal
is
to
reduce
the
likelihood
or
impact
of
vulnerabilities.
That's
all
we're
doing
we're
not
guaranteeing.
If
you
want
guarantees,
there
are
formal
methods,
go
use
them.
G
Undefined
Behavior,
but
guess
what
most
C
code
has
undefined
Behavior
it's
hard
to
not
have
undefined
Behavior
I
assume
with
a
large
sea
base.
There's
thousands
of
undefined
behaviors
and
the
problem
I
mean,
strictly
speaking
from
a
standard's
point
of
view.
You
shouldn't
have
undefined
behaviors,
but
since
they
happen
and
happen
constantly,
that's.
G
I
I
Say
that
I'm
looking
at
the
structure,
so
there
is
what
you
and
me
say,
because
we
are
experts
and
we're
supposed
to
give
people
advice
price,
and
then
there
is
the
structure
of
what
we're
telling
people.
That's
what
I'm
worried
about
I'm,
not
I'm,
not
worried
about
what
you're,
literally
saying,
I'm
worried
about
the
pattern
of
our
you
know
the
the
structure
of
arguments
and
and
how
we're
rationalizing
this.
That's
that's!
That's!
Where
I'm
coming
from.
A
Okay,
so
let's
hear
from
Jack
now
and
then
I'd
like
to
make
a
proposal
related
to
this
but
go
ahead.
Jack
you
had
a
comment.
D
Yeah
there
was
some
points
earlier
about
similar
flags
and
I
linked
this
paper
that
David
linked
and
yeah
I
agree
going
through
them
individually
would
be
good
working
out
if
they
are
generally
useful
or
just
useful,
for
things
like
a
kernel
would
be
good
with
some
of
these
in
the
paper,
there
are
examples
for
for
non-kernel
usages
and
there's
also
a
little
table
that
explains
projects
that
use
certain
Flags.
So
some
of
these
are
turned
on
by
by
postgres,
and
maybe
they
have
specific
reasons
that
we
could.
D
What
else
was
I
gonna
say
yeah,
someone
mentioned
getting
a
warning
about
when
the
optimization
happens,
if,
if
it
isn't
turned
off
completely
I,
don't
know
if
there's
a
warning
specifically
for
this
flag,
no
delete,
no
point
to
checks,
but
I
started
looking
into
no
strict
overflow,
and
there
is
a
warning
that
you
can
get
for
when
it
does
do
a
an
optimization
on
that
one
we
could.
We
could
check
if
there
is
a
warning.
C
C
So
the
new
feature
would
essentially
look
at
a
point
of
being
dereferenced
before
it
was
it
Compares
before
it
is
compared
with
inal
or
a
specific
value
to
finish
Short
Circuit.
C
So,
instead
of
assuming
that
the
power
pointer
is
non-null,
you
basically
had
a
diagnostic
where
it
it
checks,
if
lower
down
in
in
the
control
flow
graph.
The
there
is
a
check
for
that
pointer
to
verify
if
it
is
null.
G
I
I
think
that
sounds
like
a
good
if
I
mixed
around
I
think
that
sounds
like
a
good
idea.
I
mean
if
somebody
wants
to
file
it.
That's
great
I
think
that's
outside
the
scope
of
what
we
can
do
I
mean.
Obviously
we
can't
commit
to
GCC
folks
to
to
make
that
change,
that
they'll
have
to
make
that
decision.
So.
G
A
So
I
think
we
already
discussed
earlier
on
that
right
now.
Now
we
have
these
sort
of
like
two
tables,
which
is
like
warnings
and
sort
of
the
the
the
sort
of
the
Bonafide
hardening
options
that
have
like
a
security
like
a
security
rationale.
So
to
speak,
and
at
least
from
my
side,
I
wouldn't
see
any
reason
why
we
couldn't
have
yet
the
third
table
that
would
maybe
have
the
scope
that
covers
like
this
is.
These
are
like
the
options
that
have
an
impact
in
these
specific
cases.
A
If
this
touches
upon
you,
you
should
consider
using
them,
and
that
might
also
like
help
in
structuring
this
document
document
as
well,
and
then
we
can
still
have
the
description
of
this.
So.
G
The
separation,
in
both
cases
for
the
performance
ones
they're
specifically
to
to
change
the
code
to
make
it
harder
to
attack
this
option
is
exactly
the
same
thing.
There
are
other
options
that
counter
buffer
overflows
buffer
overflows
are
also
undefined
Behavior,
so
they're
all
electrifying
Behavior.
G
I
I
What
I've
seen
in
practice
is
why
I'm
having
this
pushback,
it's
it's
it's
it's
not
that
I'm
like
I,
don't
I,
don't
like
hey!
If
we
can
just
have
you
know
built-in
suspenders,
it
won't
be
great
it
it
it's
what
it
provokes
in
practice.
That's
why
I'm
pushing
back
gotcha.
A
We
have
also
a
comment
from
C
Dash
and
then
I
think
we
need
to
continue
this
discussion,
maybe
next
time,
but
I
think
that
it's
clearly
something
that's
a
bit
contentious.
So
I
think
that
we
need
to
I
think
continue
this
and
try
to
understand
each
other's
each
other's
viewpoints
and
I.
I.
A
C
Point
so
I
yeah
I
I
wanted
to
elaborate
on
the
difference
between
something
like
if
no
delete
checks
or
for
that
matter,
even
the
new
Option
F
trivial,
Auto
violinate
right.
So
what
these
options
do
is
that
they
make
undefined
Behavior
defined
and
allow
program
execution
to
continue
as
if
nothing
happened,
whereas
the
buffer,
overflow
checks
or
any
of
the
other
underlying
Behavior
checks
mitigated
by
immediately
terminating
execution
of
the
application.
So
that
is,
that
is
the
key
difference
between
the
two.
C
So
what
the
first
one
does
is
that
it
allows
under
code
that
invokes
undefined
Behavior
to
continue
undetected,
whereas
the
other
one
doesn't
so
I
wouldn't
discourage
the
use
of,
if
not,
delete,
now
point
in
checks,
but
I
wouldn't
promote
them
alongside
the
others,
which
is
why,
like
Thomas,
your
idea
of
having
a
separate
section
of
such
kind
of
flags
which
make
programs
safer,
but
they
also
kind
of
end
up
papering
over
issues.
C
It's
it's
necessary,
but
probably
as
a
separate
section
and
not
mixed
in
with
the
rest
of
the
security
Flags.
G
That's
a
that's
a
good
good
clarification.
I
still
think
you
know.
I
would
actually
agree
that
having
flags
that
detect
the
problem
and
prevent
compilation
would
be
better,
but
we
don't
have
that
today.
I'm.
C
G
A
I
I
hate
to
interrupt
this
very
interesting
discussion,
but
I
think
that
we
have
already
people
dropping
out
so
I
think
that
we
need
to
wrap
it
up,
but
I
think
what
would
be
really
good
if
we
can
sort
of
offline
start
to
think
about
this,
how
we
want
to
represent
it
and
I
think
if
we
can
have
sort
of
like
a
concrete
suggestion
for
that
in
an
upcoming
meeting,
I
think
that
that
might
be
sort
of
like
a
fruitful,
fruitful,
Way
Forward,
but
I
think
that
this
is
yeah.
A
I
think
this
is
a
really
interesting
discussion,
so
I
hope
we
can
I
hope.
We
can
continue
this
around
some
concrete,
concrete
proposal
yeah.
But
thank
you
very
much.
Everyone
for
joining
today
and
I
think
there
was
good
progress.
I
think
we
got
through
all
the
sort
of
currently
opened
PRS
and
we
have
identified
what
to
what
to
work
on
and
I
wish
you
all
a
very
good,
very
good
continuation
for
your
day
and
see
you
all
in
two
weeks.