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 #289497 |
Sorry for not mentioning you. @#8176 (more) |
— | about 1 year ago |
| Comment | Post #289415 |
@#8176
In the case of `{0}`, it looks rather weird. But imagine this structure:
```
auto struct s {
int8_t x;
int32_t y;
} s = {.x = foo, .y = bar};
```
Initializing the padding could make it slower. I agree that the standard could have special-cased `{0}`, since anyway it'... (more) |
— | about 1 year ago |
| Comment | Post #289415 |
Here's an example:
```c
struct s2 {
int8_t c;
int32_t i;
};
struct s1 {
int8_t c;
int32_t i;
struct s2 s;
};
void f(void)
{
struct s1 x = {0};
}
```
The padding within `x` itself would not be zeroed, but the padding within `x.s` would be zeroed (because `x... (more) |
— | about 1 year ago |
| Comment | Post #289415 |
@#8176 I got a quick response from JeanHeyd. The standard seems unclear in the wording, and a reasonable interpretation could be that (some) padding is not zeroed. I'll clarify below the quotes.
6.7.9p21 "If there are fewer initializers in a brace-enclosed list than there are elements or members... (more) |
— | about 1 year ago |
| Comment | Post #278658 |
Regarding POSIX rationale, I don't know. Their website puts me off with several layers of registration and nonsense. (more) |
— | about 1 year ago |
| Comment | Post #278658 |
7.19p3 <http://port70.net/~nsz/c/c11/n1570.html#7.19p3> says "[NULL] expands to an implementation-defined null pointer constant".
I thought the text in there allows anything in `NULL`, and isn't restricted by 6.3.2.3p3 (which you quoted).
I interpret 6.3.2.3p3 as saying that you can use any of ... (more) |
— | about 1 year ago |
| Comment | Post #289415 |
Agree. That blog seems wrong (I'll write to JeanHeyd later). This morning I was a bit dense, and didn't find the relevant paragraph. 6.7.9p21 seems to be it <http://port70.net/%7Ensz/c/c11/n1570.html#6.7.9p21>
So, it seems both `{0}` and `{}` do the right thing for pointers, and so does implici... (more) |
— | about 1 year ago |
| Edit | Post #290024 | Initial revision | — | about 1 year ago |
| Answer | — |
A: Is strcpy dangerous and what should be used instead? strcpy(3) can be safe. Some compilers, such as GCC and Clang, use a feature test macro, `FORTIFYSOURCE`, (see featuretestmacros(7) ), to ask the compiler to add some checks to make sure that buffer overflow doesn't happen. If the bug is detected at compile time, it will raise a warning. If the b... (more) |
— | about 1 year ago |
| Comment | Post #281519 |
I prefer the name strlcpy() rather than strcpy_s(), since it's not inherently safer, but just a different function. (more) |
— | about 1 year ago |
| Comment | Post #289415 |
(D'oh! yep, I meant a null pointer. You're right being pedantic. :)
Hmm, sorry, for some reason I thought `{0}` was shorthand for memset(3). It isn't.
Nevertheless, the wording in the answer "equivalent to initializing everything to zero" is technically wrong, I'd say, since the word zero do... (more) |
— | about 1 year ago |
| Comment | Post #278658 |
ISO C allows any kind of garbage in NULL, such as `0`, or `(void *)-1`. However, POSIX mandates that it be "an integer constant expression with the value `0` cast to type `void *`".
This is helpful if all you care about is POSIX. Not so much if you don't. (more) |
— | about 1 year ago |
| Comment | Post #289415 |
Re: freestanding: Heh, I guess. :) But maybe being in POSIX helps get it into ISO C... in a decade or two :D (more) |
— | about 1 year ago |
| Comment | Post #281519 |
I recently wrote string_copying(7), which discusses all standard functions that have been historically used for copying strings (even if incorrectly), and also suggests some non-standard interfaces for some cases.
<https://man.archlinux.org/man/string_copying.7.en> (more) |
— | about 1 year ago |
| Comment | Post #281519 |
strlcpy(3) will be blessed by POSIX in Issue 8 (that is, POSIX.1-202x). (more) |
— | about 1 year ago |
| Comment | Post #289415 |
`memccpy(dest, src, '\0', n)` isn't safer than `strncpy(dest, src, n)`. Neither of those functions guarrantees a string in `dest`. Both functions will fail to terminate `dest` with a `NUL` if it doesn't fit.
In the case of strncpy(3), this is fine, as this function is only appropriate for fixed-... (more) |
— | about 1 year ago |
| Comment | Post #289415 |
strncpy(3) is still appropriate in some cases: fixed-width character arrays. An example of an interface that uses this is `struct utmp` (see utmp(5)). The fields `utmp::ut_line`, `utmp::ut_user`, and `utmp::ut_host` are _not_ strings, and should not be written with strlcpy(3), nor any other string ... (more) |
— | about 1 year ago |
| Comment | Post #289415 |
`{0}` initializes to `0`. `{}` initializes to `0`, except pointers, which are initialized to `NULL`. It's pedantic, but in some unicorn implementations it may be meaningful. (more) |
— | about 1 year ago |
| Comment | Post #289497 |
```c
size_t n, size;
int *p;
n = MIN(PTRDIFF_MAX, SIZE_MAX) - 1; // A huge valid number of elements.
//size = sizeof(int[n]); // Is this even legal?
size = n * sizeof(int); // This wraps around, producing a bogus size.
p = malloc(size); // No UB, but...
if (p)
exit(1);
p[n - 1... (more) |
— | about 1 year ago |
| Comment | Post #289497 |
Hi Lundin!
I agree the term overflow is incorrectly used in the man(7) page. I invite you to send a patch for that. Please check <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>. :) (more) |
— | about 1 year ago |
| Comment | Post #289891 |
You could maybe use formail(1) in this script too, although I didn't know that tool until today. (more) |
— | about 1 year ago |
| Comment | Post #289891 |
Let's say I want to move mails from `someone@example.com` to `/dest/dir`:
```sh
print_filenames_that_would_be_moved \
| xargs grep -l '^From: someone@example.com' \
| xargs mv -t /dest/dir
``` (more) |
— | about 1 year ago |
| Comment | Post #289891 |
Why not do somehting like this?
```sh
print_filenames_that_would_be_moved \
| xargs grep -e '^From: ' -e '^Subject: ' /dev/null
``` (more) |
— | about 1 year ago |
| Comment | Post #287754 |
Is it? I just came to this question again because of flexible array members.
See <https://gustedt.wordpress.com/2011/03/14/flexible-array-member></https:> for more context.
The allocation is usually one of these:
```c
malloc(sizeof(s) + sizeof_member(s, fam[0]) * N);
malloc(offsetof(s, fa... (more) |
— | over 1 year ago |
| Comment | Post #288247 |
I think the object pointed to by dest is a `struct t`, not a union, since I use a pointer to the member. Only if I had casted it to the union type, or if I had used the union directly, it would have been the union, I think. (more) |
— | over 1 year ago |
| Comment | Post #285051 |
You could maybe even constexpr that :) I guess accepting such evilness is due to being more complex to reject, rather than an intention of defining the behavior. Nevertheless, I do think that `param[0]` has a valid use case in pointers to one-past-the-end of an array, which are useful for bounds. (more) |
— | over 1 year ago |
| Comment | Post #285051 |
You're right. I wish zero-sized arrays get allowed some day in array parameters. :) (more) |
— | over 1 year ago |
| Comment | Post #285051 |
It might be worth noting that `static` requires that the array size is at least `1`. So, it's not valid C to have `int x[static 0]` as a parameter, which can be otherwise useful as an end-of-array marker.
For example, one may design a function which takes an array and a pointer to one-after-the-l... (more) |
— | over 1 year ago |
| Edit | Post #288138 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288138 |
Post edited: What about allocated memory? |
— | over 1 year ago |
| Edit | Post #288138 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288138 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288138 | Initial revision | — | over 1 year ago |
| 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) |
— | over 1 year 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) |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 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) |
— | over 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) |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 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) |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 |
Post edited: |
— | over 1 year ago |
| Edit | Post #288023 | Initial revision | — | over 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) |
— | over 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) |
— | over 1 year ago |