http://gnu.wildebeest.org/blog/mjw/2012/03/16/automagically-merging-changelog-files-with-mercurial-or-git/

GIT

For git add the following lines to your ~/.gitconfig

[merge "merge-changelog"]
name = GNU-style ChangeLog merge driver
driver = /usr/local/bin/git-merge-changelog %O %A %B

[core]
attributesfile = ~/.gitattributes
And add the following line to ~/.gitattributes

ChangeLog merge=merge-changelog

うーむ、いまどきは project/.git/info/attributes をいじるのは古いのだな。git 1.7.4以降だからCentOS6だと使えないのが玉に瑕だけど。

関連記事

• flymake と戦ってた (2014/07/07)
• git-merge-changelog めも (2013/01/26)
• realloc(ptr, 0)の挙動について (2013/01/04)

please ignore me.

関連記事

• なぜかコメントが承認待ち (2014/02/05)
• test message (2013/01/26)
• はてなのブログパーツはずしました (2012/03/12)

glibcのバージョンってプログラムから簡単に得る方法ないと思ってたけどあったわ。

#include <stdio.h>
#include <gnu/libc-version.h>

int main (void)
{
	puts (gnu_get_libc_version ());
	puts (gnu_get_libc_release ());
	return 0;
}

% ./a.out
2.12
stable

これでバージョン依存のworkaroundいれるのが捗るな

関連記事

• glibcのpthreadにdeadlockバグが有るらしい (2013/02/01)
• gnu_get_libc_version (2013/01/10)
• topのswap表示いつのまにか直ってた (2013/01/10)

３年ほどまえにtopコマンドのswapフィールドが壊れているという記事を書いたんだけど

http://mkosaki.blog46.fc2.com/blog-entry-1115.html


そのときはprocpsパッケージがメンテナ不在状態で、投稿パッチが放置されてしまってた。で、最近見なおしたらprocps自体がprocps-ngという亜流にforkして、メンテナが代わり、

まったく同じパッチが違う人の手によって procps-ng 3.3.3 でマージされてた。変数名まで同じだけどクレジットはなし。むむん

ちょっと追ってみたんだけど、procps-ngのNEWSだと Debian #628462 を参照していて

procps-ng-3.3.3
---------------
* watch -g command repeats until something changes
* Changed labels of kB etc to KiB Debian #662786
* top supports hotplugged memory and cpus Debian #351934, #459287
* top %cpu not distorted when switch to/from threads Debian #441166
* top can read old toprc configuration files Debian #651213, #651863
* top supports input paste once again Debian #663334
* top -p avoids SEGV when pid doesn't exist Debian 668335
* Various DejaGNU test cases fixed
* pgrep.1 graoff syntax fix Debian #665425
* sysctl avoid crash when -p file has unexpected input
* sysctl .conf off-by-one error Debian #669128
* libprocps: protect locale env getting overwrite RedHat #548711

* Documentation catch up (fixed prior to 3.3.3)
. top repeating "%" wastes space Debian #322984
. top -U user name parse error Debian #623200
. top memory leaks Debian #627257
. top impossible task swap statistics Debian #628462
. top forest view segfault Debian #650864

そっちでは、Fedoraで同じ障害あって独自パッチでもう直ってるよー、みたいな話があって

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628462

で、Fedoraのほうを見ると自分で直したかのように書いてあるけど、

https://bugzilla.redhat.com/show_bug.cgi?id=532668


RPMをみると、
http://lists.fedoraproject.org/pipermail/scm-commits/2011-June/609617.html

%changelog
+* Wed Jun 01 2011 Jan Görig 3.2.8-20.20110302git
+- fix #532668 - procps/top SWAP statistics makes no sense (adapted patch from Mr. Kosaki)

などと、しれっと書いてあるな。

まあ、パッチ取り込むのに反対はあるはずないんだけど、本人に連絡よこせという話である。


追記： procps-ngを亜流と書いてしまったけど、全ディストロがprocps-ngに移行してしまった今となってはこっちが本流だな

関連記事

• gnu_get_libc_version (2013/01/10)
• topのswap表示いつのまにか直ってた (2013/01/10)
• ssh の ProxyCommand none (2012/08/07)

Rubyのxrealloc()の実装見たら、常に glibcと同じ挙動になるように引数チェック＆加工してあった。ふーん

関連記事

• Rubyvis (2013/05/13)
• さっきの realloc(ptr, 0)のはなし (2013/01/04)
• ruby 2.0 の dtrace featureを systemtap から使う方法 (2012/12/30)

glibcでrealloc(ptr, 0)とわたしたときに、mtraceのログがおかしいというバグがあってその議論が面白かったのでご紹介。
http://sourceware.org/bugzilla/show_bug.cgi?id=14981

reallocという関数がある。まあ、みなさんよくご存知のように realloc(ptr, size)とわたしたときにptrをsizeの大きさに拡張（縮小）してくれる関数である。

malloc(0)がNULLを返しても非NULLを返してもいいように、realloc(ptr, 0)も挙動に実装の自由度がある

１．realloc(ptr, 1) と同等（mallocが非NULLを返すケースではこれが普通）
２．ptrは解放され、NULLが返る（mallocがNULLを返すケースでは常識的な挙動）
３．ptrは解放されず、NULLが返る（mallocがNULLを返すケースでは同じくらい常識的な挙動、malloc(0)をエラーとみなす哲学だと関数の最初に引数チェックをするのは理解できる）

The Austin Group Defect Report #400
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm

によると、AIXとglibcが２、BSD系が３のようである。ところでPOSIXはテキストの書き方がわるくて３しか認めないような文章になってるから規格を直さないといけないんじゃないかな。という議論をしている

で、glibcに戻るとglibc 2.17までの挙動は

・malloc(0)は非NULLを返す（環境によるけど malloc(16)と同じになると思う）
・しかしなぜか realloc(ptr, 0) は free(ptr) と同じ挙動をし、NULLを返す（０サイズのメモリをアロケートしてはくれない）
・そしてmtraceのrealloc hookではrealloc(ptr, 0) で 非NULL が返ってくることを期待していてNULLは全部エラーとして扱っている

という不整合があり、正しくログがとれていなかった。

で、いつものようにみんなで規格書パース合戦を繰り広げた後、Roland McGrath が仲裁にはいって、ログと実際の挙動が違っているのは明らかにバグだから2.18ではmtraceを変える。realloc(ptr, 0)の挙動を変えるかどうかは規格解釈をglibc MLで議論するのがそもそも間違っていて、Austinで議論してから、必要なら変える。このコーナーケース
について変えてはいけないとは思わないが、規格に対する推測をもとに変更はしない。という結論になった。

まあ、順当なところかな。malloc(0)とrealloc(ptr, 0)の挙動が一貫してないのは気持ち悪いけど。

関連記事

• git-merge-changelog めも (2013/01/26)
• realloc(ptr, 0)の挙動について (2013/01/04)
• [togetter] The behavior of NetBSD's setenv(3) (2012/08/07)