On Wed, Oct 25, 2017 at 11:44:28PM -0500, Reepca Russelstein wrote: > errno stubbornly refuses to change from 0 no matter what kind of > ridiculous shenanigans I get up to, (-12938 -12932 kill, for example). > Considering C libraries' annoying tendency to communicate all useful > debugging information through that one point, that's pretty > frustrating. The C functions themselves return -1 as is expected, but > errno refuses to change, even when I erroneously use functions from > libc.fs itself (example: s" /argle" s" /blargle" link). > > So now I'm stuck trying to figure out why my ptraces are randomly > failing despite using the exact same arguments without knowing what > the error even is. I'm on the latest git checkout presently. > > Any ideas? My first guess would be that something in gforth itself is > overwriting errno routinely... > > Oh. Well then, turns out the problem only occurs when interactively > checking errno - when it's in a compiled definition it works fine.
I guess that, in your usage (a use case would be nice for reproducing the problem), Gforth calls some other function in between that sets errno to its error result. Solutions: 1) Documentation: We would have to document errno first, and it's better to eliminate problems than to document them. 2) Save and restore errno in the text interpreter (somewhere around the EXECUTE). This is probably the best approach. 3) Provide a wrapper that calls a C function and produces errno. I have implemented solution 2, but am too lazy to design a proper test case, so please go ahead and try it. - anton
