IRC channel logs

2025-05-05.log

back to list of logs

<lechner>Arsen / Actually, I misspoke somewhat: I currently call Glib's ptrace library function. Should I be writing a C wrapper?
<Arsen>lechner: glibc you mean?
<Arsen>and yes, I'd probably write a wrapper that returns somehow the errno
<old>you don't need to reset errno between ptrace calls?
<old>On error, all requests return -1, and errno is set to indicate the error.
<old>the only case is with PEEK
<old> Since the value returned by a successful PTRACE_PEEK* request may be -1, the caller must clear errno before the call, and then check it afterward to determine whether or not an error occurred.
<old>but then you have: Contrary to the normal rules, the glibc wrapper for ptrace() can set errno to zero.
<old>on Linux, the glic define `errno' as a macro like so: #define errno *__errno_location()
<old>so if you want, you can get the address of errno for a thread by calling __errno_location
<old>Not tested: https://paste.sr.ht/~old/5910a351e0bdf79b0650cf168f9ca7a0bf214c4f
<wingo>o/
<lechner>old / Arsen's point is, I think, that Glibc changed the API. i could indeed write a small library, if you want to call it that, to expose the actual API, which always uses -1 for errors and delivers values returned by PTRACE_PEEK* in the location pointed to by parameter 4. See "library/kernel differences" https://www.man7.org/linux/man-pages/man2/ptrace.2.html#NOTES
<Arsen>I was trying to say that if you did something like (ptrace ...) (get-errno) you'd have written a bug
<Arsen>(because the execution between ptrace and get-errno may well change errno)
<Arsen>hence you need a new wrapper (preferably one calling the libc one) that somehow preserves errno somewhere
<Arsen>sorry for miscommunicating
<lechner>why would errno change, please?
<old>lechner: If you take the above code I shown, you can store 0 in errno before calling ptrace and then read the value back to see if there was an error
<Arsen>I see no reason to believe that going back to scheme and then the native implementation of get-errno fails to avoid library calls
<Arsen>s/fails to avoid/manages to avoid/
<Arsen>and errno is global state..
<Arsen>messy thing
<old> https://paste.sr.ht/~old/aa9f989f45cbb25c98ab70aac4510e8e70931f3b
<lechner>Arsen / i am not sure that's any different than using Glibc from any other language
<old>I guess the only possible way is if FFI or Guile itself change errno in between
<Arsen>it is not different to any other libc interaction, no
<lechner>old / yeah, i am going to try that. thank you
<Arsen>doesn't make it fine in guile, it'd be wrong in C even ;)
<old>maybe you would need to disable async marks also
<old>Arsen: How could this be wrong in C?
<old>Setting errno to 0 and then calling ptrace is actually what's suppose to be done
<Arsen>it is certainly wrong to call ptrace, call arbitrarily much code inbetween, and then check errno
<lechner>who is calling code in between?
<Arsen>and going from FFI to guile to FFI to errno is doing exactly that
<old>ofc, you are suppose to: errno = 0; ret = ptrace(...); if (errno)
<lechner>that's above my paygraed
<lechner>grade
<old>right it might in Guile do that
<lechner>it would be easy for me to write a small library if I can figure out how to make it thread-safe
<Arsen>errno is thread local, if you mean thread-safe wrt access to errno
<lechner>Arsen / i'm not sure. it was just a thought
<lechner>old / in your code, should it be int or long?
<lechner>the return type
<old>long
<old>sorry
<old>ptrace returns a word
<lechner>i even struggle to interpret params 3 and 4 as pointers but have been going back and forth https://bpa.st/GXZQ
<old>you are probably better to write a C wrapper if you can
<old>otherwise it will be very fragile in Guile and will certainly break a some point
<lechner>FFI makes syscalls in the trampoline?
<lechner>i guess library calls
<lechner>Hi, anyone else think that file names are bytevectors, not strings?
<lechner>Arsen / old / are any of the traditional errno mechanics safe in Guile? how should I report error conditions from my small ptrace library, please?
<sham1>Raise a condition, most likely
<lechner>ok, maybe that's better. i wasn't going to do any Guile but only expose the actual kernel interface
<rlb>lechner: they are (as are user/group names, env vars, etc.), and guile eventually needs a solid story there -- for now, the main option you hae is to run guile with the ctype set to latin-1 (iso8859-1) and handle conversions to/from the real locale yourself, I think?
<rlb>"you have"
<rlb>(conversions, where you want/need them)
<rlb>lechner: there *is* a broader discussion now https://codeberg.org/scheme/r7rs/issues/51
<rlb>*and* a proposed solution: https://codeberg.org/scheme/r7rs/issues/51#issuecomment-2460851
<rlb>Oh, and potentially related: https://srfi.schemers.org/srfi-207/srfi-207.html -- I have an implementation of that for guile now, including reader/writer support.
<rlb>But even with both of those, we'd still have to make guile api decisions/changes.
<lechner>rlb / okay, thanks!
<lechner>Hi, what's an easy way to find the first zero in a bytestring of uint8, please?