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 |
I think git-checkout(1) does not have a `-` argument. There are other probably more specific ways to name the last state of HEAD in git(1), which I never remember because those are things I rarely use (thankfully, I don't break my repos often :).
Regarding the want to match the remote: yes, that'... (more) |
— | 7 months ago |
| Comment | Post #292287 |
I originally wrote git-pull(1) in the title too, but thought that it might cause confusion in the title, so I changed it to `git pull` in the title but kept git-pull(1) in the text. :)
In running text, when I mean exactly `git pull` (with no flags), I use that. When I mean the command, with any ... (more) |
— | 7 months ago |
| Comment | Post #292291 |
I wish I could do that, but I have to work with other authors who don't sign their commits. :|
But yeah, that's something quite useful for my own projects. Thanks! (more) |
— | 7 months ago |
| Comment | Post #292286 |
Both.
The most common worry is to lose my working copy and having a hard time recovering it (git-reflog(1) usually helps recover those).
However, I'm also worried about a git server being hacked and me pulling from it and blindly incorporating those changes as if they were fine.
I have a git... (more) |
— | 7 months ago |
| Comment | Post #292287 |
I think the comment should be enough. It's common to explain these details in comments. :)
It is actually common in Unix contexts to use this notation, BTW, even outside of manual pages. Hopefully, using it more will make people more used to it. (more) |
— | 8 months ago |
| Comment | Post #292263 |
Thanks! I've changed most blocks into text. I've kept formatting in a few where it was useful. (more) |
— | 8 months ago |
| Edit | Post #292263 |
Post edited: ffix |
— | 8 months ago |
| Comment | Post #292291 |
git-log(1):
```
%G?
show "G" for a good (valid) signature, "B" for a bad
signature, "U" for a good signature with unknown validity, "X"
for a good signature that has expired, "Y" for a good
signature made by an e... (more) |
— | 8 months ago |
| Comment | Post #292291 |
Most of the time it doesn't, but when it does it's already late. :)
And yes a git-log(1) before the pull/fetch should be enough for being able to revert, but then it's harder to see the diff, that is, see what's only on the remote.
Even if you trust the author of the remote, you may not trust ... (more) |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Comment | Post #292291 |
Hmm, I agree. Dangerous was too strong of a word; I've lessened that to clarify that it's not a security concern, but just an inconvenience.
However, I don't agree that git-reflog(1) solves the inconvenience. It is part of the inconvenience. It just makes it not a total disaster. But a git-log... (more) |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Comment | Post #292287 |
For merge, I prefer to specifically ask for a fast-forward. Having merge.ff = only could give surprises when I work in a different system.
I use the following alias for fast-forwarding merges:
```
[alias]
ff = merge --ff-only
```
So that I run `git ff <commit>` (more) |
— | 8 months ago |
| Comment | Post #292287 |
Since I advocate against git-pull(1) at all (I never ever use it, for the second reason), I think recommending a config for it could be counter-productive. (more) |
— | 8 months ago |
| Comment | Post #292287 |
git-pull(1) basically means that you can run `man 1 git-pull` (more) |
— | 8 months ago |
| 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) |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Edit | Post #292287 |
Post edited: |
— | 8 months ago |
| Edit | Post #292287 | Initial revision | — | 8 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) |
— | 8 months ago |
| Edit | Post #292286 | Initial revision | — | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 months ago |
| Edit | Post #292263 |
Post edited: ffix |
— | 8 months ago |
| Edit | Post #292263 |
Post edited: Split at section headings |
— | 8 months ago |
| Edit | Post #292263 |
Post edited: |
— | 8 months ago |
| Edit | Post #292263 | Initial revision | — | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 8 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) |
— | 11 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) |
— | 11 months ago |