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 #292287 |
Sure. It's Unix notation for commands that have a manual page.
See this extract from the intro(1) manual page (the first page of the Linux programmer's manual):
```
$ MANWIDTH=72 man intro | sed -n '/Getting information/,+12p'
Getting information
There are thousands of commands, eac... (more) |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 months ago |
| Edit | Post #292287 | Initial revision | — | 4 months ago |
| Answer | — |
A: Is `git pull` dangerous? `git pull` is dangerous, but not a security problem. The only danger is that it's difficult or inconvenient (but not impossible) to recover to the state prior to the pull, if it would be necessary. Merge commits The remote branch might have diverged from your own, in which case git will au... (more) |
— | 4 months ago |
| Edit | Post #292286 | Initial revision | — | 4 months ago |
| Question | — |
Is `git pull` dangerous? I heard `git pull` is dangerous. - Is it really dangerous? - If so, why or how is it dangerous? - Are there any flags that mitigate or remove the danger? - What are the alternatives if it is dangerous? (more) |
— | 4 months ago |
| Comment | Post #292264 |
BTW, the rules for integer constant expressions _do_ allow increment and decrement operators, as long as they're not evaluated.
<https://port70.net/~nsz/c/c11/n1570.html#6.6p3>
> Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except whe... (more) |
— | 4 months ago |
| Comment | Post #292264 |
We're working in making GCC have stricter rules about function parameters with array notation.
Now, you can do:
```c
void f(int a[3]);
void f(int a[4]);
```
and it will work.
This is clearly a bug, and we're working on making that a constraint violation.
Once we have array bounds be con... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> Which in turn brings on more
> poorly-defined behavior nobody considered...
> just look at C23 function attributes, it's a mess.
Agree. C23 is full of nonsense (it has nice things, though; not everything is bad). To me the most horrible feature is `nullptr` and `nullptr_t`.
I'm try... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> IMO the C committee should be focusing on
> fixing known problems and weeding out poorly-defined behavior,
> instead of inventing new features that nobody asked for.
Some programmers have explicitly asked for it in the past (including me). And now I have implemented it in an existing c... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Just to clarify, while elementsof() only cares about the top-level array bound for deciding if it results in an integer constant expression or not, once it is decided that it's a run-time value, it evaluates the entire operand (just like sizeof also evaluates everything). (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> what about [n][expr]?
> [n] cannot be an integer constant expression either,
> if n is a declared object/lvalue.
Then the entire expression (including `expr`) is evaluated.
```c
#define nitems(a) (sizeof(a) / sizeof(*(a)))
int n=9;
int a[3][4];
nitems(a); // i.c.e. of... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> But in order to determine if something is a VLA or not,
> we need to know if the array bounds
> is an integer constant expression or not.
That's true. Just like it's already true with the usual sizeof division. elementsof() needs to consider only the outermost bound for deciding if th... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> One obvious problem that needs consideration is VLA.
> C already struggles with sizeof(vla) being evaluated in run-time.
> Meaning that this elementsof would too need to be evaluated in run-time,
> if given a VLA as parameter,
> as mentioned in the text.
Not exactly.
sizeof() does ... (more) |
— | 4 months ago |
| Comment | Post #292264 |
C2y has already added some changes to the wording of integer constants, integer constant expressions, and literals: n3239.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3239.htm>
After those changes, elementsof() will result also in an "integer constant expression" for the case under discu... (more) |
— | 4 months ago |
| Comment | Post #292264 |
Re:
> No, that's not an integer constant expression.
> The constraits for constant expressions
> do not allow increment/decrement or assignment etc.
> Even if the meaning of the example was to say that
> n++ is not considered since
> 7 is an integer constant expression
Indeed, n++ is not... (more) |
— | 4 months ago |
| Comment | Post #292264 |
```c
alx@debian:~/tmp/gcc$ cat lie.c
int
main(void)
{
int a[3];
int (*ap)[3] = &a;
return __elementsof__(*(int(*)[4])ap);
}
```
```sh
alx@debian:~/tmp/gcc$ /opt/local/gnu/gcc/elementsof/bin/gcc -Wall -Wextra lie.c
alx@debian:~/tmp/gcc$ ./a.out; echo $?
4
``` (more) |
— | 4 months ago |
| Comment | Post #292264 |
Similarly, if you lie to NITEMS()
```c
#define NITEMS(a) (sizeof(a) / sizeof(*(a)))
int arr[3];
int (*arrptr)[3] = &arr;
assert(NITEMS(* (int(*)[4])arrptr) == 4);
```
You'll get 4. Operators don't care if you lie to them. (more) |
— | 4 months ago |
| Comment | Post #292264 |
If you lie to the compiler, the behavior is like with other operators: you'll successfully lie. (I should add some tests for this; I actually didn't test that in my implementation.)
Since the object is not accessed, it is not undefined behavior to cast it to something else, as long as you don't c... (more) |
— | 4 months ago |
| Comment | Post #292264 |
It is a contraint violation if the type is incomplete, and so a diagnostic is mandatory.
This is mentioned in the `Proposal description`. And in the proposed wording, it is clearly stated in 6.5.4.4:
Constraints (p1)
or to an expression that designates a bit‐field member... (more) |
— | 4 months ago |
| Edit | Post #292263 |
Post edited: ffix |
— | 4 months ago |
| Edit | Post #292263 |
Post edited: Split at section headings |
— | 4 months ago |
| Edit | Post #292263 |
Post edited: |
— | 4 months ago |
| Edit | Post #292263 | Initial revision | — | 4 months ago |
| Question | — |
New elementsof() operator Original problem: Arrays in C are problematic. They are transformed into pointers too easily. Especially when they are function parameters (they decay to pointers just after the function parameter list). It's hard to get the number of elements of an array in a safe and portable way, and many p... (more) |
— | 4 months ago |
| Comment | Post #291982 |
@#8176 Re: implicit conversions and using functions instead:
To SWAP(), I pass pointers, so I don't think implicit conversions should be a problem here.
To MIN() and MAX(), implicit conversions are usually not a problem, as long as the original types are of the same sign. The compiler should i... (more) |
— | 5 months ago |
| Comment | Post #291982 |
@#8176 It has been hard to come up with an input that would trigger double evaluation **and** would be valid input to MIN() and MAX(), but here it is:
```c
$ cat auto.c
#include <stdio.h>
int
main(void)
{
int i = 3;
int j[2 * i];
int (*p)[2 * i];
printf("%d\n", i);
p = &j;... (more) |
— | 5 months ago |
| Comment | Post #291982 |
And here's my implementation of MIN(3) and MAX(3):
```c
#define MIN(x, y) \
({ \
auto x_ = x; \
auto y_ = y; ... (more) |
— | 5 months ago |
| Comment | Post #291982 |
Here's my implementation of swap():
```c
#define is_same_type(a, b) __builtin_types_compatible_p(a, b)
#define is_same_typeof(a, b) is_same_type(typeof(a), typeof(b))
#define SWAP(ap, bp) do \
{ ... (more) |
— | 5 months ago |
| Comment | Post #291982 |
Re: "`If anyone can actually give a non-subjective example of when it makes sense to use auto to clearly improve everyday C code, I will certainly reconsider.`":
I fully agree with your reasons to consider `auto` dangerous and avoid it as much as possible.
However, there's one case where `auto`... (more) |
— | 5 months ago |
| Comment | Post #286605 |
You're welcome! :-)
However, I'd rather recommend my newer answer, which has a much easier user experience (although it requires a specific MUA: neomutt(1); unless you find another one that works similarly):
<https://software.codidact.com/posts/286573/291329#answer-291329> (more) |
— | 8 months ago |
| Comment | Post #286588 |
But me as a maintainer or co-maintainer of several widely-used FOSS projects? I'd say at least a worrying little bit. (more) |
— | 8 months ago |
| Comment | Post #286588 |
I didn't know of any, but I recently patched neomutt(1) to behave like that. See my new answer: <https://software.codidact.com/posts/286573/291329#answer-291329>
Usage:
`.gitconfig`:
```
[sendemail]
sendmailcmd = neomutt -C -H - && true
``` (more) |
— | 8 months ago |
| Comment | Post #286588 |
If such a malicious sender uses the `Reply-To` header field, as in this example:
```
From: well-known@example.com
Reply-To: well-known@foo.com
```
That reply-to address may look like a valid alternative address of the sender, and really be an address of an attacker.
As long as the imperso... (more) |
— | 8 months ago |
| Edit | Post #291329 |
Post edited: |
— | 8 months ago |
| Edit | Post #291329 | Initial revision | — | 8 months ago |
| Answer | — |
A: PGP sign emails sent with git-send-email(1) git-send-email(1) uses sendmail(8) as the MTA by default. However, this can be changed by passing the `--sendmail-cmd` option. ``` $ man git-send-email | sed -n '/--sendmail-cmd=/,/^$/p' --sendmail-cmd= Specify a command to run to send the email. The command should be s... (more) |
— | 8 months ago |
| 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) |
— | 11 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) |
— | 11 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) |
— | about 1 year 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) |
— | about 1 year ago |
| Edit | Post #290205 |
Post edited: |
— | about 1 year ago |
| Edit | Post #290205 |
Post edited: |
— | about 1 year ago |
| Edit | Post #290205 |
Post edited: |
— | about 1 year ago |
| Edit | Post #290205 | Initial revision | — | about 1 year 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) |
— | about 1 year 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) |
— | about 1 year ago |