Newest at the top
| 2026-04-03 22:44:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-03 22:38:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 22:37:03 +0000 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-04-03 22:32:59 +0000 | Digitteknohippie | Digit |
| 2026-04-03 22:30:23 +0000 | divlamir_ | (~divlamir@user/divlamir) (Ping timeout: 244 seconds) |
| 2026-04-03 22:27:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-04-03 22:26:15 +0000 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-04-03 22:26:05 +0000 | divlamir_ | (~divlamir@user/divlamir) divlamir |
| 2026-04-03 22:22:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 22:12:53 +0000 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2026-04-03 22:11:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-04-03 22:11:08 +0000 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-04-03 22:09:33 +0000 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-04-03 22:08:59 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 265 seconds) |
| 2026-04-03 22:07:59 +0000 | Guest20 | (~Guest20@149.3.7.235) (Quit: Client closed) |
| 2026-04-03 22:06:51 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 22:05:10 +0000 | puke | (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-03 21:56:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-03 21:48:49 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 21:47:55 +0000 | <tomsmeding> | same for clang 21.1.6 |
| 2026-04-03 21:47:07 +0000 | <tomsmeding> | monochrom: I do not share your observations, I get no -Wunused-result for read(2) whatsoever on my system (linux, gcc 15.2.1), but I do get that warning for realloc() regardless of the optimisation level |
| 2026-04-03 21:47:05 +0000 | <monochrom> | When confronted with an unused-value problem, some people go, "I know, I will store it in a fresh variable!". Now they have two problems. >:) |
| 2026-04-03 21:44:41 +0000 | <tomsmeding> | monochrom: although now you have a -Wunused-but-set-variable ;) |
| 2026-04-03 21:44:00 +0000 | <tomsmeding> | yes, I'm a little confused too |
| 2026-04-03 21:43:41 +0000 | <monochrom> | Adding "int r; r =" kills the warning under -O2. So it is not even like "we need an elaborate live-variable analysis to discover unused results" :) |
| 2026-04-03 21:37:56 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:343e:4e23:bce:73a3) synchromesh |
| 2026-04-03 21:36:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-03 21:36:19 +0000 | <tomsmeding> | I guess https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-result is the better link |
| 2026-04-03 21:35:53 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:343e:4e23:bce:73a3) (Read error: Connection reset by peer) |
| 2026-04-03 21:35:52 +0000 | <tomsmeding> | the manual doesn't elucidate: https://gcc.gnu.org/onlinedocs/gcc/Common-Attributes.html#index-warn_005funused_005fresult |
| 2026-04-03 21:35:14 +0000 | <monochrom> | So I still don't know why! :) |
| 2026-04-03 21:34:41 +0000 | <monochrom> | No warning until -O2 |
| 2026-04-03 21:34:32 +0000 | <monochrom> | OK I have: int main(void) {char b[100]; read(0, b, 100); ... |
| 2026-04-03 21:33:22 +0000 | <tomsmeding> | not saying there are none, I just can't think of any :) |
| 2026-04-03 21:32:44 +0000 | <tomsmeding> | that... has nothing to do with optimisations? fork() doesn't care whether you used -O2 if it wants to fail |
| 2026-04-03 21:32:11 +0000 | <monochrom> | I forgot. I seem to recall that unused-return-value is one of them. |
| 2026-04-03 21:31:42 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 21:31:37 +0000 | <tomsmeding> | warning about = vs == is independent of optimisations |
| 2026-04-03 21:31:21 +0000 | <tomsmeding> | what kind of warnings would become more important under optimisations? |
| 2026-04-03 21:31:00 +0000 | <monochrom> | At least there is a strong correlation between unoptimized and bad code working fine. |
| 2026-04-03 21:30:54 +0000 | <tomsmeding> | ideologically it's a little more nuanced |
| 2026-04-03 21:30:36 +0000 | <tomsmeding> | observationally, yes |
| 2026-04-03 21:30:27 +0000 | <monochrom> | Ah OK. I think the two are logically equivalent. :) |
| 2026-04-03 21:30:20 +0000 | <tomsmeding> | but this is from memory -- not 100% sure |
| 2026-04-03 21:30:04 +0000 | <tomsmeding> | or, reformulated, they think it's not worth generating the warnings if that's the only reason for running the analysis |
| 2026-04-03 21:29:57 +0000 | <monochrom> | I was guessing that it was because -O2 breaks more code under beginner mistakes. |
| 2026-04-03 21:29:44 +0000 | <tomsmeding> | IIRC some of the analyses needed to produce the warnings are only computed for the benefit of particular optimisations |
| 2026-04-03 21:29:21 +0000 | <monochrom> | I don't know. Is that it? |
| 2026-04-03 21:29:07 +0000 | <tomsmeding> | isn't that to make ghc -O0 faster? |
| 2026-04-03 21:28:44 +0000 | <monochrom> | gcc -O2 turns on more warnings than -O0. Anyone want to bring that ideology to GHC? Maybe next April 1? >:) |