On Mar 24, 2022, at 8:16 PM, Mouse wrote:
> Nested functions are not closures, or at least not what I know as
> closures. A nested function pointer (conceptually) goes invalid as
> soon as anything it refers to goes out of scope, or at the latest as
> soon as its smallest enclosing block exits
Den 2022-03-22 kl. 18:47, skrev Koning, Paul:
On Mar 22, 2022, at 1:21 PM, Greg A. Woods wrote:
At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse
wrote:
Subject: pcc [was Re: valgrind]
I've been making very-spare-time progress on building my own
compiler on and off for some years now
Den 2022-03-22 kl. 18:49, skrev bch:
On Tue, Mar 22, 2022 at 10:21 Greg A. Woods wrote:
At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse
wrote:
Subject: pcc [was Re: valgrind]
>
> >> I've been making very-spare-time progress on building my own
> >>
On Thu, Mar 24, 2022 at 11:16:58PM -0400, Mouse wrote:
> > The conclusion over the past ~25 years has been that there isn't;
> > qsort and things like it work "well enough" and real uses for
> > closures that really motivate the feature come up rarely enough that
> > it doesn't happen.
>
>
On Fri, 25 Mar 2022 at 10:03, Reinoud Zandijk wrote:
> > I guess they can think so because nested functions are a gcc extension.
> > Quite a useful one, I think, having been taught programming with Algol
> > 68 which of course does have nested functions; but an extension
> > nevertheless.
>
>
On Tue, Mar 22, 2022 at 06:17:50PM +0100, Rhialto wrote:
> On Sun 20 Mar 2022 at 23:17:57 -0400, Mouse wrote:
> > clang is - or at least was last I checked - under the impression that
> > nested functions are little-used and thus are not worth supporting.
>
> I guess they can think so because
> [...] said, moving to fat function pointers on machines that don't
> already use them is a real ABI change and therefore a big deal; but
> it could be done if there were a compelling argument to justify going
> through all the associated dark rituals.
Or as a private experiment, in which
On Tue, Mar 22, 2022 at 09:16:36PM -0400, Mouse wrote:
> Indeed, you can have different sizes for pointers to different object
> types, too. I _think_ pointers to different function types can have
> different sizes, but I'm less certain of that. (There would be little
> point, since all
Den 2022-03-23 kl. 21:55, skrev Greg A. Woods:
At Wed, 23 Mar 2022 20:56:27 +0100, Anders Magnusson
wrote:
Subject: Re: pcc [was Re: valgrind]
Den 2022-03-23 kl. 19:37, skrev Greg A. Woods:
Heh. I would say PCC's generated code doesn't compare to either modern
GCC or LLVM/Clang's output.
I
At Wed, 23 Mar 2022 20:56:27 +0100, Anders Magnusson
wrote:
Subject: Re: pcc [was Re: valgrind]
>
> Den 2022-03-23 kl. 19:37, skrev Greg A. Woods:
> >
> > Heh. I would say PCC's generated code doesn't compare to either modern
> > GCC or LLVM/Clang's output.
> >
&
Den 2022-03-23 kl. 19:37, skrev Greg A. Woods:
At Tue, 22 Mar 2022 17:47:55 +, "Koning, Paul" wrote:
Subject: Re: pcc [was Re: valgrind]
Out of curiosity: how does PCC code quality compare with that of
GCC and (for targets that it supports) Clang?
Heh. I would say PCC's gene
At Tue, 22 Mar 2022 17:47:55 +, "Koning, Paul" wrote:
Subject: Re: pcc [was Re: valgrind]
>
>
> Out of curiosity: how does PCC code quality compare with that of
> GCC and (for targets that it supports) Clang?
Heh. I would say PCC's generated code doesn't compare to eit
> On Mar 22, 2022, at 1:21 PM, Greg A. Woods wrote:
>
> At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse
> wrote:
> Subject: pcc [was Re: valgrind]
>>
>>>> I've been making very-spare-time progress on building my own
>>>> compiler on and off fo
>> Can't you? Does C require function pointers to have the same type,
>> or compatible structure, as data pointers?
> No, I don't think that it does.
Correct.
> You could have different sizes for those.
Indeed, you can have different sizes for pointers to different object
types, too. I
ory leak. They are both reachable memory
> > allocations.
> >
>
> Yah: Reachable is what valgrind reports too, but, it still flags
> it as "lost". My point being that I'm glad we have sanitizers, but,
> you still need valgrind for some common use-cases.
Yeah a
> On Mar 22, 2022, at 5:11 PM, Rhialto wrote:
>
> On Tue 22 Mar 2022 at 20:59:05 +, Koning, Paul wrote:
> ...
>> If it does, that would mean you can't get a pointer to a nested
>> function, which is no different from the C++ rule that you can't get a
>> (plain function) pointer to a
On Tue 22 Mar 2022 at 20:59:05 +, Koning, Paul wrote:
> > But these sorts of strategies require bigger function pointers, which
> > you basically can't do in C.
>
> Can't you? Does C require function pointers to have the same type, or
> compatible structure, as data pointers?
No, I don't
On Tue, 22 Mar 2022, Joerg Sonnenberger wrote:
Am Mon, Mar 21, 2022 at 11:09:41PM + schrieb RVP:
Sanitizers are OK, but, they don't seem to work in some cases:
Neither case is a memory leak. They are both reachable memory
allocations.
Yah: Reachable is what valgrind reports too
> On Mar 22, 2022, at 4:53 PM, Rhialto wrote:
>
> On Tue 22 Mar 2022 at 17:46:49 +, Koning, Paul wrote:
>> I don't believe ALGOL implementations needed executable stacks to implement
>> nested functions, for example.
>
> No, a common way to do it (as in the Dragon Book), if I recall
>
On Tue 22 Mar 2022 at 21:53:37 +0100, Rhialto wrote:
> No, a common way to do it (as in the Dragon Book), if I recall
> correctly, the address of the function combined with a stack frame
> pointer. And nested functions keep a static link to the lexically
> enclosing scope, or alternatively a
On Tue 22 Mar 2022 at 17:46:49 +, Koning, Paul wrote:
> I don't believe ALGOL implementations needed executable stacks to implement
> nested functions, for example.
No, a common way to do it (as in the Dragon Book), if I recall
correctly, the address of the function combined with a stack
> On Mar 22, 2022, at 2:23 PM, Mouse wrote:
>
>
> [EXTERNAL EMAIL]
>
>>> I found an interesting article about why they're bad...
>>>
On Tue, Mar 22, 2022 at 10:21 Greg A. Woods wrote:
> At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse
> wrote:
> Subject: pcc [was Re: valgrind]
> >
> > >> I've been making very-spare-time progress on building my own
> > >> compiler on and off for some
>> I found an interesting article about why they're bad...
>> https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my
> That's a good argument for why GCC's implementation of nested functions is b$
What security blunder is that? Based on your next line, I'm going to
assume it's
> On Mar 22, 2022, at 1:17 PM, Rhialto wrote:
>
> On Sun 20 Mar 2022 at 23:17:57 -0400, Mouse wrote:
>> clang is - or at least was last I checked - under the impression that
>> nested functions are little-used and thus are not worth supporting.
>
> I guess they can think so because nested
At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse
wrote:
Subject: pcc [was Re: valgrind]
>
> >> I've been making very-spare-time progress on building my own
> >> compiler on and off for some years now; perhaps I'll eventually get
> >> somewhere. [...]
>
On Sun 20 Mar 2022 at 23:17:57 -0400, Mouse wrote:
> clang is - or at least was last I checked - under the impression that
> nested functions are little-used and thus are not worth supporting.
I guess they can think so because nested functions are a gcc extension.
Quite a useful one, I think,
> PS. Mouse's email server will, as usual, reject mails sent from SDF I
> think... ;)
I had a look at my logs.
This is true at present, but it's mx.sdf.org's fault. It's dropping
the connection 50 seconds into my banner delay, a point at which the
SMTP specs say any client-side timeout should
Am Mon, Mar 21, 2022 at 11:09:41PM + schrieb RVP:
> Sanitizers are OK, but, they don't seem to work in some cases:
Neither case is a memory leak. They are both reachable memory
allocations.
Joerg
oid)
{
char* p = mkbuf(1000);
memset(p, '\0', 1000);
return 0;
}
$ clang -Wall -g -fsanitize=address -o 2 static_alloc.c
$ env ASAN_OPTIONS=detect_leaks=1 ./2
$
---
Valgrind, of course, detects both those leaks.
-RVP
PS. Mouse's email server will, as usual, reject mails sent from SD
Le Mon, Mar 21, 2022 at 08:54:43AM -0400, Mouse a écrit :
> >> I've been making very-spare-time progress on building my own
> >> compiler on and off for some years now; perhaps I'll eventually get
> >> somewhere. [...]
> > Have you looked at pcc? http://pcc.ludd.ltu.se/ and in our source
> >
>> I've been making very-spare-time progress on building my own
>> compiler on and off for some years now; perhaps I'll eventually get
>> somewhere. [...]
> Have you looked at pcc? http://pcc.ludd.ltu.se/ and in our source
> tree in src/external/bsd/pcc .
No, I haven't. I should - it may well
>> But it's less a lack of interest and more an unwillingness to ignore
>> the licensing issues. `Modern' GCC is licensed under the GPLv3.
> So? That doesn't affect the licensing of code compiled by gcc.
Doesn't it? I can't tell - that's, basically, the problem. Your
opinion that it doesn't
Mouse wrote:
> I've been making very-spare-time progress on building my own compiler
> on and off for some years now; perhaps I'll eventually get somewhere.
> (It's something I want to do regardless; there are some directions I'd
> like to take the language to see what results)
Have you
t-in sanitizers
>> in modern GCC useful for approximating the functionality of valgrind
>> on NetBSD.
>
> To some extent, perhaps.
>
> But it's less a lack of interest and more an unwillingness to ignore
> the licensing issues. `Modern' GCC is licensed under the GPLv
>> But it's less a lack of interest and more an unwillingness to ignore
>> the licensing issues. `Modern' GCC is licensed under the GPLv3.
> try clang, which usually has newer/better sanitizers.
clang is - or at least was last I checked - under the impression that
nested functions are
> But it's less a lack of interest and more an unwillingness to ignore
> the licensing issues. `Modern' GCC is licensed under the GPLv3. I
try clang, which usually has newer/better sanitizers.
>> Perhaps I just need a better approach
> I know you've previously expressed a lack of interest in such things
> when we've talked previously, but I've found the built-in sanitizers
> in modern GCC useful for approximating the functionality of valgrind
> on NetBSD.
To so
ity
of valgrind on NetBSD.
For example, -fsanitize=leak can log leaks at runtime.
http://wiki.netbsd.org/projects/project/valgrind/ sketches a project
for porting valgrind, but gives tech-kern as its contact address.
Surely that's not right?
In passing, the difficulty will vary, substantially I expect, with the
port(s) it's targeted for. I spent a while trying to implement
40 matches
Mail list logo
