cremno

They can be found here: https://support.google.com/groups/answer/6003482

There also some tools I think should be added: I'm not sure if linking to AddressSanitizer is okay (as its (an underused) part of Clang and GCC), but I consider include-what-you-use, unifdef, and maybe C++ Compiler Explorer a worthwhile addition.

What about mbedTLS (formerly PolarSSL)? It's dual licensed though.

https://code.google.com/p/address-sanitizer/(Apache 2.0)

https://code.google.com/p/include-what-you-use/ (same license as LLVM/Clang)

http://dotat.at/prog/unifdef/ (BSD)

http://gcc.godbolt.org/ (BSD)

https://tls.mbed.org/ (GPLv2)

Edit: midipix is something one should look out for. What it promises to support and how, sounds much more appealing to me than Cygwin or MinGW-w64, but it's still in early development: http://midipix.org/

It's a bit off-topic, but is there a reason to still use the original MinGW and not MinGW-w64? The list only mentions the original one.

I also didn't know that GNU refers to the MIT license as Expat license.

The list also links to several PDF versions of books that are still sold and also not published under a free license. Just mentioning them should be fine. We all know how to use an online search engine if we want to get a copy, don't we?

The full sentence is:

>MRI executes Ruby via an interpreted stack-machine bytecode language known as YARV (Yet Another Ruby VM) bytecode.

So YARV is a Ruby VM that has instructions and bytecode. Are you still confused?

The commit that fixes CVE-2015-0291: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h...

Just the slides do. Maybe he later thought the same and then omitted or replaced that suggestion in his talk.

https://www.youtube.com/watch?v=csyL9EC0S0c&t=393

>server_socket_getport

I found this interesting article: http://daniel.haxx.se/blog/2014/10/25/pretending-port-zero-i...

So since 0 can be okay and (in_port_t)-1 (=65535) is okay, it has to be changed to return int and take a in_port_t* to be acceptable for you. The return value may not even matter if only AF_INET/AF_INET6 as family is possible - a comment could be of help here.

>using both 0 and -1 to indicate error returns from functions

I couldn't find any function that returns 0 on failure. Or do you mean a null pointer?

>The stack should not be used to allocate buffers intended to hold data written by other routines for reasons that have become painfully clear over the last couple of years.

You want to see a zero tolerance policy for them? I think this is a bit overprotective. Their maximum size is usually known and all called functions take a size argument (snprintf(), strftime(), strlcpy(), etc.). There's a chance one could make a mistake here, but C is the wrong language to dynamically allocate everything. The probability to forget to free it, including in every error path, is much higher in my eyes. But then again, a memory leak is probably preferable than a buffer overflow (of course, both are bad). There are also already many heap allocated buffers.

>Looking a bit longer at the server_log code I think there may be a path to get a double free of 'ptr' where it is used first in the block with the while loop, then not reset to NULL and re-used in the second block and freed if it is not NULL (which it still is from the previous block...)

I don't think so, but that code really is dodgy. Also, `ptr != NULL` is unnecessary (just mentioning since OpenBSD/LibreSSL developers like to mention that too).

Can you link to specific examples? I'm currently not taking your word for it. The file has comments. Maybe too few and too terse for you, but that isn't what you've said. Yes, some buffers are stack-allocated, but what's wrong with that? No unsafe functions are used to write to them. Discussing style, unless it's really terrible which is also not the case and moreover it is well documented (as OpenBSD KNF), is a waste of time.

Disliking omitting braces or really short names is just a matter of taste (however both is classic C coding style), but you can easily find out what they store without comments or a longer name. I personally would have chosen l instead of x, which is a pointer to a character in the current read _l_ine (see L202).

Can you tell me what comments you're expecting? qmail comes with a bunch of man pages (including ones for functions and they're well written). The file is called qmail-pw2u.c and there's qmail-pw2u(8). The function is called dosubuser, so let's look up subuser in it:

> Extra addresses. Each line has the form

> sub:user:pre:

That gives us a pretty good idea about the purpose of the posted code (plus the previous lines).

I agree, a function or macro makes sense (since there are many other equivalent constructs in the same file), but that's "just" giving a bunch of statement a name. Does field_next explain what they do?

   static int field_next(int *i, char **x, unsigned *xlen) {
       *++i; *x += *i; *xlen -= *i; *i = byte_chr(*x,*xlen,':');
       return i == xlen;
   }
   / * later */
   if (field_next(&i, &x, &xlen)) return;

The rest of the function is writing something. Maybe we should find out the purpose of the program at first? The man page tells us this too:

>qmail-pw2u reads a V7-format passwd file from standard input and prints a qmail-users-format assignment file.

What are your issues with it? That the variable names are not descriptive enough to be understood when the code is taken out of context? That the if-substatements aren't compound statements? The last line? What would you have done instead (back then)? Every statement on a new line makes it more difficult to understand it since it belongs together, a macro obscures the code and also has to be named, and a function only for this is (was) too expensive speed and memory wise.

Dropbox doesn't read the file content. There is also no proof that Dropbox directly accesses those files.

The changelog? Perhaps the _two_ listed fixed issues (ffi build failure, Symbol GC memory leak) were just the most important ones according to the maintainer.

I don't know. I'm actually more interested in what it receives/sends.

Yes, free(NULL) is a questionable statement. The source code comment (not the analyzer) just irritated me.

The malloc(3C) man pages since 5.5.1 claim otherwise.

>So do implement it then to avoid the compilation and/or linking errors, but make it crash intentionally if called.

    void SimpleReferenceObject::operator delete[](void * /* pPtr */)
    {
      free(NULL);
    }

What will cause the crash? Passing a null pointer to free() is fine. Something specific to C++?

It's legal C99. See DR258 / C99+TC3. But be careful, reading trap representations is UB.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

I recommend checking out Corkami's articles/posters:

https://code.google.com/p/corkami/wiki/PE

https://code.google.com/p/corkami/wiki/PE101

https://code.google.com/p/corkami/wiki/PE102

It also has a section about the minimal size: https://code.google.com/p/corkami/wiki/PE#minimal_sizes

Modern Windows versions refuse to run the 97 b and 133 b files from the linked article.

Linux actually has/had flowery names: https://en.wikipedia.org/wiki/List_of_Linux_kernel_names

The commit message contains some numbers:

https://github.com/golang/go/commit/6c7cbf086c34ebb88311ba12...

Well, that status page links to http://www.w3.org/community/ortc/, so I don't think they mean CU-RTC-WEB.

https://status.modern.ie says WebRTC is in development and CSS 3D transforms are part of a IE preview release.

Oh, I am the one that has to be sorry! I didn't check the URL, even though I am aware of that issue with cgit (no line highlighting).

Yeah, using alloca() (in any form, incl. VLA) isn't good style. At least it's bounded, since filename_is_valid() checks the length. But it uses FILENAME_MAX, which could be too large for the stack.

I don't like the usage of that attribute either (but if that's their strategy, fine by me.), but I still don't see where the obvious memory leaks are. Your first link links to a line with a strdup() call, but the corresponding free() can be found in L168.

Where are the _obvious_ memory leaks?

They're still part of C++14. You have to wait for C++1z (or use a compiler switch).

What about normalization, which by the way, isn't actually NFD — it's just very similar to it?