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 #290316 |
@#8176 You can't, in the sense that the expression won't be undefined (because `#undef` is interpreted by the preprocessor, there are still no identifiers that aren't macros; it's just text), but you can, in the sense that your program will be valid.
```c
#undef stdin
#define stdin something_els... (more) |
— | 3 months ago |
| Comment | Post #290316 |
@#8176 A minor nitpick on your comment: `#undef` doesn't need to be guarded by `#ifdef`. `#undef` is defined by ISO C to be a no-op if there's no such macro. <http://port70.net/~nsz/c/c11/n1570.html#6.10.3.5p2> (more) |
— | 3 months ago |
| Comment | Post #290215 |
Very interesting hacks about commas with macros! I'd say if you write a macro that expands to something with a comma operator, you either want that hack explicitly for some obscure reason, or should be using parens in that macro so that it doesn't misbehave with other macros. But yeah, very interes... (more) |
— | 5 months ago |
| Comment | Post #290215 |
But in function argument lists, the comma operator cannot appear, so in a replacement, the comma operator will never appear in the top level, right?
That is, how can I embed a comma operator in a macro call that could possibly interfere with the macro body?
```c
macro(a, (b, c));
```
That ... (more) |
— | 5 months ago |
| Edit | Post #290205 |
Post edited: |
— | 5 months ago |
| Edit | Post #290205 |
Post edited: |
— | 5 months ago |
| Edit | Post #290205 |
Post edited: |
— | 5 months ago |
| Edit | Post #290205 | Initial revision | — | 5 months ago |
| Question | — |
When should I parenthesize macro arguments in C? I've seen macros use parentheses to enclose its arguments. Most of these make sense, as in ```c #define sum(a, b) ((a) + (b)) ``` The outer prevents the following: ```c #define sumbad(a, b) (a) + (b) s = sumbad(x, y) z; // (x) + (y) z ``` The inner prevents the following: ... (more) |
— | 5 months ago |
| Comment | Post #277341 |
C has the #error directive, and C23 will have the #warning directive.
<https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2686.pdf> (more) |
— | 6 months ago |
| Comment | Post #289497 |
Sorry for not mentioning you. @#8176 (more) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months ago |
| Comment | Post #278658 |
Regarding POSIX rationale, I don't know. Their website puts me off with several layers of registration and nonsense. (more) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months ago |
| Edit | Post #290024 | Initial revision | — | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months ago |
| Comment | Post #281519 |
strlcpy(3) will be blessed by POSIX in Issue 8 (that is, POSIX.1-202x). (more) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months ago |
| Comment | Post #289891 |
You could maybe use formail(1) in this script too, although I didn't know that tool until today. (more) |
— | 6 months 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) |
— | 6 months 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) |
— | 6 months 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) |
— | 8 months 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) |
— | 10 months 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) |
— | 10 months ago |
| Comment | Post #285051 |
You're right. I wish zero-sized arrays get allowed some day in array parameters. :) (more) |
— | 11 months 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) |
— | 11 months ago |
| Edit | Post #288138 |
Post edited: |
— | 11 months ago |
| Edit | Post #288138 |
Post edited: What about allocated memory? |
— | 11 months ago |
| Edit | Post #288138 |
Post edited: |
— | 11 months ago |
| Edit | Post #288138 |
Post edited: |
— | 11 months ago |
| Edit | Post #288138 | Initial revision | — | 11 months 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) |
— | 11 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 |