On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix
> real-world bugs that would be caused if Clang becomes overly pedantic by
> default here. And the probability of introducing real-world bugs is
> essentially zero.
FWIW,
Hello Weimin,
> The main use-case for this format are
> "online" debugging tools like stack tracers
I'll appreciate anything that can help producing a universally working
backtrace for C, since experience (e.g. from Lisp, Java, Python) has
shown that such a backtrace function can tremendously imp
On Tue, 15 Nov 2022, Sam James wrote:
On 13 Nov 2022, at 00:43, Paul Eggert wrote:
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, he
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the wrong
prototype? Is it plausible that any such security flaw exists?
CVE-2006-1174 is a possibly reasonable example.
CVE-2006-1174 is not an example, because no p
On Tue, Nov 15, 2022 at 3:27 PM Paul Eggert wrote:
>
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would
This patch adds two new modules to gnulib, related to the Simple Frame
format (SFrame) recently introduced in binutils [1].
The SFrame format (Simple Frame format) represents the minimal necessary
information for stack backtrace and it is stored in the .sframe section.
The format's detailed defini
On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert wrote:
>
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report e
On 2022-11-15 11:27, Jonathan Wakely wrote:
Another perspective is that autoconf shouldn't get in the way of
making the C and C++ toolchain more secure by default.
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the
On Tue, 15 Nov 2022 at 19:08, Paul Eggert wrote:
>
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report err
On 2022-11-15 06:50, Jonathan Wakely wrote:
Could you clarify what you mean, with a concrete example? Surely as
long as errors are reported on stderr and the compiler exits with
non-zero status, that's an acceptable way to report errors?
Not if the "error" is harmless as far as Autoconf is conc
On Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote:
>
> On 2022-11-14 04:41, Aaron Ballman wrote:
> > it's generally a problem when autoconf relies on invalid
> > language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And C
Pádraig Brady wrote:
> > +sc_unportable_grep_q:
> > + @prohibit='grep -q' halt="unportable 'grep -q', use >/dev/null instead"
> \
> > +$(_sc_search_regexp)
> > +
>
> Note the above isn't equivalent as -q will exit early upon first match
> (as defined by POSIX)
In most of the cases, the
> On 15 Nov 2022, at 13:30, Zack Weinberg wrote:
>
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>>
>>> Although there will be problems with people who run "./configure
>>> CFLAGS='-Werror'", that sort of usage has always been problem
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply contin
Am Di., 15. Nov. 2022 um 13:46 Uhr schrieb Ondrej Valousek
:
> > This would correspond to a mode attribute of "--rwx" according to the
> > above statement,
> Well I do not think so as the RFC also states that EVERYONE@ means literally
> everyone (including group and owner), so the above examp
On 01/11/2022 08:12, Simon Josefsson via Gnulib discussion list wrote:
Bruno Haible writes:
Hi Simon,
+ @if ! indent --version 2> /dev/null | grep -q 'GNU indent'; then\
As mentioned in the Autoconf manual [1], the grep option '-q' is not portable.
E.g. on Solaris 10:
$ echo | grep
> This would correspond to a mode attribute of "--rwx" according to the
> above statement,
Well I do not think so as the RFC also states that EVERYONE@ means literally
everyone (including group and owner), so the above example would indeed return
rwxrwxrwx.
Anyhow, would the code I offered
Am Di., 15. Nov. 2022 um 10:17 Uhr schrieb Ondrej Valousek
:
> I mean from RFC8881:
> " The server that supports both mode and ACL must take care to synchronize
> the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have
> respective who fields of "OWNER@", "GROUP@", and "EVERYONE@"
Am Di., 15. Nov. 2022 um 10:17 Uhr schrieb Ondrej Valousek
:
> > * If an ALLOW entry has any mask bits set that don't correspond to the UNIX
> > rwx permissions, we don't have a trivial ACL.
> Do we really have to do this?
Of course. For example, an ACL that grants ACE4_WRITE_ACL to anyone
beyond
> * If an ALLOW entry has any mask bits set that don't correspond to the UNIX
> rwx permissions, we don't have a trivial ACL.
Do we really have to do this?
I mean from RFC8881:
" The server that supports both mode and ACL must take care to synchronize the
MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bi
20 matches
Mail list logo
