freenode/#clasp - IRC Chatlog
Search
0:25:51
drmeister
I was looking it up a while ago when I was trying to figure out how to access debug info.
0:26:38
Bike
the header says it's source-compatible with nongnu, so i guess it can unwind out of signal handlers too.
0:29:40
Bike
yeah i meant the apple one. here. https://opensource.apple.com/source/libunwind/libunwind-35.3/include/libunwind.h.auto.html
0:29:43
drmeister
My understanding is that libunwind uses DWARF-like info to describe the stack unwinding information - but that is it.
0:30:29
drmeister
Yeah - that https://opensource.apple.com/source/libunwind/libunwind-35.3/include/libunwind.h.auto.html was what I was looking at months ago.
0:32:14
Bike
well, since it says it's source compatible i'm going to imagine that things are fine in that respect, and the problems i'm seeing are something that won't involve the unwinder, because i really don't want to deal with the unwinder
0:39:52
drmeister
They are supposed to be a scientific programming language - I'm surprised they have done as little as they have.
2:32:28
Bike
makecontext might be a good thing to do except all those functions were removed from posix how super
2:48:37
drmeister
I read that there were several functions removed a few years ago that emacs needed. I thought it might have been at that point.
7:34:46
frgo
Bike: The Cray T90 seems to natively support FPEs as traps ;-) https://users.757.org/~ethan/comp_cray/MANPAGES/2080_10.0/04_pgs_174-409.pdf
7:41:11
frgo
Bike: Not exactly knowing what you now want to achieve, but I also found this: https://linuxgazette.net/issue40/trap.txt
8:00:43
beach
I have a C++ question related to a discussion about different strategies for passing arguments. If you have the syntax type fun (type &argument) {argument++;}, does that mean that if you do fun(x), then x will have its value incremented? And, with that syntax, are there any restrictions on the kind of arguments you can have, i.e., can you have fun(x + 2)?
8:04:19
heisig
beach: If I recall correctly, C++ references are just syntactic sugar for pointers. So argument++ translates to (*argument)++.
8:05:30
heisig
So x in your example will have its value incremented, and there are no restrictions on using references as arguments or return values.
8:07:08
d4ryus
it would not compile: invalid initialization of non-const reference of type ‘int&’ from an rvalue of type ‘int’
8:17:34
beach
So call-by-value and call-by-reference are not opposite strategies, but they also can't coexist. Call-by-value must accept any r-value so it is mandatory that the resulting value be passed by sticking it in a location belonging to the callee. And no side effects on that location can be visible in the caller. Call-by-reference passes a reference to a location, which restricts the possible arguments to being l-values.
8:22:09
beach
Interestingly, early versions of Fortran (which used call-by-reference uniformly) allowed a call such as fun(10), and if fun were defined to increment its parameter, then 10 would be 11 after the call.