「Zuneとgigabeatが閏年の処理の問題でフリーズ」記事へのコメント

原因はクロックドライバ

[Anonymous Coward]

Freescaleの参照ドライバがバグっていた模様です。
閏年の判断が間違ってたわけじゃなくて、1980年1月1日からの日数を閏年を考慮して年初からの日数に直すところで無限ループに入っていたという…
http://www.zuneboards.com/forums/zune-news/38143-cause-zune-30-leapyea... [zuneboards.com]

Re:

[Anonymous Coward]

素直に書けば、これだけのこと？

year = ORIGINYEAR; /* = 1980 */
 
while (days > (IsLeapYear(year) ? 366 : 365))
{
  days -= IsLeapYear(year) ? 366 : 365;
  year += 1;
}

Re:

[Anonymous Coward]

教科書的に書けばこんな感じ。

year = ORIGINYEAR; /* = 1980 */
year_days = IsLeapYear(year) ? 366 : 365;
while (days > year_days)
{
    days -= year_days;
    year += 1;
    year_days = IsLeapYear(year) ? 366 : 365;
}

Re:

[Anonymous Coward]

両方とも、「IsLeapYear(year) ? 366 : 365;」が複数箇所に記述されてるのは駄目だろう。
この程度なら余裕で見通せるだろうが、基本的に同一の記述が複数にあると潜在バグの元になる。
過去の遺産的なつぎはぎ修正のプログラムは、たいていこんなものが散見されて、コピペミスと思われるバグがあったりするよ。

Re:原因はクロックドライバ

[Anonymous Coward]

つまり、実用的に書くとこんな感じ?

year = ORIGINYEAR; /* = 1980 */
while (1)
{
    if (IsLeapYear(year))
    {
        if (days <= 366) break;
        days -= 366;
    }
    else
    {
        if (days <= 365) break;
        days -= 365;
    }
    year += 1;
}

Re:

[Anonymous Coward]

この場合はforで書いたほうが読みやすいよ。

for (year = ORIGINYEAR; ; year++)
{
    if (IsLeapYear(year))
    {
        if (days <= 366) break;
        days -= 366;
    }
    else
    {
        if (days <= 365) break;
        days -= 365;
    }
}

Re:原因はクロックドライバ

[Anonymous Coward]

これ、実用的なの？ifの中身を同じアルゴリズムにするのと、ローカル変数を一つ増やすのとの差でしょ？

for (year = ORIGINYEAR;; year++) {
  year_days = IsLeapYear(year)? 366 : 365;
  if (days <= year_days)
    break;
  days -= year_days;
}

おそらく、組み込み系にとっての、という意味だと思うが…。

Re:

[Anonymous Coward]

実用性云々じゃなくて、

        year_days = IsLeapYear(year) ? 366 : 365;

をうっかり、

        year_days = IsLeapYear(year) ? 365 : 366;

と、しちゃったりとか、そういうトラブルを未然に防げる、って事だと思う。

Re:

[Anonymous Coward]

for文もwhile文も使わない経過日数の計算アルゴリズム [ufcpp.net]もありますね。
ドキュメンテーションをしっかりしておく必要はありますが。。

Re:

[Anonymous Coward]

どうしてif文で書くと365と366を書き間違えるトラブルを未然に防げるの？

Re:原因はクロックドライバ

[Anonymous Coward]

三項演算子を知らないプログラマがいるからです。
保守性を考えた場合、底辺に合わせるしかありません。

Re:原因はクロックドライバ

[Anonymous Coward]

三項演算子も知らないプログラマに保守できるように書いちゃったら自分がクビを切られちゃうじゃないですか!
管理側の発想としてはとてもよく理解できますけど。

Re:

[Anonymous Coward]

いや、三項演算の":"に問題がある(?)っていう話なら、ifを使ってこう書き換えてもいいはず。

for (year = ORIGINYEAR;; year++) {
  if (IsLeapYear(year))
    year_days = 366;
  else
    year_days = 365;
 
  if (days <= year_days)
    break;
  days -= year_days;
}

Re:

[Anonymous Coward]

days=`date +%j`

ってのはドライバということだとだめなんでしょうけど、
なぜに1980年からの通算日数から年内日数なのでしょう？　RTCにはBCDで
月日が格納されるのがほとんどだと思うのですが。

epochが1980年？とググったらarcプロセッサのシステムで
採用しているみたいですね。

Re:

[Anonymous Coward]

ソフトウェアで年月日に変換すればいいのだから、クロックは単なる2進カウンタで実装したほうが、回路のコストが浮きますよ。
微々たるものですが、ソフトウェアで十分なものをハードウェアでやるのは、どーかと思います。

Re:原因はクロックドライバ

[monaka (4489)]

MISRA-Cだと，三項演算子の使用もif-elseでのカッコの省略も，ルール逸脱ってことで文書を上納しなければならなかったりしたような．面倒．

// 個人的にはコーディングスタンダード嫌いなID

--
from もなか

Re:

[Anonymous Coward]

ちょっとカメだがひとこと。

> をうっかり、

バカをいいなさんな。 こういう奴がいるから

if (is_xxx) {
/* Nothing to do */
} else {
/* Procedure to do */
}

とかいうわけのわからない書式が規約になったりする。勘弁してくれ。

組み込みチップではローカル変数は貴重である上にアクセスすると使うとペナルティがでかかったりするのだよ。
数多くのレジスタと大量のスタックと高速のメモリが当然だと考えないでくれたまへ。