[HN Gopher] Defer Reference Implementation for C
___________________________________________________________________
Defer Reference Implementation for C
Author : cyber1
Score : 31 points
Date : 2020-09-30 19:55 UTC (3 hours ago)
(HTM) web link (gustedt.gitlabpages.inria.fr)
(TXT) w3m dump (gustedt.gitlabpages.inria.fr)
| neostrauss wrote:
| Presumably GCC (and I believe Clang)'s __cleanup__ attribute
| provides this functionality already in most cases?
|
| Any platform where Clang and GCC aren't supported is a platform
| where this style of code shouldn't be used, no?
| dnautics wrote:
| thing is, you'll still want errdefer.
| saagarjha wrote:
| I hate commenting on this usually, but please please please don't
| touch letter-spacing if you want people to be able to read your
| text! Doubly so if these are literally _headers_ and using a
| fairly ugly, squat font...
| cozzyd wrote:
| Looks fine for me (Firefox on Linux on a 1440p monitor).
| jart wrote:
| Looks fine to me. Post a screenshot of your desktop. I'd love
| to learn more about how Courier New spaced -.1em could be
| rendered illegibly.
| saagarjha wrote:
| This is what the page looks like on my computer:
| https://i.imgur.com/FX3o2EI.png. I wouldn't call it
| "illegible" but it's certainly unpleasant to read.
| jart wrote:
| The C language shouldn't need a defer statement keyword, because
| it's so trivial to implement using an asm() macro that overwrites
| the return address.
|
| Using a macro is more succinct: const char *s =
| gc(xasprintf("%s/%s", dir, name));
|
| Than what's being proposed: char *s =
| xasprintf("%s/%s", dir, name); defer free(s);
|
| See this x86 reference implementation of defer() and gc().
| https://gist.github.com/jart/aed0fd7a7fa68385d19e76a63db687f...
| That should just work with GCC and Clang. That code is originally
| from the Cosmopolitan C Library
| (https://github.com/jart/cosmopolitan) so check it out if you
| like the Gist and want more!
|
| Please note the macro operates at function call boundaries rather
| than block scoped. I consider that a feature since it behaves
| sort of like a memory pool. Having side effects at the block
| scope level requires changing compilers, the language itself, and
| it would cause several important gcc optimization passes to be
| disabled in places where it's used.
| grok22 wrote:
| I think perhaps this is the wrong way to look at it -- having
| it as a standard way to do things built into the language
| simplifies this (not everybody needs to know tricks) and also
| most likely will be more portable across platforms.
| saagarjha wrote:
| While interesting, such a construct is obviously unsuitable for
| inclusion in the C standard nor can it be relied upon when
| writing portable code.
| jart wrote:
| I never proposed that some code I posted to Gist be part of
| the C standard. I'm flattered however that folks are
| considering it for that purpose!
| mayoff wrote:
| Nobody's proposing your code for the C standard. The
| original article is proposing an addition to the standard.
| Your comment argues that programmers don't need the
| addition to the standard because there is a non-standard,
| non-portable hack. That is not a good argument against an
| addition to the standard.
| jart wrote:
| The onus is on the proposer. C is simple and should stay
| that way. If someone is proposing the C language needs to
| change, which is about the most conservative language
| there is when it comes to adopting change, then that
| person should have good arguments as to why there's no
| other way. Otherwise it should go in C++. If whipping up
| a few lines of asm for my local architecture solves the
| problem, then that weakens the proposal. Maybe they
| should be focusing instead, on standardizing the RMS
| notation for the asm() keyword which makes this epic hack
| possible.
| neostrauss wrote:
| Looks extremely cool. Presumably __cleanup__ is more robust in
| a GCC environment though?
| cozzyd wrote:
| Can this be made to work on ARM as well?
| liuliu wrote:
| You need to disable inlining. __builtin_frame_address can
| give surprising addresses when inline enabled. The code
| itself is likely not be wrong, but you won't confined to the
| lexical scope as if you see in the code (the defer can be
| triggered when the parent function returned).
|
| Disclaimer: I haven't looked at the code too closely.
| jart wrote:
| Inlining gives you the ability to control how "pooled" the
| free() operations end up being. You don't need to disable
| inlining. You just have to be mindful of how much power
| this macro gives you. For example, if a function that calls
| gc() is being called from within a loop, then it's a good
| idea to make sure that function isn't static.
| warmwaffles wrote:
| ARM implementation would be fun to look at as well.
| jart wrote:
| Yes, absolutely! In the case of Arm, it would need to be a
| pure macro (i.e. no external __defer function) since ARM ABI
| uses a register to store the return address. Then the unwind
| code would need to save the return registers x0 to x7 each
| time it calls free() or whatever function is being deferred.
| I'd write it for you, but I don't use ARM.
| est31 wrote:
| The original goal of C was to allow writing programs in a
| platform independent way, i.e. without having to write
| different code for different arches.
|
| Also, there is no inline assembly support in standard C, just
| in various compilers.
| saagarjha wrote:
| Interestingly, C++ does have an asm declaration.
| est31 wrote:
| It exists, but the meaning is implementation defined.
|
| https://eel.is/c++draft/dcl.asm
| shoo wrote:
| tangential suggestion: if the the first line of the
| cosmopolitan README after the title was the description "fast
| portable static native textmode executable containers" then
| that would help newcomers more quickly understand what the
| project is about. i skim-read through the README and was still
| fairly puzzled about what the purpose of a cosmopolitan was
| before i saw that description hiding in the margin.
| jart wrote:
| Thanks for the feedback! The README has now been updated: htt
| ps://github.com/jart/cosmopolitan/commit/fd22e55b42503093...
| It could use more work though. See also
| https://justine.storage.googleapis.com/ape.html and the HN
| thread about it last month:
| https://news.ycombinator.com/item?id=24256883
| warmwaffles wrote:
| That gist looks interesting. You said it is from cosmopolitan,
| I assume it has the same license as it. Thinking about toying
| with that defer implementation. Looks fun.
|
| Though I still do it all manually, and am looking for ways to
| automate it.
| jart wrote:
| The Gist is now updated with an ISC license. So it's very
| permissive. Enjoy! Feel free to contact me anytime too, if
| you get interested in hacking on this stuff.
___________________________________________________________________
(page generated 2020-09-30 23:01 UTC)