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.
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
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
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
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
