Weird #FreeBSD oddity I haven't observed elsewhere:
Uncategorized
2
Posts
2
Posters
2
Views
-
Weird #FreeBSD oddity I haven't observed elsewhere:
Testing something, I issued a grep(1) command against interactive stdin:
$ grep x
and immediately hit control+d to provide an EOF. However it didn't exit until I pressed control+d a *second* time. I tested against grep on OpenBSD and an Ubuntu box and both exit immediately as expected, without the need for the second EOF.
Can other FreeBSD users reproduce this? And it feels like a bug I should report…
-
Weird #FreeBSD oddity I haven't observed elsewhere:
Testing something, I issued a grep(1) command against interactive stdin:
$ grep x
and immediately hit control+d to provide an EOF. However it didn't exit until I pressed control+d a *second* time. I tested against grep on OpenBSD and an Ubuntu box and both exit immediately as expected, without the need for the second EOF.
Can other FreeBSD users reproduce this? And it feels like a bug I should report…
@gumnos I can confirm, I get the same behavior, single ^D to exit on Linux, double ^D to exit in FreeBSD.
-
undefined stefano@mastodon.bsd.cafe shared this topic on
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@aeva I thought that's what we did by coming here.
-
@aeva You can have values that are different but their difference is a subnormal value and suddenly with FTZ you have div-by-0s, yeah.
(This is super rare but still.)
-
-
@rygorous ah, so for example, a not quite zero value and zero compare differently depending on whether DAZ is on, stuff like that?
-
@aeva the main thing that breaks without denormals on is that some numeric code might start slightly misbehaving in rare corner cases you're unlikely to notice, and certain assumptions like "if (a != b) then a-b != 0" don't hold with denormals off
-
@aeva me and the DSP classic: "why does it get very slow after the envelope fades out"
I solved this when I was doing a synth in Flash by adding noise
-
@aeva It's fine for audio code but when you turn it on, you generally want to put it in a scope guard thingy that saves the original MXCSR and restores it after (way out in the outer loop, not per function or anything, toggling that isn't super cheap) because it changes the results of some float calcs and breaks a few rules that while not _super_ important might trip you up
-
@aeva For audio?
Mostly you just won't need it if your IIR filters and delay lines (these are the two main culprits) just do this magic supah sekrit fixup on their input:
input += 1e-30f;
(or, in some cases, put it on the output for the feedback signals)
