It's not clear to me if the author actually understands how staging works and how that affects the commands they suggest. They claim that stashing takes staged changes and then note that after stashing the working tree will be clean. That suggests the post is being dumbed down or the author is misunderstanding things.
Git guidance should almost always start with a brief introduction to the concepts you believe the audience doesn't know or fully understand. To begin with reset and not properly explain the index will just end up being confusing, especially with brief references to hard, soft and mixed resets later on!
I see this so often with power user tools. All power user tools are tools that you can only use reasonably well with some basic understanding. They are made not to be understood in the easiest fashion but to handle all complexities of a problemset as efficiently as possible. Therefore it sometimes seems harder to use from the outside, but actually the hardness comes from the problem it solves, not the tool.
So yeah, if you really want to use git well, learn its internals. It takes some time but actually not even hard. After reading the Git Book once I was even able to implement my own git (of course without performance considerations).
Really? I'm not sure if this is bait or not, but 64b time_t extends the epoch over 200 billion years into the future. I figure we'll handle it in Linux 7.0 or 8.0 at the earliest :P
It's probably not bait. It's easy to intuitively think 64 bits is only double. I do these calculations regularly as security professional (password strength for example) but not everyone does.
Thanks, I hate it. I'm a bit bemused about this bizarro case_N.h trickery. I'm also almost positive __COUNTER__ would be adequate and entirely remove the need for __LINE__ as suggested in the addendum which is likely to be quite large in any non-trivial source unit. I mean, something gcc this way comes I guess...
This puzzled me also. Perhaps it's been kicked down the road as an engineering problem and we'd end up with a hydrogen extraction system which is responsible for that part. We'd probably need to feed protons back in though...
The first paragraph of that question says 'address the possibility that a US company may have had spacecraft launched into orbit without the appropriate approval from the US government.'
This is a discussion of another offence against a different document and assumes the first offence against FCC regulations is valid. Be careful not to conflate the two, one causes the other.
I make heavy use of cardless cash via my bank's app when I need to visit an ATM. I haven't had my wallet with me for more than half an hour at a time this year.
This isn't wrong but I've got issues with some of the examples, especially the lack of a solution for #2 and #4.
#2 is referred to as an unsafe macro because of the multiple evaluation of its arguments. In some cases this is fine but it may need to be documented that the macro is unsafe for future users. It is also entirely possible to convert these macros into safe ones if you're willing/able to use GNU C extensions like typeof. The SEI CERT secure C wiki has a good reference for this at [0].
#3 presumes you want to compose functions but I'd suggest that by doing so you are writing bad C. Because of the lack of any type of side-band error reporting (exceptions etc) you must presume that your functions will always return a sane/non-error value. That's not a good assumption even for your own code and definitely not for the C library or any other libs. In addition, this is just another unsafe macro which could be made safe as above.
#4 doesn't explain the solution to the problem it poses which is annoying because it's the most important one IMO. There are a number of ways to make a multi-line macro safe for use in an unbraced expression body. My preferred way is to define the macro with a always false-post check while loop. e.g.
#define MY_NAME_JEF(x) do{ \
const char jef[] = "jef"; \
printf("my name %s, not %s\n", jef, x); \
}while(0)
Note the lack of a trailing semi-colon. This is because we expect the macro to be terminated with its own semi-colon. Stupid example but it gets the point across I suppose.
Check out the secure C wiki, it's full of gems which can help you avoid issues with macros, and much more.
> #2 is referred to as an unsafe macro because of the multiple evaluation of its arguments. In some cases this is fine but it may need to be documented that the macro is unsafe for future users.
In the early days of C programming, a naming convention was adopted to warn about this. If you wrote a macro that might have multiple evaluation of its arguments, you named it in UPPERCASE as a warning:
#define MIN( a, b ) ( (a) < (b) ? (a) : (b) )
This practice spread into pretty much all macro definitions. If you defined a macro of any sort, you gave it an uppercase name, even if the macro didn't take any arguments at all and therefore warning about multiple evaluation was moot:
#define MAX_SIGNED_SHORT 32767
From there the notion spread into other languages that all constants ought to have UPPER_CASE_NAMES. So this is why you see JavaScript code like:
Although I get that the original intent was different. I actually find making all constants uppercase a useful practice. When reading the code, it's easy to see what is a local variable and what is not, or at least not supposed to be.
That's a K&R (Kernighan and Ritchie) style function declaration. Compilers still support it but the version you'd be more familiar with (ANSI C style) has been standard since at least the late 80s IIRC. ANSI C was standardised in 1989 but that process had been in progress for something like 5 years beforehand.
Specifically, everything is an integer with the auto lifetime (gets discarded with the stack frame) unless otherwise specified.
I think most modern compilers will warn on encountering such short hand due to the common error of accidentally declaring integers when you meant to assign a value to a variable you forgot to declare.
Did you genuinely find it difficult to parse the comma delimited representation near the bottom of the article? Just curious. It seemed very natural to me, a minor variation on British style thousand separators.
Myself, not really given the context in the article. If I was shown this without context it would be pretty confusing. Using : would be better as or would suggest clock which is base 12 plus base 60...
Letters are clearer still if given the base identifier - commonly subscript number.
The suggested notation would make for interesting puzzles.
Not sure what you mean by a sub-session but my perusal suggests an entirely new conversation key is negotiated by current participants when those participants change. The spec doesn't say anything about requiring everyone to be online but I think it's implied. It may be that not everyone has to be online at the same time (which would just delay the negotiation IIUC) which is interesting but I wonder what would happen if an offline participate rejoins and doesn't get a full transcript from when they were last online with the carrier. Sounds entirely possible for an IRC/XMPP carrier with people not using bouncers.
I also think that it's implied, maybe like Telegram Private Chat - when you need to wait the peer to go online before complete the key exchange.
However when scale to a group with N peers.. we need to wait all of them, maybe they do waking up the peer's via Silent Notification or something like that..
Git guidance should almost always start with a brief introduction to the concepts you believe the audience doesn't know or fully understand. To begin with reset and not properly explain the index will just end up being confusing, especially with brief references to hard, soft and mixed resets later on!