►
From YouTube: C/C++ Compiler Options Best Practices (March 29, 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
B
B
B
Better,
all
right,
we
are
a
bit
fewer
today,
but
let's
get
started.
I
put
the
link
to
the
Google
Doc
with
the
meeting
notes
into
the
chat.
B
A
I'm
going
to
introduce
myself,
my
name
is
Sam
zeidel
I
work
for
recap,
systems
and
I'm
in
the
I.
Guess
it's
technically
the
kind
of
devops
release,
Engineering
Group
we
build,
we
build
our
own
internal
internally.
We
build
our
own
operating
system,
it's
not
actually
based
on
Linux,
but
there's
a
lot
of
interest.
I
mean
there's
a
lot
of
you
know
similar
similar
interests
and
concerns
that
spend
you
know,
span
operating
systems.
A
B
B
So
we
have
a
couple
of
things
on
the
agenda
for
now
and
please
free
if
you
have
any,
if
you
want
to
add
any
other
open
items,
please
go
ahead
and
add
them
to
the
to
the
Google
Doc,
but
I
guess
that
if
when
we
are
a
little
bit
fewer,
we
could
I
think
get
started
from
at
least
looking
through.
Some
of
these
proposed
pull
requests.
B
C
Yeah
so
I
think
you
you
approved
it
two
days
ago
and
then
your
charge
yeah.
B
A
B
B
We
just
started
to
go
through
this
pull
requests.
D
Awesome
titama,
sorry
about
that.
I
had
an
LF
meeting,
no.
B
Worries
so
we
were
just
looking
at
the.
We
were
just
looking
at
the
sidesh
editions
and
they
all
looked
good
from
from
our
point
of
view.
B
D
Just
just
for
the
record
just
for
the
record,
what
you
need
to
do
I
can
merge
them
for
you
for,
first
of
all,
did
you
guys
know
that
we
have
notes
and
best
practices
where
we're
supposed
to
sign
in
because
the
same,
but
anyway
just
email
operations,
it's
operations
at
openssf.org
and
copy
Chrome
requesting
to
be
added
to
the
team
to
the
best
practices
team,
because
that's
the
team,
you
need
to
be
added
to
be
able
to
merge
and
basically
Crow
should
approve
it
and
that's
how
you
get
put
into
GitHub.
B
B
B
Then,
which
one
is
the
which
one
is
the
next
one?
So
there's
this
okay,
this
one
was
from
you
Randalls
at
GCC,
Dash
V
section
in
compiler,
hardening
guide.
D
B
D
B
And
you
also
had
like
I
guess
that
this
is
also
now
related
to
this.
These
also
now
related
to
this
other
Google
docu
that
you
started
compiling
compiling
together
right
where
you
are
collecting
the
different.
B
Yes
different,
different
default
options.
Yes,
so
I
think
I
think
that,
like
this
I
think
that
the
additional
text
look
good.
How
do
you
see
like
the
relation
between
the
two
documents
right
so
well,.
D
D
The
problem
is
that
people
went
or
got
flags
from
somewhere
very
questionable
where
they
get
these
flags
from,
and
they
just
enable
everything,
because
they
think
it's
like
switches
that
you
just
switch
things
on
I
mean
that's
what
could
possibly
happen.
It
can't
go
any
slower,
but
that
and
that's
the
problems,
and
they
realize
that
first
of
all,
a
lot
of
your
distros.
If
you're
talking
about
compiling
for
distros,
then
you're
gonna
do
the
work
for
you.
So
you
really
shouldn't
like
the
secret
to
installing
Gen
2
is
installing
it
without
Flags.
D
Laughs
main
reason:
why
is
because
we've
already
done
all
the
work
for
you
so
yeah
so,
but
yeah
like
like
a
lot
of
people,
don't
get
that
so
I
think
that
this
is
an
important
note,
depending
on
your
use
case,
you
know,
and
depending
what
you're
trying
to
do.
I
know
it's
very
typical
now
to
just
use
Docker
use,
you
know
apt,
ad
and
just
add
GCC
depth,
Dev
or
whatever,
but
my
recommendation
would
be
check.
D
A
D
D
B
B
A
D
B
Yeah
no
I
I
that
I
think
that
that
makes
sense.
So,
of
course,
it
requires
some
effort
to
go
through
the
output,
but
yeah
I
think
that
that's.
That
is
like
the
only
way
to
be
sure
right
that
you
actually
look
at
the
output
of
that
exactly.
D
And
that
being
said,
there
are
a
few
people
out
there
like.
If
you
really
wanted
like
when
I
first
started
years
ago,
figuring
out,
GCC
I
mean
you
could
a
lot
of
there's
a
lot
of
people
that
have
good
blogs.
So
if
it's
a
flag
that,
like
is
a
big
thing,
you
might
actually
find
something
on
Google
that
will
go
in
depth
like
what
happens
when
you
enable
it
or
you
don't
enable
it
or
when
you
add
these
other
flags,
some
people
actually
do
have
blogs.
If
the
flag
is
like
important
enough.
C
So
I
think
the
only
the
only
challenge
that
limited
GCC,
minus
V
section
is
helping
people
look
for
the
flags
that
are
useful
like,
for
example,
you
you
get.
This
whole
list
of
you
know,
configure
flags
for
GCC
and
which
ones
are.
Those
are
important
is
is
something
that
we
probably
need
to
point
out
like
enable
default.
C
Pi,
for
example,
is,
is
something
that
that
you
want
to
highlight,
and
you
know
there'll
be
others,
so
the
challenge
would
be
to
kind
of
get
those
out,
and
you
know
highlight
those
compared
to
like
a
100
other
options
that
are
in
there.
D
See
I
thought
that
would
have
been
the
way
that
I
was
gonna
address.
This
is
what
I
suggested
to
George
was
possibly
adding
another
column,
because
that
way
you
know
like.
If
you
have
default
Pi,
you
don't
need
to
enable
Pi.
I
mean
I.
Think
there's
also
default
no
pie
too,
but
but
I
think
it
would
just
be
good
to
point
out
like
if
you
have
these,
then
you
really
don't
have
to
worry
about
these.
B
Yes,
I'm
I'm
like
a
little
bit
wondering
that
isn't
this
kind
of
like
which
flags
are
relevant,
isn't
that
kind
of
also
what
we
are
trying
to
address
by
compiling
this
guide
in
the
first
place
right?
B
So
the
things
that
you
would
look
for
as
a
user
would
presumably
be
the
flags
that
we
have
in
this
in,
like
the
recommended
option
table
or
this
tldr
version
right
and
and
then
and
then
then
you
can
sort
of
look
at
it
from
from
like
two
ways.
So
so
either
you
might
be
either
you
might
be
sort
of
either
you
might
be
sort
of
missing
something
or
then
you
know
you
are.
B
You
are
doing
this
because
you
are
having
some
issues
with
your
build,
but
then
again
the
more
detailed
sections
in
our
guide
would
provide
like
this
caveats,
with
some
or
with
some
more
information,
so
I
I,
don't
really
know
that
like,
if
is,
is
your?
Is
your
concert,
Conservancy
dish
that
that
we
should
be
doing
something
like
more
specifically
in
this
guide
to
to
be
like
a
little
bit
more
verbose
about
this?
B
That
how
you
would
actually
like
go
about
doing
this
or
or
do
you
think
that,
like
the
guide,
is
not
sufficient
to
do
this
exercise.
C
So
I
think
the
the
minus
V
kind
of
opens
up
a
different
Avenue
when
it
comes
to
this
guide,
where,
where
it
says
that
we
have
all
of
these
options,
but
if
you
look
at
GCC
minus
V
on
your
distribution,
you'll
find
that
some
of
these
are
enabled,
and
you
don't
need
to
do
that,
so
it
it
sounds
like
an
additional
caveat.
C
Maybe
it's
something
that
we
put
in
like
as
an
appendix,
which
will
then
also
kind
of
talk
about
you,
know,
distribution,
Bill,
flags
and
and
so
on,
where,
where
we
kind
of
expand
on
you
know
the
state
of
flag
usage
as
it
were,
and
and
not
as
like
a
main
thing
where
so
My
worry
is
that
it
will
probably
just
end
up
confusing
users
and
and-
and
we
might
end
up
having
this
kind
of
inconsistent
usage,
where
users
assume
that
there
are
developers
assume
that
end
users
are
always
going
to
be
on
Ubuntu
and,
you
know,
don't
add,
like
default.
C
Pipe
Flex,
for
example,
assuming
that
it's
always
going
to
be
there
or
you
know,
have
these
kind
of
assumptions
that
are
just
specific.
C
So
that's
that's!
Basically,
my
concern
like
I,
it's
a
very
useful
thing
to
have
there.
It's
just
the
the
positioning
to
kind
of
make
sure
that
the
messaging
of
the
document
is
correct
is
is
what
I'm
concerned
about.
B
Right,
so
so,
so
would
that
concern
be
addressed
by
maybe
adding
a
sentence
saying
that,
regardless
of
what
the
sort
of
defaults
are,
you
can
still
provide
them
as
command
line
options,
and
it
will
not.
It
will
not
hurt
you
something
and
and
and
maybe
and
maybe
even
say,
that
that's
sort
of
like
the
best
practice
that
we
recommend
that
you
always
be
explicit
about
the
hard-ending
flags
and
enable
them,
even
if
they
are
enabled
by
the
distro
register
your
own,
to
have
this
kind
of
like
consistent,
consistent
usage.
A
A
I
I,
wouldn't
I,
would
maybe
disagree
a
little
bit
in
about
portability
that
doesn't
necessarily
make
things
more
portable,
because
some
of
the
flags
may
end
up
only
being
specific
to
a
particular
operating
system.
For
one
reason
or
another,
GCC
is
not
necessarily
identically
built
on
different
operating
systems
and,
depending
upon
you
know,
you
may
be
building
your
own
GCC
right
like
what
we
do
internally
so
but
I
agree.
A
D
Exactly
if
I
may,
it
might
also
be
helpful
to
add
a
line
in
there
that
if
you're
doing
this
from
a
developer
perspective
like
on
Docker,
you
should
be
using
GCC
container,
if
you're,
just
trying
to
compile
one
thing,
because
GCC
does
have
a
separate
setup
than
like
the
Divi
they
use
Debian,
but
they
actually
compile
GCC
and
it's
like
a
clean
version
of
GCC
without
anything
any
patch
applied
to
it.
D
You
should
look
at
this
now.
Let
me
also
say
this
in
all
my
years
of
being
in
Gen
2.
What
I
can
say
is
this
that
I
think
flags
are
kind
of
a
Goldilocks
approach
where,
if
you
have
too
many,
you
could
definitely
trip
you
up
and
if
you
have
too
few,
then
you
really
don't
know.
What's
going
on,
you
could
have
mixed
results.
B
B
Yeah,
so
it
it
sounds
like
then
it
sounds
like
then.
This,
like
the
wording
of
the
text,
can
use
a
little
bit
more
attention
and-
and
maybe
like
a
little
bit
more
clearer
messaging
about
this.
That,
like
the
recommendation,
is
to
always
enable
enable
at
least
the
hardening
flag.
B
Since
that's
what
we
are
focusing
on
here
explicitly,
regardless
of
the
output
of
gccv,
but
at
least
from
my
side,
I
I
kind
of
see
a
value
in
having
this,
where
it
is
now
like
in
the
main
document
rather
than
an
appendix,
because
this,
because,
because
we
even
like
especially
like,
if
it
sort
of
comes
with
this
sort
of
like
best
practice,
recommendation,
I
think
that
that
would
be
good
to
have
sort
of
fairly
early.
C
C
There
are
like
40
50,
different
options,
and
in
that
you
you
need
to
look
for
specific
ones
to
to
kind
of
know
whether
a
certain
feature
is
enabled
or
not,
so
that
bit
I
guess
would
be
useful
as
an
appendix,
because
without
that
the
minus
V
kind
of
note
is
is
kind
of
half-baked,
I.
Think.
D
I
do
agree
with
what
sanisha
is
saying
and
I.
Think
the
I
agree
with
the
appendix
another
thing
I
was
going
to
say
is
I
mean
if
you
wanted
to
make
like
a
super
secure
version
of
GCC.
It
just
turn
on
all
the
secure
Flags
automatically
and
use
that
to
compile,
because
you
compile
from
Source
I
mean
you
could.
D
That
is
one
approach
to
take
that
you
could
just
use
all
the
default
Flags
like
default,
pi
and
F
pot,
or
all
that
F
pick
and
all
that
stuff,
and
you
could,
you
know
just
turn
everything
on
that
edge,
build
a
secure
version
of
GCC,
so
I
think
it
has
value
I,
just
think
it.
It
yeah
I
agree
with
what
city
said:
I
should
I
I.
Think
an
appendix
item
would
be
good.
B
D
D
B
D
B
D
B
Yeah,
but
maybe
maybe
since
we
are-
maybe
maybe
since
we
are
sort
of
still
discussing
this,
this
PR,
so
how?
How
do
you
see
this
like
the
Google
Doc,
with
with
the
distribute
specific
options,
so
the.
A
D
It
was
basically
like
we
enable
this
by
default,
so
it's
it's.
This
I
guess
so.
I
think
that
that's
why
I
decided
to
go
with
this,
because
I
think
that
this
is
like
more
specific
and
even
as
this
changes
in
the
future,
the
document
would
still
be
accurate
because
we're
not
going
to
focus
on
any
one
specific
distro.
D
B
Yeah,
but
but
but
from
the
from
the
work
that
you
put
in
there
in
already
I,
think
that
at
least
what
we
can
get
out
of
this
is
that
we
we
can
sort
of
look
at
this
Delta
between
the
distro
options
and
see
if
there
is
any
defaults
there
that
we
are
currently
missing
and
would
want
to
would
want
to
incorporate
absolutely
so
so
I
had
a
I.
Had
a
brief
look
at
this
brief.
Look
at
this
document
and
I.
Think
our
coverage
in
terms
of
hardening
options
is
quite
good.
B
I
think
that
there
is
like
this.
Is
it
now
this
V
time,
which
is
more
like
on
this?
Reproducible,
builds
right
area
and
I'm
I'm
a
little
bit
on
the
fence
with
that,
because
I
don't
think
that
it's
really
it's
not
really
about
security
hardening.
B
But
it's
more
like
on
this,
like
supply
chain
side,
so
so
so
that
that
seems
to
be
sort
of
part
of
the
Delta
at
least
but
I
think
that
maybe
the
maybe
the
home
for
that
would
be
in,
like
some
other
some
other
guidance,
because
I
know
that
there
are
these
efforts
for
supply
chain
security,
yeah.
D
I
would
also
say
and
I'm
sure
sidish
can
correct
me
on
this.
I
would
also
say
that
you
know
compiler
flag.
Documentation
is
very
light.
I
would
agree
with
you
that
maybe
keep
it
off
this
version,
but,
as
we
continue
to
maybe
expand,
I
would
say
that
it's
definitely
something
to
look
at
because
I
do
know.
D
People
are
into
that
sort
of
thing,
and
it's
not
necessarily
security,
but
trying
to
sort
of
I
mean
reversible
builds
is
something
that
is
important,
so
I
would
all
I'm
saying
is
that
maybe
for
our
second
version,
when
we
look
at
different
things
to
expand
reproducible
bills
would
definitely
not
be
like
a
bad
thing
to
you
know
touch
on,
even
if
that's
just
an
appendix
item.
Another
appendix
item
saying
you
know:
reproducible
bills
are
not
really
considered
a
security
feature,
but
I
mean
it
should
be
happening
anyway,
and
this
is
our
guidance
on
that.
B
B
I
I
sort
of
still
feel
that
it's
like
a
little
bit
of
like
a
different
domain
with
a
little
bit
different
considerations
right
because
it's
not
just
about
configuring
the
compiler.
But
there
is
all
this.
There
are
other
tooling
considerations
as
well
that
go
into
it
right,
so
I'm
I'm,
maybe
maybe
I'm
like
a
little
bit,
worried
about
kind
of
like
feature
creep
in
terms
of
absolutely,
but
what
we,
what
we
cover,
but
but
yeah
I,
agree
that
it
it
sort
of
it's
sort
of
also
relevant
for
security
and
I.
B
B
It
was
yeah,
and-
and
we
also
when
we
when
we
started
this
when
we
started
this
initiative,
we
also
had
this
discussion
around
like
what
do
we?
What
do
we
mean
by
hardening
and
like
in
this
context?
We
are
specifically
focusing
on
the
kind
of
hardening
you
do
through
the
compiler
options
right,
because
we
we
at
least
based
on
the
initial
discussion.
We
didn't
want
to
get
into
this
whole,
like
software
development
time
hardening,
because
that's
again
a
much
larger
area
and
there
are
all
sorts
of
secure
coding
standards
that
are
already
addressing
that.
C
B
Through
through
mechanisms
provided
by
the
compiler
or
Linker
yeah
yeah,
but
but
of
course,
I
think
that
it
also
sort
of
doesn't
hurt
to
acknowledge
that
there
are
these
other
ways
of
doing
hardening
and
and
providing
links
to
relevant
material.
At
least
that's
that's
the
way
I.
We
would
see
it.
D
B
B
B
B
I
think
the
next
one
is
this
G
lib
cxx
assertions
that
took
the
wheeler
was
working
on.
Unfortunately,
he
couldn't
he
couldn't
make
it
today,
but.
B
I
think
that
you
also
Randall-
you
had
reviewed
reviewed
this.
There
was
this
you.
You
brought
that
up
again,
this
question
of
whether.
B
Like
filing
filing
bugs
against
against
Upstream,
if
it
doesn't
compile
with,
is
it
now
specifically
with
this
particular
option?
I
remember
we
had
like
we
started
this
discussion
I
think
last
time,
but
ran
out
of
time.
D
Yes,
yes,
I,
remember
this
discussion.
Yes,
this
is
because
most
in
in
The
Wider
Linings
Community,
there
are
certain
Flags
like
the
g-lib
cxx
flag.
As
the
assertations
flags
I
forget
the
action
I'm
pretty
sure
I
hadn't
yelled
it,
but
I
could
be
wrong,
but
like
that
flag,
for
example,
if
you're,
if
you're
trying
to
compile
on
a
curl
which
should
compile
with
this
and
it
doesn't
compile
with
this,
then
you
probably
have
a
bug
that
you
should
probably
report
to
Upstream.
B
So
so
I
I
do
know.
I
I
do
know
that
at
least
a
few
few
of
the
distributions
they
consider
these
to
be
bugs
right
when
they
package
this,
but.
B
I
I'm
a
little
bit
sort
of
I'm
a
little
bit
sort
of
like
dubious,
whether
it
would
be
sort
of
wise
to
make
sort
of
like
very
general
statements
about
this,
because
I
guess
that,
like
different
projects,
can
have
like
different
priorities
and
I.
Think
that
we
had
like
this
discussion
around
veeam
last
time
and
like
this
CE
language
features
that
Lim
decides
to
use
that
might
not
work
with
this
fortify
hardening
right.
So
I'm
very
I'm.
D
D
I
know
that
from
a
GCC
perspective,
I
know
that
there's
certain
flags
that
in
an
Ideal
World,
should
be
safe
like
a
hundred
percent,
because
these
are
just
like
standards,
we
all
should
comply
to
keyword
should,
but
that's
you
know,
I'm
more
of
a
packager
than
a
participant
in
the
GCC
ecosystem,
so
I
said
maybe
sedish
has
better
or
a
better
position.
But
that's
what
I
understand
that
I
know
that,
like
from
us
in
packaging
land
and
one
of
these
flags
doesn't
work,
then
you
should
Ring
the
Alarm.
D
C
For
for
Philips
cxx
assertions,
I
think
it
should
be
so
it's
a
c
plus
flag
right.
So
as
long
as
we're
filing
bugs
against
C
plus
plus
projects,
it
should
be
fine,
but
then
I
do
think
there
are
projects
that
do
not
enable
assertions
because
they
have.
They
could
have
an
overhead,
a
performance
overhead
but
yeah.
If
it
fails
with
sub
cxx
assertions,
then
it's
likely
a
bug
that
triggered
it
and
and
it's
something
that
should
be
looked
into.
C
Like
45
Source
has
to
deal
with
a
lot
of
kind
of
old-time
Wards,
as
in
for
in
in
the
C
programming
language
and
and
like
the
interplay
between
like
no
extensions
and
and
the
C
standards,
and
so
on.
The
C
plus
plus
ecosystem
I
think
is
a
lot
clearer
in
that
sense,
and
because
of
that,
at
least
in
my
experience,
the
Gypsy
XX
assertions
hasn't
had
the
same
kind
of
problems
that
45
Source
has
had.
C
So
you
should
be
able
to
do
that
as
long
as
it's
it's
limited
to
the
C
plus
ecosystems
ecosystem
and
the
project
kind
of
rejects
the
flag
saying
that
it
has
a
performance
overhead
and
not
because
it
causes
any
correctness,
issues
in
their
code.
D
I
was
I
was
going
to
add
also
in
Pros
that
I
think
that
by
adding
that
Thomas,
my
intent
or
my
part
of
my
question
is
I
see
a
lot
of
discussions.
If
you
want
to
call
them
discussions
that
you
know
could
be
avoided.
If
you
know
that
this
flag
is
a
bug
and
just
go
report
it
to
upstream
and
don't
like
cause
more
issues,
laughs.
B
Yeah
I-
this
sounds
like
this
sounds
quite
like
quite
a
sort
of
like
a
challenging
challenging
topic,
so
I
think
that
I
guess
that
even
for
like
this
specific
flag,
at
least
at
least
like
Dr
Wheeler,
also
had
like
the
option
that
it
wouldn't
make
sense
to
to
suggest
that.
But
of
course,
he's
not
he's
not
here
to
provide
his
provide.
This
use.
I,
I
kind
of
I
gotta
feel
that
this
is
not
like
an
entirely
Consciousness.
D
I
think
I
could
I.
Think
David's
point.
Is
that
how
far
down
this
rabbit
hole?
Do
you
really
want
to
go
because,
like
once
you
do
it
for
one
like
it's
gonna
become
an
issue
on
all
of
or
like
so
I
I.
Think
David's
point
is
that
like
we
should
stay
away
from
it
because
of
the
fact
that
it
would
definitely
increase
maintenance
burden,
and
then
you
start
getting.
You
start
pushing
this
line
of
being
opinionated
I.
Think
that's
his
point.
Yeah
I
think
that's.
D
Why
he's
saying
that
it
would
be
better
right
now
to
keep
it
as
is
which
I
don't
disagree
with,
but
they
said
it
depends
on
kind
of
what
down
the
line.
What
we
want
to
like
deal
with,
because
it's
a
it
is
a
rabbit.
It
is
a
bit
of
a
hole
to
go
into
because
a
lot
of
these
have
and
I
wouldn't
say
this
type
of
nuance,
but
they're
just
they
have
different
nuances,
not
to
mention
some
of
these
flags
have
history.
D
B
Yeah
and
and
I
I
think
that,
like
I,
can
also
see
a
little
bit
this
sort
of
issue
here,
with
the
kind
of
like
the
long
longevity
of
this
guide
right.
So
let's
say
that
we
decide
that
we
should
sort
of
consider
each
option
as
its
own,
whether
or
not
this
is
sort
of
whether
or
not.
This
is
something
that
sort
of
we
could
say
that
it
should
always
be
enabled
whether
that
it
has
some
issues
now,
but
then
again,
then
those
features
mature
and
they
stop
being
issues.
B
You
would
sort
of
need
to
continuously
like
reassess
like
all
these
options
right
correct.
Is
it
now
maturing?
Is
it
now
mature
enough
right
so,
and-
and
maybe
this
kind
of
maybe
this
kind
of
like
burden
is
not
sort
of
worth
it,
because
I,
because
I
think
that
this
guy
still
has
value
in
terms
of
like
this
like
informational
value,
and
you
can
make
decisions
like
you
can
make
these
decisions
on
your
own.
Even
if
we
we
sort
of
don't
have
like
a
strong
stance
on
this.
B
Yeah
I
I
mean
personally
I
would
be
very
happy
to
see
this
being
see
this
being
a
living
document,
but
I
could
also
see
sort
of
you
know
like
the
risks,
with
sort
of
like
snapshots
of
this
being
being
sort
of
becoming
out
date
out
of
date.
B
Right
and
I
would
sort
of
want
to
avoid
that,
like
especially
when
you
know
I'm
myself,
maintaining
a
snapshot
of
this,
which
I
try
not
to
let
become
out
of
date
as
we
do
all
these
valuable
work,
work
work
like
this
and
and
then
I
would
also
see
that
I
would
maybe
see
a
little
bit
like
if
you
sort
of
consider
where
we
spend
the
effort.
B
I
would
maybe
see
more
value
in
spending
the
effort
in
like
keeping
it
as
a
keeping
up
to
date
with
regard
to
sort
of
new,
exciting
features,
because
I
feel
that
this
is
also
an
area
where
there
is
a
lot
of
development
happening
happening
continuously
and
in
a
way.
I
see
this,
as
there
is
like
even
like,
accelerating
development
with
all
of
these
Hardware
assisted
approaches,
both
in
like
x86
processors,
as
well
as
like
arm
processors
right.
B
So
I
I
I
I
I,
saw
now
that
I
saw
now
that
last
week
that
this
control
flow
enforcement
for,
like
Hardy
Hardware,
assisted
control
for
enforcement
for
user
space
looks
to
be
up
to
be
merged
in
Linux
for
the
6.4
merge
window.
So
I
think
that
this
would
also
be
sort
of
a
nice
time
to
a
nice
time
to
look
into
like
adding
the
relevant
options
to
this
guide
and
I.
Think
that
I
I
talked
about
this
a
little
bit
before
that
like
when
I
was
sort
of
prioritizing.
B
This
I
was
primarily
prioritizing
the
software
software
based
approach,
just
because
I
thought
that
that
sort
of
like
where
you
can
get
the
most
widespread
benefit,
but
I
think
it
would
be
really
great
to
sort
of
try
to
make
this
sort
of
comprehensive
in
this
sense
that
we
also
try
to
cover
like
this
platform.
Specific
options
also
continuously
future
right.
So
so
that's
maybe
what
I
sort
of
that
that's
sort
of.
Like
my
my
stance
on
this.
B
And
where
I
would
want
to
spend,
spend
the
time
right,
but
I
again,
I
think
that
this
is
also
like,
depending
on
where
there
is
community
interest
right.
So
if
there
is
community
interest
in
sort
of
like
following
these
developments
on
the
older
options
as
well,
then
of
course
it
would
be
great
if
we
can
keep
it
up
to
date.
But
my
experience
is
just
that,
if
you're,
not,
if
you're,
not
very
centrally
involved
with
working
with
these
options,
it
can
be
quite
cumbersome
to
follow
to
follow
these
developments
continuously.
D
Well,
I
I
I'll
just
say
that
I
think
the
guide
is
great
either
way
you
know
and
I
do
think,
there's
a
need
for
it
in
the
community.
So
I
I
was
the
basis
of
my
question.
B
Yeah
yeah,
but
I
I'm
sort
of
a
little
bit
now
so,
if
I'm,
trying
to
sort
of
like
summarize
this
discussion
like
it
seems
to
be
like
a
little
bit
of
a
contentious
issue,
but
I
think
that
overall,
there
seems
to
be
like
more
reasons
not
to
go
into
like
doing
like
this
specific
recommendations,
either
for
specific
Flags
or
in
or
in
general
and,
like
especially
in
general,
seems
to
be
like
more
problematic
right,
because
because
of
this,
that
that
they
are,
they
are
sort
of
like
real
choices
involved
in
enabling
or
enabling
or
disabling
so
correct
I
would
I
would
maybe
I
I
would
maybe
then
then
not
not
pursue
at
least
at
this
point
in
time,
adding
adding
additional
text
with
regards
to
that.
B
But
but
overall
overall
I
think
that
the
GLI
cxx
assertions
text,
I
mean
I,
I,
think
I
think
it's
clear.
We
should
cover
that
option
in
the
in
the
list
of
options.
B
And
then
there
was
like
this
question
of
like
in
which
ceiling
version
this
became
available
and
I
tried
to
dig
a
little
bit
into
this,
because
it's
not
really
it's
not
really
tied
to
the
compiler
right,
because
it's
a
version
on
the
standard
Library.
Whether
the
standard
Library
supports
these
assertions-
and
you
are
just
passing
through
this
Define.
B
So
so
there
is
this.
Also
for
the
llvm
project,
C
plus
plus
standard
Library,
there's
a
as
far
as
I
can
tell
equivalent
option.
Libc
PPS,
Earth
and
I'm,
like
from
my
side.
I
was
like
mostly
wondering
whether
we
should
cover
that
in
the
same
section
or
whether
we
should
have
a
separate
section
for
that
so
and
I
I
think
that
I'm
not
like
completely
decided
on
that.
But
I
thought
that
it
would
be
good
to
bring
up
here.
B
So
if
there
is
sort
of
features
which
are
more
or
less
equivalent,
but
the
actual
option
differs
between
GCC
and
Zealand,
should
we
sort
of
try
to
combine
them,
or
should
we
just
treat
them
as
separate
options.
C
I
I
was
gonna,
say
the
other
way
to
keep
them
separate
because
the
different
runtimes,
it
might
not
make
sense
to
mix
the
two.
So.
D
C
Like
you
mean
in
the
top
table
kind
of,
say,
gwxx
assertions
for
GCC,
lipstick,
C
plus
plus,
and
then
slash
clang
3.3
lip
C,
plus
plus
correct
okay,.
B
B
So
would
it
make
sense
to
just
directly
refer
to
this,
like
the
C
plus
plus
standard
Library,
by
name
and
the
version
which
I
pursue
matches
the
compiler
version
anyway?
But
but
we
can,
we
can
sort
of
specifically
name
it
name:
the
C
plus
standard
Library
implementation
instead
of
the
compiler.
B
Yeah,
okay,
so
maybe
I
can
maybe
I
can
take
a
stab
at
this
and
provide
some
edits
edit.
Based
on
this
initial
initial
PR
by
by
Dr
Wheeler.
B
I
think
we
have
around
five
minutes
left.
Did
we
have
another.
B
D
B
So
maybe
I
was
maybe
I
was
maybe
I
I
formulated
myself
a
little
bit
confusingly
I
was
like
more
I.
I
was
like
more
considering
this
that
you
know
at
some
point,
I
presume
that
we
would
want
to
publicize
this
guide
when
we
feel
that
it's
in
a
in
a
shape
shape
where,
where
we
feel
that
it's
it
sort
of
not
maybe
like
complete
but
but
but
in
a
shape
where
we
would
actually
want
to
get
some
attention.
B
To
it
and
and
what
I'm
sort
of
what
I'm
sort
of
of
course,
of
course,
the
sort
of
the
like
the
living
document
version
should
be
in
the
GitHub,
but
I'm
also
considering
the
possibility
that,
like
this
information
might
be,
you
know,
quoted
or
you
know,
there's.
D
A
B
That
gets
sort
of
like
archived,
somewhere,
exactly
and
and
then
and
then
I
would
sort
of
consider
that
it
be
becoming
like
beneficial
that,
like
to
text
in
the
guide,
at
least
shouldn't
like
age,
badly
right
right.
A
B
I,
don't
know
I
mean
we
could.
We
could
definitely
consider
consider
that
okay,
but
but
I
think
that
I
I
also,
we
don't
really
have
like
a
clear
sort
of
road
map
either
right
or
we
don't
really
have
like
a
clear
prioritization
yet
so
no.
D
No,
but
if,
if
you
want
my
advice,
just
just
buy
like
some
of
the
other
work,
I've
done,
I
would
I
would
suggest
getting
or
putting
maybe
like
a
due
date.
Okay
I
think
you
said
you
wanted
this
out
to
be
or
this
to
be
out
by
a
certain
date.
So
I
would
say
that
way.
We
can
make
a
call
for
you
know
any
last
Suggestions
by
this
date.
You
know
and
whatnot,
and
now
we
can
start
moving
towards
finalizing
towards
that
date.
So.
B
B
Yeah
I
I
think
that
I
I
think
that
that
might
be.
That
might
be
a
good
good
suggestion.
Maybe
we
we
are
running
out
of
time.
So
maybe
we
should
leave
this
to
another
yes,
another
meeting,
but
but
I
think
that
also
we
have
sort
of
maybe
some
things
that
we
sort
of
should
get
done
before,
like
the
version
1.0
right.
So
we
have
like
this
original
Google
doc
draft,
which
we
I
think
are
still
working
through
right.
B
What
like
one
option
at
the
time
and
I
think
it
sort
of
makes
sense
to
at
least
make
sure
that
we
can
incorporate
anything
of
value
from
there
as
well
as
this
the
effort
you
started
with
the
with
the
distribution,
specific
options
right,
so
we
have
like
this
sort
of
clear
sources
of
this
material
that
we
can.
B
We
can
try
to
work
through,
but
I
think
that
I
I,
I
I
think
that
yeah
I
I
think
that
just
process
wise
I
I,
like
this
idea
to
to
have
to
like
aim
for
some
kind
of.
B
Yeah
I
I-
let's
let's
I,
think
we
are
out
of
time
now.
But
but
let's
keep
this
in
mind
and
and
bring
it
up
in
like
a
future
meeting
and
and
think
about
this.
D
B
About
this,
what
to
do?
Okay,
but
thanks
for
thanks
for
a
very
good
discussion,
I'll,
try
to
summarize
also
these
last
Parts
in
the
meeting,
notes
and
I
wish
you
all
a
very
good,
very
good
day
and
I
hope
to
talk
to
you
all
in
two
weeks
time.
Thank
you.
Thank
you.
Everyone.