You can set the buffering mode of any file stream with setvbuf. For example, setvbuf(stderr, NULL, _IOLBF, BUFSIZ) sets stderr to line buffered I/O.

that may help, but if a write writes more than PIPE_BUF bytes, it isn't guaranteed atomic by the kernel. similarly, stdioing a line of more than BUFSIZ may result in multiple write calls. i don't think posix makes any guarantees there (this is just an empirically based speculation) and i'm fairly sure the c standard doesn't

Don't confuse the C stderr (which is of type FILE) from posix STDERR_FILENO file descriptor (i.e. 2). FILE (in POSIX, and in C since C11) guarantees that each I/O operation is thread safe (and flockfile in POSIX can be used to make larger operations atomic). A low level POSIX file descriptor is not thread safe (although of course the kernel will protect its own integrity). BUFSIZ only matter when writing to a pipe from distinct file descriptors.

i think the previous discussion may not have been clear enough, because you seem to be discussing a totally different scenario

given this program

    #include <string.h>
    #include <stdio.h>

    char large[16385];

    int main()
    {
      printf("BUFSIZ is %d\n", BUFSIZ);
      memset(large, 'A', sizeof(large));
      large[sizeof(large) - 1] = '\0';
      fprintf(stderr, "%s\n", large);
      return 0;
    }

compiled with `gcc -static` against glibc 2.36-9+deb12u7, we get this strace

    execve("./a.out", ["./a.out"], 0x7fffafcb4a30 /* 49 vars */) = 0
    brk(NULL)                               = 0x1e28000
    brk(0x1e28d00)                          = 0x1e28d00
    arch_prctl(ARCH_SET_FS, 0x1e28380)      = 0
    set_tid_address(0x1e28650)              = 1501924
    set_robust_list(0x1e28660, 24)          = 0
    rseq(0x1e28ca0, 0x20, 0, 0x53053053)    = 0
    prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=9788*1024, rlim_max=RLIM64_INFINITY}) = 0
    readlink("/proc/self/exe", "<censored>", 4096) = 21
    getrandom("<censored>", 8, GRND_NONBLOCK) = 8
    brk(NULL)                               = 0x1e28d00
    brk(0x1e49d00)                          = 0x1e49d00
    brk(0x1e4a000)                          = 0x1e4a000
    mprotect(0x4a0000, 16384, PROT_READ)    = 0
    newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x7), ...}, AT_EMPTY_PATH) = 0
    write(1, "BUFSIZ is 8192\n", 15)        = 15
    write(2, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 8192) = 8192
    write(2, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 8192) = 8192
    write(2, "\n", 1)                       = 1
    exit_group(0)                           = ?
    +++ exited with 0 +++

you can see that the single fprintf call resulted in three separate calls to write(2), even though it is only a single line of desperate screaming. those three calls happen at three separate times, typically on the order of tens of microseconds apart. if that file descriptor is open to, for example, a terminal or pipe or logfile that some other process is also writing to, that other process can write other data during those tens of microseconds, resulting in the intercalation of that other data in the middle of the screaming

threads are completely irrelevant here, except that i guess in an exotic scenario the 'other process' that is writing to the file could conceivably be a different thread in the same process? that would make your remarks about 'distinct file descriptors' and thread safety make sense. but we were talking about entirely separate processes writing to the file, since that's the usual case on unix, and in that case no form of thread-safety is worth squat; what matters is the semantics of the system calls

i don't think posix makes any guarantees about how many calls to write(2)† a call to fprintf(3) will result in, though i haven't actually looked, and i don't think wg14 concerns itself with environment-dependent questions like this at all

______

† or writev(2)

What he's saying is that as long as you don't mix usage of stdio and raw write(2), you won't have any interleaving problem; because there's a lock, which is why _unlocked variants exist.

that is correct in its own sphere of applicability, but incorrect in the scenario i was discussing, with entirely separate processes writing to the file, since that's the usual case on unix, because each process has a separate lock

(amelius, however, did mention the possibility of multiple threads!)

it also wasn't what they were saying

this thread is starting to remind me of the 'i'm not your buddy, pal' cascades from reddit

Sorry, I meant specifically threads, so the atomicity is purely process local of course. There is an I ternal (recursive) mutex inside FILE.

agreed (well, i haven't looked at how glibc implements the thread safety requirement, but i imagine you're correct)

rust

Click on + for Fedora and Ubuntu and check "Stability"

People have been killing each other for their entire history, I don't think that has changed. It's just that you hear about and see it more often now.

> Like say from my password manager? Or API keys in my terminal?

That's not describing a bad outcome, it's describing how the tool works.

Oh, well I think what he meant is that some malicious program could read and transmit this unencrypted recorded data which is normally stored in an encrypted form

Thanks, I think so too, but the threat model is a bit odd. On a Mac, potentially malicious programs do not normally have access to files in every location (e.g. the prompts to allow a process to access your Documents dir); there is hardware-backed crypto available for further protections; full disk encryption; and so on. It's unclear to me how to evaluate the severity of the risk.

Every security decision is a risk-reward tradeoff, and the reward of a complete memory of computing tasks seems pretty huge.

It's usable if you can live with some small annoying inconveniences last I tried. I can't remember if there were more inconveniences but what bugged me the most was that the touchpad was too sensitive compared to MacOS, it seemed to register accidental touches on the edges more and accidental taps were easier. I tried figuring out if this is fixable with libinput or hwdb but eventually gave up. Also the shortcuts with Command key are way more convenient than the ctrl ones but this probably is configurable somehow. Some Java programs had scaling issues but that can be configured to work properly. Battery life was a bit worse I think, this is with the GPU drivers and no video playback, just regular browsing. Oh and external monitor support isn't there, I do use this sometimes on MacOS.

Isn't that implying OP is a script kiddie? I don't think writing a debugger is a script kiddie project.

I saw Unexpected Keyboard recommended here, turns out it can do this as well among other things. Just tap Shift and drag left/right on spacebar. The main feature though is that you can enter the characters that aren't used commonly by swiping insted of holding on a key or switching to a different key view. You can also get Ctrl and Alt and you can like lock them as well which is useful in Termux.

I don't understand going cold turkey. You said it had a difference for you. What was it? I've tapered off before, it probably took like a week at most and I experienced no headaches.

Even at ~1/4th caf as my once daily cup, I still got ~3 days of headaches when I finally quit entirely.

After that, I slept much better. I could finally fall asleep, it wouldn't take me an hour to nod off. I stayed asleep, I wasn't getting up 2-3 times a night. My anxiety, which I then found out contributed to my sleep problems, that pretty much went away. I used to plan and replan scenarios in my head, come up with pithy quips to conversations that would never happen, fear saying or doing the wrong thing in imaginary conundrums.

It all just disappeared after I quit caffeine. I felt 'normal' for the first time in decades. I woke up having the best night of sleep in my memory. And then it happened the next morning, and the next.

Currently, I don;t sleep all that well, but a new baby is the culprit. I can't imagine having a newborn and being on caffeine again, my anxiety would spiral out of control. I'd be a mess for my kid, projecting things, being a jerk.

One of the best little random challenges I ever gave myself.