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 |
|---|---|---|---|---|
| Question | — |
Storing more bytes than a union member has, but less than the union size, with memcpy(3) Let's say we have an object, we store it in a union (into some other narrower type, but with memcpy(3), so it's allowed --I guess--), and then read it from the union via it's original type (so no alignment issues or anything. ```c $ cat union.c #include struct s { int a; int b;... (more) |
— | 12 months ago |
| Comment | Post #288023 |
Regarding VLA notation, is it mandated by the standard, or is it optional? Anyway, I'm not going to complain about good taste extensions to the language:) I'll complain about the real issues of it (IMO): while it solves the readability issues, it doesn't solve type safety. In fact, that's one of t... (more) |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year 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) |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288023 | Initial revision | — | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year ago |
| Edit | Post #288017 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288017 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288017 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288017 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288017 |
Post edited: |
— | about 1 year ago |
| Edit | Post #288017 | Initial revision | — | about 1 year 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) |
— | about 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 |
Post edited: |
— | about 1 year ago |
| Edit | Post #287905 | Initial revision | — | about 1 year 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 1 year 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) |
— | over 1 year ago |
| Edit | Post #287754 |
Post edited: |
— | over 1 year ago |
| Edit | Post #287754 | Initial revision | — | over 1 year 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) |
— | over 1 year ago |