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 #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Comment | Post #288023 |
As for having to read the definition of the macros: that really goes for any code you read. I don't know why these wrappers would be any different. Encapsulation is not bad (it can be bad, but it's not necessarily bad); especially if it solves a long-standing issue of type safety.
How to read th... (more) |
— | almost 2 years ago |
| Comment | Post #288023 |
I guess your comment only applies to the macros, and not the Unix-only *array() variants like reallocarray(3), right?
The malloc API is not really horrible; it's good, as far as C functions go. There's really not much more that could be acomplished, in terms of type safety. Overflow due to multi... (more) |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Comment | Post #285910 |
The rule for `sizeof(*p)`, at least as I used it in the past, was more like:
```c
SOMETHING = malloc(sizeof(*SOMETHING));
```
Whatever that `SOMETHING` is, the above rule works (except for `flexy`, of course :).
```c
p = malloc(sizeof(*p));
p[i] = malloc(sizeof(*p[i]));
```
---
Di... (more) |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288023 | Initial revision | — | almost 2 years ago |
| Answer | — |
A: How to properly use malloc? There are several things to consider when calling the malloc(3) family of functions: - `nelem sizeof(elem)` or `sizeof(elem) nelem`? - Use the type or the pointer name in `sizeof()`? - To cast or not to cast? TL;DR: Use a simple and readable interface, and let it handle the safety for... (more) |
— | almost 2 years ago |
| Comment | Post #288020 |
Moreover, I've just checked the C2x draft and a proposal that got accepted, and found something that seems to say that this is UB:
Accepted proposal for C2x:
<https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2861.pdf>
C2x (latest draft that I know of):
<https://www.open-std.org/JTC1/SC22... (more) |
— | almost 2 years ago |
| Comment | Post #288020 |
> since p and q are now indeterminate, nothing can be assumed about them - their values are unspecified.
Nothing can be assumed about the value of p.
> since p used to hold a valid value and since free() can't change p, then p cannot hold a trap representation in this specific case.
Yet we c... (more) |
— | almost 2 years ago |
| Comment | Post #286189 |
strncat(3) is a good function. It's just that is has been misused. I thought it was a useless broken-by-design function, until I found by chance a good use of it in groff(1)'s source code (https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?id=f720813c5f512627a246115a255989ad6... (more) |
— | almost 2 years ago |
| Comment | Post #286189 |
@#8176 linux.die.net has quite outdated versions of the man pages; at least I can confirm that of the Linux man-pages, which I maintain. The only official online version of the Linux man-pages is this PDF: https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.04.01.pdf. There's... (more) |
— | almost 2 years ago |
| Comment | Post #287083 |
> Someone somewhere might still have the great idea to define a macro called "index" in a public header file...)
And someone might be 4.3BSD and POSIX.1-2001 :D.
It's a function, though, but that already makes it reserved, so I wouldn't call anything `index`, except maybe a structure member.
O... (more) |
— | almost 2 years ago |
| Edit | Post #288017 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288017 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288017 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288017 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288017 |
Post edited: |
— | almost 2 years ago |
| Edit | Post #288017 | Initial revision | — | almost 2 years ago |
| Question | — |
Can freed pointers undergo lvalue conversion? ``` char p, q; p = malloc(1); free(p); q = p; // lvalue conversion ``` Is the last lvalue conversion (`= p;`) Undefined Behavior or not? We didn't take the address of the local `p`. C11::6.3.2.1/1 contains the following sentence regarding lvalue conversions: > If the lvalue des... (more) |
— | almost 2 years ago |
| Comment | Post #287917 |
`int* ptr = original; free(original); if(ptr == original)`: That would actually be different. That one is in fact Undefined Behavior, since you're reading the pointer value and not its representation. To make it unspecified behavior, you's need to call memcmp(3). (more) |
— | about 2 years ago |
| Comment | Post #287917 |
I guess using a `free(3)`d pointer in the same way, instead of an uninitialized `int32_t` local, would still be *unspecified* behavior, since we can't trap because `memcmp(3)` uses char to read the representation. Am I correct? I used `int32_t` just to simplify the question, but it's true that `int... (more) |
— | about 2 years ago |
| Comment | Post #287908 |
I chose 0 on purpose to avoid endianness issues, and also to make sure I know the translation from representation to value. I could have also chosen maybe `0x1111` or something similar which isn't affected by endianness, but `0` was just simpler.
I'm almost sure representation 0 has to correspond... (more) |
— | about 2 years ago |
| Comment | Post #287908 |
memcmp(3) really compares bytes rather than bits. The proof is that whatever the bit endianness is, I won't be able to detect it using memcmp(3). I'd need bitfields for that. (more) |
— | about 2 years ago |
| Comment | Post #287908 |
I don't think your answer covers the part about the variable containing an invalid value (possibly a trap representation). This answer would be fine for the same question if the question didn't mention reading from an uninitialized variable (which was the main point I was interested in). (more) |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287905 | Initial revision | — | about 2 years ago |
| Question | — |
memcmp(3) memory containing invalid values What does it mean that we can use memcmp(3) on invalid values? ISO C allows comparing an invalid value through memcmp(3), because it doesn't read the value, but rather its representation, and "reading the representation is never Undefined Behavior" (or so I've been told). The following code inv... (more) |
— | about 2 years ago |
| Comment | Post #287760 |
If instead of a `struct` containing an array, it would be a `struct` containing many fields (e.g., `struct s2 {int a; int b; int c; int d;};`), would it change your answer in any sense? Let's say I do `struct s2 *s2 = malloc(offsetof(struct s2, c));`, and later I only use fields `a` and `b`. Would ... (more) |
— | about 2 years ago |
| Edit | Post #287754 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287754 | Initial revision | — | about 2 years ago |
| Question | — |
Is partial allocation of an object Undefined Behavior? Is it valid to partly allocate an object, as long as you only use the allocated part of it? ```c #include #include struct s { int i[100]; }; int main(void) { struct s s; s = malloc(50 sizeof(int)); s->i[30] = 7; printf("%d\n", s->i[30]); free(s); } ``` ```sh al... (more) |
— | about 2 years ago |
| Edit | Post #287748 |
Post edited: |
— | about 2 years ago |
| Edit | Post #287748 |
Post edited: Use wider types, which will more-likely show atomicity problems |
— | about 2 years ago |