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 alx
| Type | On... | Excerpt | Status | Date |
|---|---|---|---|---|
| Edit | Post #286578 | Initial revision | — | over 2 years ago |
| Question | — |
array of arrays vs array of pointers to store array of string literals Let's consider the following code: ```c const char a[][4] = {"aa", "aaa"}; const char b[] = {"bb", "bbb"}; const char const c[] = {"cc", "ccc"}; ``` For shared libraries, both `b` and `c` arrays require the array of pointers to be generated at runtime, which implies performance costs. Se... (more) |
— | over 2 years ago |
| Comment | Post #286575 |
But I'm discarding it from `r->s`, which is `const char *`. (more) |
— | over 2 years ago |
| Edit | Post #286575 |
Post edited: __auto_type |
— | over 2 years ago |
| Edit | Post #286575 |
Post edited: |
— | over 2 years ago |
| Edit | Post #286575 | Initial revision | — | over 2 years ago |
| Question | — |
How to write a macro that discards the const qualifier, for any type? How to write a macro that discards the const qualifier, for any type? I hope some combination of `typeof` and a cast will do, but haven't found the combination. I tried this, without luck: ```c #define discardconst(x) ((typeof(x + 0)) (x)) struct t { char s; }; char foo(const... (more) |
— | over 2 years ago |
| Edit | Post #286573 |
Post edited: |
— | over 2 years ago |
| Edit | Post #286573 | Initial revision | — | over 2 years ago |
| Question | — |
PGP sign emails sent with git-send-email(1) How can we use git-send-email(1) to sign patches (emails) with the gpg(1) keyring? I've heard it can be done, but couldn't find anything in the git-send-email(1) documentation nor in a web search. (more) |
— | over 2 years ago |
| Comment | Post #286302 |
Hmm, interesting. I'll copy here a link to the c99(1) specification for completeness: <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html>.
My question was about portability to Unix systems, including systems about which I don't know much, such as Solaris or HPUX for example. If... (more) |
— | over 2 years ago |
| Edit | Post #286302 |
Post edited: tfix |
— | over 2 years ago |
| Edit | Post #286302 |
Post edited: |
— | over 2 years ago |
| Edit | Post #286302 |
Post edited: |
— | over 2 years ago |
| Edit | Post #286302 | Initial revision | — | over 2 years ago |
| Question | — |
Is `-isystem` a POSIX cc option? Is `-isystem/path/to/sys/includes` a standard compiler option, or is it a compiler extension implemented by gcc, clang, and maybe other compilers? Can I rely on its availability? I couldn't find the POSIX specification for cc(1). (more) |
— | over 2 years ago |
| Comment | Post #285974 |
Might be, yes. I usually return. But I was reviewing some existing code that used that scheme. But I tend to agree :) (more) |
— | over 2 years ago |
| Edit | Post #285972 |
Post edited: ffix |
— | over 2 years ago |
| Edit | Post #285946 |
Post edited: ffix |
— | over 2 years ago |
| Comment | Post #285974 |
@#8176 In this case, `noreturn` doesn't help the compiler optimize, because it can't optimize (and in fact it would be wrong to optimize, since `pthread_create(3)` expects a function that actually returns, and providing something different (`void`) might be UB (but it happens to be compatible by the ... (more) |
— | over 2 years ago |
| Comment | Post #285974 |
Calling `pthread_exit(3)` instead of returning from the callback is the same as calling `exit(3)` instead of returning from `main()`. It's not like you're killing it with a signal or anything like that. It handles everything gracefully and acts as if it returned: _"The pthread_exit() function term... (more) |
— | over 2 years ago |
| Edit | Post #285972 |
Post edited: |
— | over 2 years ago |
| Edit | Post #285972 |
Post edited: |
— | over 2 years ago |
| Edit | Post #285972 | Initial revision | — | over 2 years ago |
| Question | — |
noreturn function with non-void return type Is it legal ISO C to declare a function as `noreturn` with a non-`void` return type (but of course not actually returning)? As far as I can read from the standard, it seems legal. Example: ``` c noreturn void foo(void x) { pthreadexit(x); } ``` ISO C (N2731, C2x) says: > 6.7... (more) |
— | over 2 years ago |
| Edit | Post #285946 |
Post edited: show len usage |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: Add usage |
— | almost 3 years ago |
| Comment | Post #285946 |
Of course, if one has portability issues, it can just `#define _Nonnull` to nothing for some compilers that lack support (right now only Clang supports it, AFAIK). Or simply manually remove the text. But for this showcase implementation, I'd like to be as explicit as possible, especially in the int... (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: Symmetry |
— | almost 3 years ago |
| Comment | Post #285946 |
I want `_Nonnull` in the standard (I'm preparing a draft, but I'm going slow on that; want it to be perfect), `static` then becomes irrelevant/obsolete. I'd like `[_Nonnull 3]` to mean `[static 3]`, `*_Nonnull` / `[_Nonnull]` to mean `[static 0]` and `[3]` to mean maybe `[static 3]` but maybe `NULL`... (more) |
— | almost 3 years ago |
| Comment | Post #285946 |
1) Convention is that, yes, but `_Nonnull`/`static` can help be more precise about that in the prototype. Helping the caller is not a bad thing to do. 2) `static` is problematic in that it means too much. It means that the pointer is not NULL, _and_ that the underlying storage points to at least N... (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: Add implementation in terms of memccpy(3) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | almost 3 years ago |
| Comment | Post #285952 |
Hmm, yes, `!*dst` is not very readable for a review, except for those used to the idiom. The equivalent `(*dst == '\0')` would probably be better for someone to review it. (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: const, restrict, _Nonnull |
— | almost 3 years ago |
| Comment | Post #285952 |
Yes, I completely forgot about those. That improves readability of the prototype, and also correctness of user code. (more) |
— | almost 3 years ago |
| Comment | Post #285952 |
I did't care too much about the performance of my implementation, as long as the design isn't too flawed to not allow an efficient implementation. When adding to a libc, yes, it would require a bit more complex code. I was more concerned on the interface for now. I'm not sure if it can be faster o... (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: Don't call stpsecpy() as st[rp]ncpy(3), which would be misleading. |
— | almost 3 years ago |
| Comment | Post #285899 |
@Lundin they didn't break backwards compatibility. They added an entirely new set of integer types in parallel to the old one, which is still supported with its buggy design. It's not yet sure if it'll make it into C2x, but Clang supports it, and GCC has an open bug to add support for it. Anyway, ... (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: clarify that stpencpy() creates a string |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: tfix |
— | almost 3 years ago |
| Comment | Post #285899 |
@Lundin Good news for `unsigned short` (and in general for `uintN_t` shorter than `int`): `unsigned _BitInt(N)` from C2x will not promote to `int` (the same applies to `signed` shorts, but bitfields tend to be `unsigned`). So you won't need to clutter bitwise operations with casts all around. (more) |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: Remove spurious 'static' from tests |
— | almost 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | almost 3 years ago |
| Edit | Post #285946 | Initial revision | — | almost 3 years ago |
| Question | — |
stpecpy(): Design a better string copy function that truncates I was directed a few days ago to a post about a string copy function, which IMO improves the commonly known string copy functions, including strlcpy(3BSD), strlcat(3BSD), and strscpy(9). It defines a function, `char strecopy(char dst, char src, char end)`, where end really means one past the end o... (more) |
— | almost 3 years ago |