Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Activity for Lundin
| Type | On... | Excerpt | Status | Date |
|---|---|---|---|---|
| Edit | Post #283441 |
Post edited: |
— | almost 3 years ago |
| Comment | Post #286189 |
Btw I'm not saying that it shouldn't be used, I'm saying that it should be used with caution. It's an incredibly flawed function. At a minimum use a compiler which investigates the format string. Or perhaps generate the format string through some type safe interface like `_Generic` macros. (more) |
— | almost 3 years ago |
| Comment | Post #286189 |
@#8196 That would involve using OS-specific API though. Or in case of embedded systems, rolling out some UART or display driver manually. There's no universal replacement. Though console I/O is mostly a thing of the past, most people stopped using it around year 2000. (Programs with or without GUI ca... (more) |
— | almost 3 years ago |
| Comment | Post #285813 |
@#56533 No, in the first case you pass the array object and in the second case the function. As per various rules of parameter decay, the compiler will implicitly adjust them to pointers. Just as for example Java will implicitly adjust an object passed as parameter to a reference - same thing. (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
In either of these scenarios, the correct place to check against null is _always_ where you have valid reasons to suspect it to get set to null (after a malloc call?) and only there. It is _never_ the correct place to check inside the completely unrelated library function `func` which has the purpose... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#8196 It isn't, it is the very same thing. This code `int* someptr = ...; /*...*/ if(!someptr) { ... } func(someptr); /*...*/ void func (int* someptr) { if(!someptr) { ...}` boils down to the very same thing as `int* someptr = ...; /*...*/ if(!someptr) { ... } /*some rows of unrelated code*/ if(!som... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#8196 So every 10th line or so we should check if all pointers in the current scope are null? Because that makes as much sense. (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
Checking if you have the key before starting your car is perfectly reasonable. Checking if the car still has an engine, wheels and exhaust each time before starting it is not. What is one's reason for doing so, is there a notorious car part thief in the neighbourhood (valid reason) or is it "one cann... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#8196 Everyone is missing the point that checking for null _inside_ some generic function is always the wrong _place_. Checking for null elsewhere is perfectly reasonable and I never said otherwise. Unfortunately it would seem that the average reader here is of the PC programmer variety who has neve... (more) |
— | almost 3 years ago |
| Comment | Post #286189 |
@#36396 Looking them up is just a [man](https://linux.die.net/man/) away though. Some of these are rarely ever used even by C veterans. I don't think I've ever used `tmpfile` or `ungetc`, `signal()` is pretty much never used outside *nix systems and so on. (more) |
— | almost 3 years ago |
| Edit | Post #286195 | Initial revision | — | almost 3 years ago |
| Answer | — |
A: How can we grow this community? By having decent source code formatting that isn't completely inferior to other sites like Stack Overflow. We might want to post/view snippets longer than 13 lines without suffering some scroll wheel. See my feature request here. My first impression when coming to any Codidact site requiring sour... (more) |
— | almost 3 years ago |
| Comment | Post #286189 |
@#36396 "Family of functions" means that there is `atoi` and `atof` and `atod` etc, a bunch of very similar functions with slight differences when it comes to types/parameters. And there's a corresponding more suitable family of `strtol`, `strtof`, `strtod` and so on. Similarly there is `printf`, `f... (more) |
— | almost 3 years ago |
| Comment | Post #286193 |
"Defensive programming", as in applying numerous error checks even in cases that theoretically shouldn't fail, might be a good idea. However, such error checks should be located near the place where one might suspect that the error appears (user input, buffer copying etc), and not in some unrelated l... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#8153 Ah yeah, silly little bug. It's been fixed, thanks. (more) |
— | almost 3 years ago |
| Edit | Post #286191 |
Post edited: Fixed a bug |
— | almost 3 years ago |
| Comment | Post #286191 |
@#53305 So now I'm not only waiting for you to explain how a C function should do bounds checking of its array parameter, I'm also waiting for you to explain exactly how `memmove_s` checks it's parameters against null, contrary to the run-time constraints in K 3.7.1.2 I just quoted. Or we could just ... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#53305 It's not "whatever", you criticise my post and down vote it with the and claim that functions should do bounds checking, which I still don't know what it has to do with null checking. I'm happy to get _constructive_ criticism but this isn't it. As for the optional annex K bounds checking inte... (more) |
— | almost 3 years ago |
| Comment | Post #286191 |
@#53305 How is that even related? Also I don't understand what you are talking about: either a function gets an array size passed, in which case the caller has to get it right, or it doesn't get an array sized passed, in which case no can do. Either way, a function in C cannot do meaningful bounds-ch... (more) |
— | almost 3 years ago |
| Edit | Post #286191 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #286191 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #286191 | Initial revision | — | almost 3 years ago |
| Answer | — |
A: Should I check if pointer parameters are null pointers? The kind of comments telling you to add checks against null are typically coming from programmers mostly used to deal with higher level programming languages. They think that generally, more explicit error handling is always a good thing. And that is true in most cases, but not in this one. The sp... (more) |
— | almost 3 years ago |
| Edit | Post #286190 | Initial revision | — | almost 3 years ago |
| Question | — |
Should I check if pointer parameters are null pointers? When writing any form of custom function such as this: void func (int a, int b) Should I add code to check if `a` and `b` are null pointers or not? if(a == NULL) / error handling / When posting code for code reviews, one frequent comment is that such checks against null shoul... (more) |
— | almost 3 years ago |
| Edit | Post #286189 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #286189 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #286189 | Initial revision | — | almost 3 years ago |
| Answer | — |
A: Which functions in the C standard library must always be avoided? Standard library functions that should never be used: setjmp.h - `setjmp()` Together with `longjmp()`, these functions are widely recogniced as incredibly dangerous to use: they lead to spaghetti programming, they come with numerous forms of undefined behavior, they can cause unintende... (more) |
— | almost 3 years ago |
| Edit | Post #286187 | Initial revision | — | almost 3 years ago |
| Question | — |
Which functions in the C standard library must always be avoided? It would seem that the C standard library is a collection of diverse functions that pretty much just ended up in the standard by tradition or "accident", rather than through some careful plan or rationale. During standardization of ANSI/ISO 9899:1990, they just grabbed a bunch of existing library fun... (more) |
— | almost 3 years ago |
| Comment | Post #286152 |
The thought I had when raising this question was mainly how much research effort we should require. SO went from "you have to at least understand a minimum of the topic" to "ask anything you want" and the site got IMO much worse because of it. If we aren't expecting any research effort then posters e... (more) |
— | about 3 years ago |
| Edit | Post #286142 | Initial revision | — | about 3 years ago |
| Answer | — |
A: C++ exit code -1073740940 C++ doesn't have error codes/exit codes other than `return 0;` / `EXITSUCCESS` / `EXITFAILURE`. The code you are getting is from the OS when your program crashes from a run-time error. `-1073740940` is unhelpful gibberish, you need to convert this from 2's complement 32 bit into hex. Then you get ... (more) |
— | about 3 years ago |
| Edit | Post #285998 |
Post edited: Better title |
— | about 3 years ago |
| Comment | Post #285999 |
@#8046 Well 400 lines of very compact and detailed code with lots of comments might go as far as 30k characters... maybe. If we are looking for some worst-case number, I'd say a reasonable upper limit might be something like 1k lines 80 characters each = 80k. Larger than that and it won't be fun to r... (more) |
— | about 3 years ago |
| Comment | Post #285999 |
Seriously, 400 lines of code is not much, the average source file is some 200-1000 LoC and a medium-sized project has maybe 50 such files. Sure, a whole project like that would be too much, but why wouldn't the site be able to take a 400 LoC post? (more) |
— | about 3 years ago |
| Comment | Post #285974 |
As a side note regarding embedded systems and main(), there's an issue where C++ claims that if main() is defined, it must be declared as int main() and I don't even think they made an exception for freestanding systems. In that case `noreturn` might save the day. That doesn't apply to C however, wh... (more) |
— | about 3 years ago |
| Comment | Post #285974 |
@#53937 I wouldn't dare say anything about ABI compatibility between all *nix systems that have implemented pthreads over the years. Just take x86_32 Linux vs x86_64 Linux as the most obvious example. (more) |
— | about 3 years ago |
| Comment | Post #285974 |
@#53398 Again, you can't do that for the same reasons as in my previous comment - calling convention. If you specify a return type but don't return, you risk tricking the compiler into thinking it should push/pop items on the stack which are never pushed/popped there by the function. This is also the... (more) |
— | about 3 years ago |
| Comment | Post #285974 |
@#53937 Never the less, it is bad practice not to clean up your own mess no matter what the OS does. Executing such clean-up code is also an excellent way of surfacing dormant bugs elsewhere in the application (`free()` crashing etc). (more) |
— | about 3 years ago |
| Comment | Post #285974 |
@#53398 The whole practical rationale for this is cases like for example a "bare metal" system where your program starts up in a power-on reset interrupt. From there on it calls the C run-time start-up code _never to return_, so no need to waste stack on storing return address etc. Then the C run-tim... (more) |
— | about 3 years ago |
| Comment | Post #285968 |
@#53078 The C standard is fuzzy and only says that the pointed-at data should be regarded as an array of objects with "a fundamental alignment requirement" (an alignment less than or equal to the greatest alignment supported by the implementation in all contexts). So the alloc functions may grab more... (more) |
— | about 3 years ago |
| Edit | Post #285974 | Initial revision | — | about 3 years ago |
| Answer | — |
A: noreturn function with non-void return type Syntax-wise it is a function specifier and may in theory appear everywhere where `inline` (or rather the syntax item function-specifier:) can appear, since the standard doesn't say otherwise. Though of course it would be nonsense to declare `Noreturn` together with a return type and a compiler failin... (more) |
— | about 3 years ago |
| Comment | Post #285969 |
Discussion about resource requests specifically: [How does the community feel about resource requests?](https://software.codidact.com/posts/277530) (more) |
— | about 3 years ago |
| Comment | Post #285911 |
Also related: [The size of the code format window is much too small.](https://software.codidact.com/posts/278868) (more) |
— | about 3 years ago |
| Edit | Post #285971 | Initial revision | — | about 3 years ago |
| Answer | — |
A: Software recommendations category At some extent, you can ask about (programming-related) software recommendations if you manage to narrow down the scope to something specific. A question like "which one of compiler x and compiler y currently got the best support for language standard z? I'm mainly interested in features a, b and c."... (more) |
— | about 3 years ago |
| Edit | Post #285968 |
Post edited: |
— | about 3 years ago |