|
rjmccall posted:Well, some of those are understandable, actually. If you’re going to have non-significant characters in identifiers, there’s not really any way to describe what might happen to a program that contains conflicts except UB — an identifier might resolve unexpectedly to a macro, calls might go to the wrong function or use the wrong type signature, etc. Same thing with reserved keywords — if your program is suddenly interpreted differently, it might have UB. The lexing violations, though, I dunno; always felt like they were standardizing that some compilers might have weird bugs. Any reason not to make it implementation-defined? Too open-ended an issue?
|
#
?
Mar 10, 2020 02:05
|
|
|
|
| # ? May 16, 2024 20:28 |
|
|
A lot of them feel like they should have just been made a (well-defined) compilation failure, since they're trivial and unambiguous to detect.
|
|
#
?
Mar 10, 2020 02:23
|
|
|
OddObserver posted:Any reason not to make it implementation-defined? Too open-ended an issue? Yeah, I don't think implementation-defined behavior encompasses the range of weird poo poo that can happen if names start resolving to the wrong thing.
|
|
#
?
Mar 10, 2020 03:36
|
|
|
Tei posted:You are the problem. Don't make me point to the thread title.
|
|
#
?
Mar 10, 2020 03:45
|
|
|
b0lt posted:Additional crazy UB: infinite loops without side effects are UB. i heard that this is now defined in C11 (not C++) because embedded developers threw a tantrum lol
|
|
#
?
Mar 10, 2020 05:15
|
|
|
OddObserver posted:Any reason not to make it implementation-defined? Too open-ended an issue? Implementation-defined behaviour must be documented, and I think to a higher standard than "who knows lol". But at least in C, missing a newline character from the final line of a source file is no longer UB.
|
|
#
?
Mar 10, 2020 08:40
|
|
|
qsvui posted:i heard that this is now defined in C11 (not C++) because embedded developers threw a tantrum lol What's the use case, waiting for an interrupt on an architecture that doesn't have a halt/pause instruction? Do those exist?
|
|
#
?
Mar 10, 2020 09:47
|
|
|
NtotheTC posted:In this nest of horrors, the one that pisses me off the most is that she created a middleware for this. Is this a "only tool is a hammer" situation or are serialisers a dirty word where you work?
|
|
#
?
Mar 10, 2020 12:10
|
|
|
nielsm posted:What's the use case, waiting for an interrupt on an architecture that doesn't have a halt/pause instruction? Do those exist? Sure. Or hand tuning delay loops because all your timers are used elsewhere or ugh I'm just doing it in this one place I don't want to dedicate a whole timer channel. It's not good but sometimes it's easier
|
|
#
?
Mar 10, 2020 13:40
|
|
|
Absurd Alhazred posted:Don't make me point to the thread title. I mean, if this thread ever run out of content, I myself can sustain it for years just posting my own code. I know.
|
|
#
?
Mar 10, 2020 13:52
|
|
|
Tei posted:I mean, if this thread ever run out of content, I myself can sustain it for years just posting my own code. I know. We all could. That's the point. 
|
|
#
?
Mar 10, 2020 14:23
|
|
|
nielsm posted:What's the use case, waiting for an interrupt on an architecture that doesn't have a halt/pause instruction? Do those exist? I think the most common use is just an infinite loop in main because your program only exits when the device is turned off and all the work is done in interrupt handlers.
|
|
#
?
Mar 10, 2020 16:53
|
|
|
The only uses I can come up with is panicky crash handler or some bizzaro chip that needs to busy loop while waiting for an interrupt. Everywhere else you'd access a register (volatile reads or writes count as side effects)
|
|
#
?
Mar 10, 2020 18:33
|
|
|
nielsm posted:What's the use case, waiting for an interrupt on an architecture that doesn't have a halt/pause instruction? Do those exist? I use them in debug all the time, "just wait here until i attach". But compilers get goofy around infinite loops so I mostly just write it in assembly. Honestly how many of you have written a wait-for-interrupt routine, they're not so trivial as the discussion here makes them sound.
|
|
#
?
Mar 10, 2020 19:29
|
|
|
JawnV6 posted:Honestly how many of you have written a wait-for-interrupt routine, they're not so trivial as the discussion here makes them sound. *raises hand*
|
|
#
?
Mar 10, 2020 19:41
|
|
|
JawnV6 posted:Honestly how many of you have written a wait-for-interrupt routine, they're not so trivial as the discussion here makes them sound. Does 6502 assembly count?
|
|
#
?
Mar 10, 2020 20:22
|
|
|
Generally speaking, sophisticated UB optimizations tend to be annoying when doing low-level embedded programming on a simple architecture. Think Atmel AVR class: a couple kilobytes of RAM, single or low double digit MHz, no caches. Just enough machine to be usefully targeted by a standards compliant C compiler. No operating system, usually no threads, just a main loop and interrupt handlers. In that sort of environment you’re typically trying to use C like it actually is portable assembly. On one project I remember frequently checking the compiler’s ASM output for a critical subroutine to make sure it was generating roughly what I expected. (Why not just write ASM by hand? Because I didn’t need that much optimization, and I like my code to be readable and maintainable by future-me.) In that context, optimizations which radically transform your program because a standards committee member thought it would be a good idea to tag simple idioms (like an infinite loop) as UB are very unwelcome. Perhaps they allow a benchmark written for something with 1000000x as much memory and 10000x as much cpu to go faster, but for you they’re unpredictable land mines which get in the way of writing simple code which translates to assembly instructions in a straightforward way. The need for this kind of software methodology is shrinking as the 8- and 16-bit embedded cores get replaced by 32-bit RISCs of various flavors (mostly ARM32), but it’s probably not ever going to disappear completely.
|
|
#
?
Mar 10, 2020 22:07
|
|
|
In particular, I've never known a project that doesn't use -fno-strict-aliasing
|
|
#
?
Mar 10, 2020 23:05
|
|
|
lobsterminator posted:Does 6502 assembly count? CLI
|
|
#
?
Mar 10, 2020 23:13
|
|
|
BobHoward posted:In that context, optimizations which radically transform your program because a standards committee member thought it would be a good idea to tag simple idioms (like an infinite loop) as UB are very unwelcome. Perhaps they allow a benchmark written for something with 1000000x as much memory and 10000x as much cpu to go faster, but for you they’re unpredictable land mines which get in the way of writing simple code which translates to assembly instructions in a straightforward way. The reason infinite loops specifically are/were undefined behaviour is so that if the compiler optimizes all the side-effects out of a loop (which is surprisingly common - consider code that uses a loop to compute a value, and then the value is only used when debug logging is turned on), it can remove the loop entirely, even if the compiler can't actually prove that the loop terminates. The fact that this also means the compiler can just delete code that ends up reaching a provably-infinite loop is not really the desired goal of making it UB.
|
|
#
?
Mar 10, 2020 23:28
|
|
|
Wait, does the spec define side-effect? Or is the compiler deciding what constitutes one, such as about load/stores outside the current frame. So in the old spec, an infinite loop around popping a hardware queue with native instructions would be UB?
|
|
#
?
Mar 11, 2020 10:07
|
|
|
In C++, it's: - A call to a library i/o function - An access or modification of a volatile object - a synchronization operation or atomic operation If you're poking hardware registers, then hopefully you've declared those as volatile - you'll have all sorts of other problems if you haven't! If you're using inline asm, you'd similarly need to declare it as __volatile__ so that the compiler is aware that it has side-effects instead of merely computing an output from given inputs.
|
|
#
?
Mar 11, 2020 11:46
|
|
|
Looks like writing to any object counts as a side effect, linkcppreference posted:Initiation of side effects: access (read or write) to an object designated by a volatile glvalue, modification (writing) to an object, calling a library I/O function, or calling a function that does any of those operations.
|
|
#
?
Mar 12, 2020 03:50
|
|
|
Guess what language uses the same words for more than one concept! That's about operation sequencing. It splits expressions into value computation and side effect, then has rules for what order they happen in. i.e. how to interpret an expression like code:The infinite loop part is more explicit: C++ draft posted:The implementation may assume that any thread will eventually do one of the following: Foxfire_ fucked around with this message at 08:59 on Mar 12, 2020 |
|
#
?
Mar 12, 2020 08:52
|
|
|
rjmccall posted:If you’re going to have non-significant characters in identifiers Which is the root problem. Non-significant characters should have been removed a long time ago. If you can't support unlimited length, then just have a hard limit. Don't make Long_long_name and Long_long_name_v2 resolve to the same thing.
|
|
#
?
Mar 12, 2020 09:45
|
|
|
What is the definition of a 'library I/O function'? I assume that this is more specific than just any function (does in-lining matter?)
|
|
#
?
Mar 12, 2020 13:01
|
|
|
Dumb question because I know nothing about C - when people talk about how "powerful" it is, what are they talking about? Like, what specifically is it able to do that no other (nicer-to-use) language is able to do? I imagine there's a lot, but I have no knowledge of C and I generally just do application-level coding I don't really have any need for the close-to-the-metal stuff that I assume C excels in.
|
|
#
?
Mar 12, 2020 22:35
|
|
|
a hot gujju bhabhi posted:Dumb question because I know nothing about C - when people talk about how "powerful" it is, what are they talking about? Like, what specifically is it able to do that no other (nicer-to-use) language is able to do? I imagine there's a lot, but I have no knowledge of C and I generally just do application-level coding I don't really have any need for the close-to-the-metal stuff that I assume C excels in. For C I guess the powerful part would be explicit and direct control of how and when memory is allocated and deallocated as well as explicit and direct control of how your data is laid out in memory. C++ keeps those characteristics and adds a lot of abstractions on top like: a Turing-complete type system, functional programming idioms like scans and folds, and complex multiple class inheritance. These are all perfectly useful and the combination of low level control of memory with high level abstractions is powerful, but it tends to be powerful in roughly the same way that powering your kitchen fridge with a small experimental fusion reactor is powerful. The talk about "powerful C++ features" over the last couple of pages has been maybe 70% sarcastic or so.
|
|
#
?
Mar 12, 2020 23:09
|
|
|
At least 90% of the people who talk about how powerful C is have no idea what they're talking about and are just parroting a line that someone else told them. If you need to work with hardware at a level below an OS API then it really does offer something, but otherwise it's just a pain in the rear end to work with.
|
|
#
?
Mar 13, 2020 00:03
|
|
|
The power of C is that it's a sweet spot of a small and (relatively) simple abstraction that gives you enough control to do useful stuff. If you are starting with *nothing*, no OS, no kernel, no libc, no friggin printf; a small C toolchain is the first thing you want to get up and running. You don't even need the standard library, just initiate your stack in a crt0.s and you're golden. (all assuming you have a compiler that can codegen and link for your platform...) Need some parts of libc? Copy over some code from newlib, no probs. libc++ is a lot more complicated to get running, and it requires libc anyway. That and the fact it was used to build Unix and nearly every OS after helped to made it the lingua-franca of computing. If your kernel talks C to you, it's handy if you can talk C back. You can maybe imagine an alternative world where Forth was used as the basis of Unix, and subsequent kernel and OS layers. But C's where we landed in this timeline. edit: obligatory gently caress THE PREPROCESSOR
|
|
#
?
Mar 13, 2020 00:05
|
|
|
While you don't necessarily want to use C a lot, knowing it can help you do things like creating a DLL that'll play nice with people's binaries without being too dependent on the version of their more higher-level compiler.
|
|
#
?
Mar 13, 2020 03:16
|
|
|
yeah, the C runtime is *the* runtime. everybody uses it. everybody can use it.
|
|
#
?
Mar 13, 2020 03:23
|
|
|
It doesn't make sense to use C because it's "powerful". It's not powerful, it's weak, and that's why it can run on everything, and why everything can talk to or from C. It's not even "high level assembly" anymore, unless you look at it as assembly for the machine defined by Unix-ish operating systems.
|
|
#
?
Mar 13, 2020 15:32
|
|
|
EMERGENCY BROADCAST SERVICE: You will see many misinformation on the internet talking bad of C. Ignore these post for your safety and only pay attention to the official information comming from K&R. Stay safe. Stay informed.
|
|
#
?
Mar 13, 2020 16:03
|
|
|
As long as you wash your hands of C, you will be fine.
|
|
#
?
Mar 13, 2020 16:14
|
|
|
Every Turing-complete language is exactly as powerful as every other. 
|
|
#
?
Mar 13, 2020 16:14
|
|
|
CPColin posted:Every Turing-complete language is exactly as powerful as every other. can't argue with that. footguns are just as powerful as regular guns
|
|
#
?
Mar 13, 2020 16:20
|
|
|
power is work over time, so it's more accurate to say that they're all equally strong
|
|
#
?
Mar 13, 2020 16:21
|
|
|
Which language has the most torque? Also, all conputers are equally powerful, as they are equivalent to a finite state machine.
|
|
#
?
Mar 13, 2020 17:07
|
|
|
|
| # ? May 16, 2024 20:28 |
|
|
FACT CHECK: more states = more power
|
|
#
?
Mar 13, 2020 17:09
|
|
