u/xsdgdsx

A friend of mine bought the FITTDYHE fabric glue from Amazon. The moment I smelled it being applied, the scent reminded me of the highly flammable/sometimes toxic solvents from common industrial adhesives (thinking xylene, toluene, MEK). Given that the warnings on the back of the tube were extremely vague, I started looking for an SDS and couldn't find one. Then I started looking for… any content information at all and couldn't find _any_. It just says "Material: resin" and that's it.

Do y'all have any rules of thumb for determining the approximate safety of adhesives that don't include an SDS? I'm going to assume that the solvent is likely both toxic and highly flammable. Is it valid to be concerned that it might be carcinogenic?

(The back of the tube shows:
Technical data
Appearance: translucent liquid
Solid content: 30% - 50%
Hardness after curing: 65-80A
Surface drying time: 3 minutes
Complete drying time: 24-48 hours
Storage: below 28 degrees Celsius
Shelf life: 24 months
Net content: 60 ML

Matters need attention

1. Possible skin and eye irritation.
2. Use in a well-ventilated environment.
3. In case of contact with eyes, rinse with plenty of water.
4. Keep away from children. Store it away from sources of ignition

)

Consider:

class A {
    operator bool() const { return true; }
    // Assume A is movable but not copyable.
};

A make_a() { return A(); }

int main() {
    auto a_obj = make_a();
    if (a_obj) std::cout << "it's true\n";
    return 0;
}

Is it guaranteed that auto will infer type A for a_obj? Are there any situations where a_obj might be inferred as a bool instead?

(This is a simple example, but in the case that I actually care about, A is an RAII class, so I need to guarantee that its lifetime will extend to the end of the containing scope)

For context, I'm trying to design a SIGBUS handler for our multi-threaded program that uses mmap.

From the signal(7) manpage:

>A signal may be process-directed or thread-directed. A process- directed signal is one that is targeted at (and thus pending for) the process as a whole. A signal may be process-directed because it was generated by the kernel for reasons other than a hardware exception, or because it was sent using kill(2) or sigqueue(3). A thread-directed signal is one that is targeted at a specific thread. A signal may be thread-directed because it was generated as a consequence of executing a specific machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE for a math error), or because it was targeted at a specific thread using interfaces such as tgkill(2) or pthread_kill(3).

It's not clear to me whether an mmap fault (in our case, attempting an access after the underlying file was truncated) counts as a hardware exception as defined above — it definitely triggers a SIGBUS, but I don't know whether I can rely on that SIGBUS targeting the thread that triggered the fault. (This is relevant in particular because I'm trying to design a signal handler, and longjmp across threads isn't valid.)

So what I want to know is (1) whether SIGBUS is process-directed or thread-directed in practice on Linux, and ideally (2) whether that is guaranteed across kernel versions and platforms (we also need to support NetBSD and FreeBSD)

From the signal(7) manpage:

>A signal may be process-directed or thread-directed. A process- directed signal is one that is targeted at (and thus pending for) the process as a whole. A signal may be process-directed because it was generated by the kernel for reasons other than a hardware exception, or because it was sent using kill(2) or sigqueue(3). A thread-directed signal is one that is targeted at a specific thread. A signal may be thread-directed because it was generated as a consequence of executing a specific machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE for a math error), or because it was targeted at a specific thread using interfaces such as tgkill(2) or pthread_kill(3).

It's not clear to me whether an mmap fault (in our case, attempting a read after the underlying file was truncated) counts as a hardware exception as defined here — it definitely triggers a SIGBUS, but I don't know whether I can rely on that SIGBUS targeting the thread that triggered the fault. (This is relevant in particular because I'm trying to design a signal handler, and longjmp across threads isn't valid.)

So what I want to know is (1) whether SIGBUS is process-directed or thread-directed in practice on Linux, and ideally (2) whether that is guaranteed across kernel versions and platforms (we also need to support NetBSD and FreeBSD)