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 |
|---|---|---|---|---|
| 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) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: Add implementation in terms of memccpy(3) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | about 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) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: const, restrict, _Nonnull |
— | about 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) |
— | about 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) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: Don't call stpsecpy() as st[rp]ncpy(3), which would be misleading. |
— | about 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) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: clarify that stpencpy() creates a string |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: tfix |
— | about 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) |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: Remove spurious 'static' from tests |
— | about 3 years ago |
| Edit | Post #285946 |
Post edited: |
— | about 3 years ago |
| Edit | Post #285946 | Initial revision | — | about 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) |
— | about 3 years ago |