Rob Browning writes:
> Oh, and in addition to wondering about using ttyname_r when it's
> available, if we did that, or even if we didn't, I could also see moving
> the shared code to a shared helper, but I was just starting with a
> "simpler" proposal (to avoid the crash).
Attached is a variant
Rob Browning writes:
> Hmm, just to clarify. *I* didn't write any of that code, and hadn't
> considered it carefully yet -- I just replicated the existing
> scm_ttyname() code from posix.c, i.e. this just does what we already do
> there.
Oh, and in addition to wondering about using ttyname_r wh
Maxime Devos writes:
> You are ignoring out-of-memory situations (from strdup), instead of raising
> an out-of-memory exception.
Hmm, just to clarify. *I* didn't write any of that code, and hadn't
considered it carefully yet -- I just replicated the existing
scm_ttyname() code from posix.c, i.
There is nothing that forbids doing that, to my knowledge (do so the same way
you would call other libc functions). But remember to check for ENOMEM/NULL
(and eventually free it).
Something to keep in mind though (not specific to malloc): if you put the
pointer in some object, and the record ty
You are ignoring out-of-memory situations (from strdup), instead of raising an
out-of-memory exception.
It’s rather unclear what you are taking the scm_i_misc_mutex for.
You are also not taking the appropriate port lock (look for
scm_i_port_table_mutex – savannah git is down and I don’t have a
