> And I couldn't find any hints that va_list and pointers can be mixed,
> and no hints that they can't either
C99, Section 7.15, simply says that it "is an object type suitable for
holding information needed by the macros va_start, va_end, and
va_copy".
So clearly not guaranteed to be mixable wit
You need to cast those arguments of tolower to (unsigned char). That's
arguably a bug of the language.
Character values less than zero aren't valid for tolower, unless they
happen to equal
EOF in which case the tolower calls don't mean what you want them to mean. Per
the man page:
"If c is neit
If threading is the issue, how do you get meaningful results from
reading and updating
"dying" with no use of atomic types or locks? Other than winning the
implied race, of
course.
M.
On Wed, Jun 21, 2017 at 4:47 PM, Ævar Arnfjörð Bjarmason
wrote:
> Change the recursion limit for the default d
One could have configure ask some existing dependency that has already
determined the byte order. For example:
# perl -e 'use Config; $o=$Config{byteorder}; print(($o=~/^1234/ ?
"little" : ($o=~/4321$/ ? "big" : "weird")), "\n");'
little
Good: less #ifdef soup; bad: not so great for cross-compil
Just swap in md5 in place of sha1. Pad with '0'. That'll give you
all the collisions you want and none of those you don't want.
On Mon, Feb 27, 2017 at 5:43 AM, Jeff King wrote:
> On Mon, Feb 27, 2017 at 10:57:37AM +0100, Geert Uytterhoeven wrote:
>
>> > Yeah, that is a lot more flexible for ex
The attack seems to generate two 64-bytes blocks, one quarter of which
is repeated data. (Table-1 in the paper.)
Assuming the result of that is evenly distributed and that bytes are
independent, we can estimate the chances that the result is NUL-free
as (255/256)^192 = 47% and the probability tha
Is there a point to including a different checksum inside
a git tag? If someone can break the SHA-1 checksum
in the repository then the recorded SHA-256 checksum can
be changed. In other words, wouldn't you be just as well
off handing someone a SHA-1 commit id?
If you can guard the SHA-256 with
>> Is there a reason why picking among the choices in a sliding window
>> must be contents neutral?
>
> Sorry, you might be getting at something interesting but I do not
> understand the question. I have no idea what you mean by "contents
> neutral".
I was merely asking if an algorithm to pick be
> So I think with s/Regularly/About half the time/, your observation
> above is correct.
>
> I think the reason you perceived this as "Regularly" is that you do
> not notice nor appreciate it when things go right (half the time),
> but you tend to notice and remember only when a wrong side happened
> I have verified that successful close() after failed mmap() won't reset
> the output of perror() to "Success".
Does $standard guarantee that?
In general, successful libc calls can set errno to whatever they
please, except zero. And they sometimes do. This follows from
C99.
Morten
-
To unsubs
On 4/20/05, Martin Uecker <[EMAIL PROTECTED]> wrote:
> The storage method of the database of a collection of
> files in the underlying file system. Because of the
> random nature of the hashes this leads to a horrible
> amount of seeking for all operations which walk the
> logical structure of som
There's one more mode bit we might actually care about: the symlink bit.
(One would store the target as the blob, presumably, but chmod isn't going
to create symlinks out of regular files.)
Morten
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL P
> Does it really make sense to store full permissions in the trees? I think
> that remembering the x-bit should be good enough for almost all purposes
> and the other permissions should be left to the local environment.
It makes some sense in principle, but without storing what they mean
(i.e., gr
This write will failing sooner or later when someone's disk fills up.
That'll leave someone with
a truncated file.
Signed-off-by: Morten Welinder <[EMAIL PROTECTED]>
--- read-cache.c
+++ read-cache.c2005-04-15 20:32:52.87168 -0400
@
14 matches
Mail list logo
