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 #293091 |
atoi(3) is not broken by design. It actually has a good design. It was broken by history.
The standard could perfectly define the behavior on error, and it would be a decent API. They just decided to not define it.
If I were to define the behavior of atoi(3), I would make it equivalent to th... (more) |
— | 7 days ago |
| Edit | Post #293051 |
Post edited: |
— | 17 days ago |
| Edit | Post #293051 | Initial revision | — | 17 days ago |
| Answer | — |
A: How to keep git blame ignored commits up to date? [Disclaimer: This is an alternative workaround, and not really answering your question.] When blaming files in a git repository in which I am working at the moment, I usually blame from the master branch, or from HEAD, or HEAD^, depending on what I'm interested in. That is, don't start blaming on... (more) |
— | 17 days ago |
| Edit | Post #292759 |
Post edited: Add release date of Unix V7 |
— | 27 days ago |
| Edit | Post #292759 |
Post edited: s/fear of/aversion to/ |
— | about 1 month ago |
| Edit | Post #292759 |
Post edited: irrational fear of macros in C++ world |
— | about 1 month ago |
| Comment | Post #289415 |
It was only poorly specified in C89. C89 hallucinated, and trying to disallow 0-size objects, they broke the specification for realloc(p, 0) (but somehow kept malloc(0) and realloc(NULL,0) okay-ish, that is, optionally supporting 0-size objects).
Anyway, C99 had fixed the bug introduced by C89, a... (more) |
— | 2 months ago |
| Comment | Post #292695 |
Yeah, I guess low QoI implementations exist. But the standard shouldn't be bound by them. A newer revision could just tighten malloc(0) to return a unique pointer since it's simpler to implement, it's more useful (simpler to use), and almost ubiquitous. Just like C23 mandated 2's complement. (more) |
— | 2 months ago |
| Comment | Post #292695 |
I've poked a friend of mine to research this, and has done some quite interesting research. This all seems to originate from a bug in SysV r2, which got later standardized by AT&T's SVID out of thin air.
<https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html>
Every sane malloc(0) had alw... (more) |
— | 2 months ago |
| Comment | Post #292784 |
Those are the two return values, but then `errno` can be `0` or `ENOMEM`. I think there are various weird combinations of return value and `errno` in the wild. (more) |
— | 2 months ago |
| Comment | Post #292784 |
In fact, this is different from NULL, and is what makes non-null a better behavior: it's not a special case. (more) |
— | 2 months ago |
| Comment | Post #292784 |
The non-null pointer returned by `malloc(0)` *can* be used. To be more precise, usual pointer arithmetic is allowed on such a pointer. You can do `p + 0` or `p - p`, or `p - 0`.
Of course you cannot access any members, because there aren't any, but other than that, it's a valid pointer like any ... (more) |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: reference the C++ FAQ |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: wfix |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: wfix |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: ffix |
— | 2 months ago |
| Edit | Post #292759 |
Post edited: wfix |
— | 2 months ago |
| Comment | Post #292695 |
Adding an unconditional +1 would significantly hurt readability (a reader may wonder why we're adding 1). However, malloc(foo ?: 1) might make sense (especially in combination with a useful commit message that explains why). But that's still a workaround for an unportable specification. In an idea... (more) |
— | 2 months ago |
| Comment | Post #292695 |
I don't necessarily agree with Linus on everything, but in this case I tend to prefer less branches, even if that means using double de-referencing.
And in the case of malloc(0), there's no double de-referencing issue or of other kind. It's a free removal of the branches.
Here's a dummy exampl... (more) |
— | 2 months ago |
| Edit | Post #292759 | Initial revision | — | 2 months ago |
| Answer | — |
A: Why not call nullptr NULL? It's a long story. Once upon a time, there were three ways to express a null pointer constant: - `NULL` - `0` - `((char ) 0)` This was true at least as far back as Unix V7 (1979). Maybe even further back in time; I don't have older Unix sources at hand. `void ` still didn't exist. ... (more) |
— | 2 months ago |
| Comment | Post #292748 |
Makes sense, I will write one. :) (more) |
— | 2 months ago |
| Comment | Post #292748 |
C++ has a broken definition of NULL as 0, which is a consequence of breaking the semantics of `void *` by not allowing implicit conversions from it to any other pointer.
C doesn't have that problem. And in fact, POSIX requires that NULL be defined as "the value 0 cast to type void *", which is fo... (more) |
— | 2 months ago |
| Comment | Post #292695 |
It's not about the optimization, but rather about readability. Removing branches is one of the things that works best --at least for me-- to reduce the complexity of a function.
It would be along the lines of Linus's good taste example:
<https://youtu.be/o8NPllzkFhE?feature=shared&t=858>
<https... (more) |
— | 2 months ago |
| Comment | Post #292695 |
But think of the following algorithm:
We want to have an array of N elements, which correspond to the emails in my mailbox. Unconditionally allocate an array of N elements of mail_t.
Iterate over those N elements, to do some work.
Free the array when we've finished.
If the algorithm is w... (more) |
— | 2 months ago |
| Comment | Post #292695 |
While giving a list of libraries or other software is typically not wanted, I think a list answer would be the most specific answer to a broader question "How portable is malloc(0) returning a valid pointer?", which is what I really wanted to know.
My system (glibc) returns a valid pointer (which ... (more) |
— | 3 months ago |
| Comment | Post #292694 |
The ISO C paper n2464, which made realloc(ptr, 0) result in UB, contains a table with related information. It's not about malloc, but it documents how implementations behave on realloc(ptr, 0), which is similar (in some implementations, it behaves like malloc(0), while in others it doesn't).
<htt... (more) |
— | 3 months ago |
| Comment | Post #292695 |
Hmmm, it is Undefined Behavior now. That's a bad thing. I think it should have been reworded to be a more generic implementation-defined behavior without making it UB.
I'll have that in mind, and might send a proposal to fix it. Thanks! (more) |
— | 3 months ago |
| Edit | Post #292694 | Initial revision | — | 3 months ago |
| Question | — |
Which platforms return a non-null pointer on malloc(0) What is the portability of `malloc(0);`? - Which platforms return `NULL` without setting `errno`? - Which platforms return a non-null pointer? - Do any platforms have some other behavior? (more) |
— | 3 months ago |
| Comment | Post #292287 |
In git-checkout(1), I couldn't find documentation for `-`.
And:
```
$ git checkout -
error: pathspec '-' did not match any file(s) known to git
```
I guess it's a weird shell extension. :) (more) |
— | 4 months ago |
| Comment | Post #292287 |
And even when I want to get the changes blindly (e.g., I'm contributing a patch (which I have on a branch called `len`) to GCC, and want to rebase my patch on top of the latest GCC master), I want to keep track of what the old state of master was.
That allows me to later run the following command ... (more) |
— | 4 months ago |
| Comment | Post #292287 |
... unless _all_ commits are signed, in which case you can tell git(1) to automatically check signatures on all commits.
So, in some cases, git-pull(1) works. But when something deviates from it, it's better to git-fetch(1) and later do whatever. In general, to prevent those problems _before_ th... (more) |
— | 4 months ago |
| 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) |
— | 4 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 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 opt... (more) |
— | 4 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) |
— | 4 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) |
— | 4 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) |
— | 4 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) |
— | 4 months ago |
| Edit | Post #292263 |
Post edited: ffix |
— | 4 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) |
— | 4 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) |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 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) |
— | 4 months ago |
| Edit | Post #292287 |
Post edited: |
— | 4 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) |
— | 4 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) |
— | 4 months ago |
| Comment | Post #292287 |
git-pull(1) basically means that you can run `man 1 git-pull` (more) |
— | 4 months ago |