On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
> Replacing malloc is just as invalid from a strict standard compliance
> perspective, so *shrug*
Why is that?
We have e.g. shells/standalone-tcsh that does it. Is it broken now?
Martin
On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote:
> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
> Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
> fail if the app provides its own malloc()
> >
> > On Mon, Jul 13, 2020 at 03:05:17PM -070
At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
fail if the app provides its own malloc()
>
> On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> > I think it is the following change (and perha
On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> I think it is the following change (and perhaps more similar/related
> changes) which breaks static linking of applications which wish to
> supply their own implementation of malloc(), and which call, e.g.,
> fork():
I consider it a
I think it is the following change (and perhaps more similar/related
changes) which breaks static linking of applications which wish to
supply their own implementation of malloc(), and which call, e.g.,
fork():
This is because fork() now calls _malloc_prefork(), and if the
application's replacemen
>> if (ch == t.c_cc[VINTR]) {
>> } else {
>> if (ch == t.c_cc[VQUIT]) {
>> } else {
>> if (ch == t.c_cc[VKILL]) {
>> } else {
>> }
>> }
>> }
> For this, I would prefer
> if (
At Mon, 13 Jul 2020 09:48:07 -0400 (EDT), Mouse
wrote:
Subject: Re: style change: explicitly permit braces for single statements
>
> Slavishly always
> adding them makes it difficult to keep code from walking into the right
> margin:
These days one really should consider the right margin to be a
On 2020-07-13 17:52, Paul Goyette wrote:
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do
On Mon 13 Jul 2020 at 09:48:07 -0400, Mouse wrote:
> I'd actually recommend one exception, that being the else-if chain: if
> the dependent clause after an else is a single statement, and it is an
> if statement, then, depending on the semantic relationship of the inner
> if's test to the enclosing
>> I find the braces pure visual clutter in the latter.
> What really bugs me is when my code winds up with a security fail because I $
Yeah, that bugs me too.
But "don't be careless" isn't something codifiable enough to go on a
list of style rules such as this one.
> â??Because it looks betterâ
On Mon, Jul 13, 2020 at 09:18:18AM -0400, Ted Lemon wrote:
> On Jul 13, 2020, at 9:13 AM, Mouse wrote:
> > . I find the braces pure visual clutter in the latter.
>
> What really bugs me is when my code winds up with a security fail because I
> wasn’t careful.
If only we had compilers that coul
On Jul 13, 2020, at 9:13 AM, Mouse wrote:
> . I find the braces pure visual clutter in the latter.
What really bugs me is when my code winds up with a security fail because I
wasn’t careful. I’ve had this happen maybe three or four times in my career,
which isn’t too bad, but it’s hard to cat
> Personally I don't think there's any good excuse for not always
> putting braces around all single-statement blocks.
Well, you may not think it good, but I prefer
if (x < 0) return(n);
to
if (x < 0) { return(n); }
. I find the braces pure visual clutter in the latter.
I als
> On 20-07-12 10:01, Luke Mewburn wrote:
> | I propose that the NetBSD C style guide in to /usr/share/misc/style
> | is reworded to more explicitly permit braces around single statements,
> | instead of the current discourgement.
> |
> | IMHO, permitting braces to be consistently used:
>
15 matches
Mail list logo
