Newest at the top
| 2025-10-28 12:18:14 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-10-28 12:16:22 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2025-10-28 12:13:12 +0100 | <kuribas> | Especially if you have a good IDE. |
| 2025-10-28 12:13:06 +0100 | <kuribas> | IMO types also help greatly with understanding a codebase better. |
| 2025-10-28 12:11:58 +0100 | <kuribas> | __monty__: word |
| 2025-10-28 12:00:17 +0100 | srazkvt | (~sarah@user/srazkvt) (Read error: Connection reset by peer) |
| 2025-10-28 11:58:13 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 264 seconds) |
| 2025-10-28 11:54:59 +0100 | Pixi` | (~Pixi@user/pixi) Pixi |
| 2025-10-28 11:52:33 +0100 | <__monty__> | But for some changing code and the type feels like too big a waste of time, I suppose. |
| 2025-10-28 11:52:32 +0100 | <mauke> | that was "goto fail" |
| 2025-10-28 11:52:01 +0100 | <__monty__> | That doesn't mean that I'm willing to waste time tracing through a dynamic OOP codebase to figure out where a number is being passed rather than a string. |
| 2025-10-28 11:51:02 +0100 | <__monty__> | I do think it's fair to say the most impactful bugs are ones in the logic as implemented. The if statement that didn't actually guard its body comes to mind, was that Apple or Heartbleed? |
| 2025-10-28 11:49:59 +0100 | <kuribas> | But I find static types a nice middle ground, usually not a huge extra effort. |
| 2025-10-28 11:49:18 +0100 | <kuribas> | Of course, full on formal verification can be a huge time wast if you implement the wrong business logic. |
| 2025-10-28 11:48:55 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 264 seconds) |
| 2025-10-28 11:48:35 +0100 | <kuribas> | Also, if the code reflects the business logic cleanly, it's easier to change when required, rather than have an dynamic, spagetty mess of imperative side-effects. |
| 2025-10-28 11:47:34 +0100 | <kuribas> | Why does always the argument that you can implement the wrong business logic comes up when talking about formal languages? In my experience, the majority of bugs (in those languages) or not business logic related. |
| 2025-10-28 11:46:16 +0100 | Googulator70 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 11:46:02 +0100 | Googulator49 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 11:43:15 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-10-28 11:43:07 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 246 seconds) |
| 2025-10-28 11:38:33 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-10-28 11:37:39 +0100 | AlexNoo_ | AlexNoo |
| 2025-10-28 11:35:45 +0100 | Googulator20 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 11:35:44 +0100 | Googulator70 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 11:34:05 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-10-28 11:32:29 +0100 | <srazkvt> | yea i usually make it a macro too |
| 2025-10-28 11:32:01 +0100 | <haskellbridge> | <Morj> srazkvt: Yeah you're right, I was misremembering. In any case, for the last how many years of C++ for me it was Q_UNUSED(thevar) |
| 2025-10-28 11:31:47 +0100 | <tomsmeding> | I guess (void)&my_struct; |
| 2025-10-28 11:31:24 +0100 | <tomsmeding> | you can just &my_struct; if you want |
| 2025-10-28 11:31:14 +0100 | <srazkvt> | icc is still a thing, but i don't know of anyone who uses it |
| 2025-10-28 11:31:08 +0100 | <tomsmeding> | lol ok yeah |
| 2025-10-28 11:30:48 +0100 | <kuribas> | (int *(int*)(&my_struct)) or something... |
| 2025-10-28 11:30:47 +0100 | <mauke> | tomsmeding: maybe intel cc (is that still a thing?) might support it |
| 2025-10-28 11:30:15 +0100 | <tomsmeding> | mauke: ah I see -- a viewpoint that I agree with, by the way, though that's beside the point here |
| 2025-10-28 11:30:11 +0100 | <kuribas> | tomsmeding: what if you cast the pointer, then back? |
| 2025-10-28 11:29:48 +0100 | <tomsmeding> | yes but you cannot convert a struct to an int |
| 2025-10-28 11:29:40 +0100 | <tomsmeding> | kuribas: `error: cannot convert to a pointer type` |
| 2025-10-28 11:29:39 +0100 | <kuribas> | tomsmeding: you can convert pointer to int, no? |
| 2025-10-28 11:29:20 +0100 | <mauke> | because they didn't like #pragma because you can't generate it from a macro |
| 2025-10-28 11:29:05 +0100 | <tomsmeding> | pointers are just scalars, but structs are not scalars |
| 2025-10-28 11:28:54 +0100 | <tomsmeding> | kuribas: C distinguishes very much between values and pointers |
| 2025-10-28 11:28:50 +0100 | <mauke> | AFAIK __attribute__ is a GNU invention |
| 2025-10-28 11:28:40 +0100 | <tomsmeding> | because if this is just warning management, I wouldn't care so much about proper cross-compiler compatibility |
| 2025-10-28 11:28:39 +0100 | <kuribas> | tomsmeding: does C distinguis between scalar and compound? I thought it's just all addresses for C. |
| 2025-10-28 11:28:27 +0100 | <tomsmeding> | mauke: is __attribute__ in general syntax that is parsed by other compilers, even if not this particular 'unused' attribute? |
| 2025-10-28 11:27:47 +0100 | <tomsmeding> | mauke: ah |
| 2025-10-28 11:27:45 +0100 | <tomsmeding> | kuribas: yes which makes no sense and may well be rejected by the compiler if the thing is not a scalar in the first place, such as a struct |
| 2025-10-28 11:27:34 +0100 | <mauke> | s/gcc/gcc and imitators/ |
| 2025-10-28 11:27:24 +0100 | <tomsmeding> | s/w// |