ソースコードを皆でマッタリ読もう会(初心者歓迎){}

ソースコードをま〜たり解読しながら一杯やりませんか。
ありそでなかったスレッドなんで無謀にも立てちゃいました（笑）
プログラム板に立てようかとも悩みましたが、あえてLinux板にしました。

プログラミング入門者大歓迎。
つーか、はじめに宣言しておきますが、スレ主がヘタレ入門者です（笑）
たぶん挫折すると思いますが、せっかくLinuxを入れてオープンソースを
利用させてもらっているんだから・・・いやま、ちょっとした好奇心で。

で、どれを読むの？

>>1
うせろ

http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/mac.h.html

ソース　コード　2804
http://quote.yahoo.co.jp/q?s=2804.t&d=c&k=c3&h=on&z=m

1の努力が試されるとき。

>>4
なんつーキモいヘッダーファイルだ。

あのbourne shellの悪名高きソースか
気付かなかった

http://lxr.mozilla.org/mozilla/source/xpcom/base/nscore.h
http://lxr.mozilla.org/mozilla/source/xpcom/base/pure_api.c

http://sartak.katron.org/nh/src/monst.c.txt
ローグライク崇め奉ってる連中は↑読んで
さっさとUNIX板のNethackスレから撤退して欲しいよ

>>10
そのコード、C99で書き直すとすっきりする予感。

>>4
その手を使えば簡単に新種のプログラミング言語をつくれたんだww

>>13
お前、センスないな。

>>14
可変幅フォントを採用するようなセンスは欲しくない。正直言って。

struct Hoge {
unsigned x:31;
unsigned y:1;
}
後ろのコロン数字なんだけど、
これどういう意味??

ヒント：足して32

え・・・まさか 32 bit のうち、
x に 31 bit 割り当てて y に 1 bit 割り当ててるってこと??

つ ビットフィールド

>>19
サンクス。理解した。
ビットフィールドって本でチラっとだけ読んだ事あったけど忘れてたよ。

まあ使わんけどね。

struct hoge {
unsigned hilo:4;
unsigned lohi:4;
} val;

val.hilo = 1;

でビット並びが 00010000/00000001/10000000/00001000 のどれなのか
コンパイラ依存では使いにくい（ビットフィールドは並び順規定がなくて
詰め込みの都合で前後入れ替わったりもOKだったはず）。結局自分で
unsigned 8bitなフィールドでビット演算すればいいや、みたいなことになる。

bit-fieldは、PICやAVRのコントロールレジスタを弄る時に重宝してます。

コンパイラ依存だということさえ頭の片隅にあればおk

>>19
できるよ。
以上。
はい次の方。

オープンソースとはいっても意外と誰もソースコードを読んでいる人はいなかったりしてwww

必要もないのに読みふけるような人はあまりいないのでは。
趣味の欄に「ソースコードを読むこと」と書いた人にはあまりお目にかからない。
修正したいこととかがあれば読んで修正して、
それが他人の役にもたちそうならパッチ送ってる。

ねぇねぇ、マジレスだがパッチ送るとかそういうのって具体的にはどうするの?
とあるアプリに機能追加してみたら、人も使うかなって感じになったんだけど
MLにも参加してないし、だいたいOSSのそこらの流儀ってよくわからんのですよ。
英語のコミュニケーションも自信ないしなぁ。

>>27
BTSがあればそこにでもたたき送れば?
なければメンテナのメールアドレスに送る。

英語は Please apply this patch. でええやん。
内容説明はちゃんとしたほうがいいが、最初は簡単。
patchがrejectされると返答に困ったりするが。

>>28
ありがとう。デベロッパの代表メールアドレスのほうに送ってみる。
しかしbugfixでもないし、なかなか緊張するなぁ。

プログラミング文法（C言語&Perl）の基礎を習いたての人が読むのに丁度いい
ソースって何かありますか？

>>30
リナックスカーネル。
良質のコメント、解説が巷に溢れてることがその理由。

>>30
プログラミングテクニック―UNIXコマンドのソースコードにみる実践プログラミング手法
http://www.ascii.co.jp/books/books/detail/4-7561-4389-X.shtml
どうだろ

リナックスカーネルってｗｗｗ難易度高すぎorz

>>32
変な先入観持ってないか？

>>30
> プログラミング文法（C言語&Perl）の基礎を習いたての人は

まずソースを読むより教科書の写経でいいからガリガリ書いた方がいい。
古典だがK&R(プログラミング言語C)とラクダ本(プログラミングperl)は必修。
人のソース読むのはその後でいいよ。

>>33
Linux kernelの参考書(特に日本語のやつ)はほとんど参考にならん。
なので>>30にはきついと思う。

読むなら自分で使っていると思われるGNUツールとかかな。

>>30
ffmpegのソース。あれは見といて損は無い。

>>35
良い洋書はどんなのがある？

>>37
>>35じゃないけど、オライリーのあれは結構読みやすかった。

Understanding the linux kernel

>>36
cmdutil.cだけちょっと眺めたら、hoge_hoge_or_dieとかいう関数がいくつかあって
「これ何てPerl？」と思ったわw

Hoshu Linux

cp mkdir ls rm...
これらのソースコードを見るはどのパッケージを落とせばいいの？

>>42
coreutils

>>43
サンキュー！！！！！！

.c はC言語のソースファイル
.h はそのヘッダファイル
.adと.manは何でしょうか。

>>45
何故ベストを尽くさないのか

勉強や趣味でソース読むならBSDのコマンドが一番いいと思うがな。
見た目もきれいだし、とにかく簡潔で短い。

BSDは、パクリ放題。Appleにもええようにされて
それでも耐えてるドSって感じ。まあ、それと
ソースは関係ないので、読んでもいいんじゃない?

でも一番は自分の興味があったり、使ってたりする
ソースコード。読むんじゃなくて眺める所から始めても
いい。ただし毎日すること。

ソースコードなんてごくごく僅かな人（ごく一部のハッカー）にしか読まれていないよね。

>>49
ハッカーじゃないけど困ったら読むよ。

こんな過疎スレがまだ生き残っていたのかwwww

ボードゲームの考察に使う時間をなくして
再びsource codeの読みふけに参戦する

使ってる環境全て制覇したいけど
まったくはかどらない
集中力が続かないな
印刷して寝ながら見たほうがいいかも

数学と英語の勉強のし直してる
なんか毎日勉強ばっか
それにしても英語ってほんと苦手
英語は日本語の感覚から遠すぎるな
あまりに手応えを感じられないので
息抜きにほかの言語の学習したりしてる

つ TinierMe

>>49
この前はOBPagerをビルドするのにエラー箇所を調べていたり、
さらにその前はpiewmのビルドが通らなくてエラー箇所を調べ...。

ビルドでエラー起きたらエラーメッセージを検索して修正方法を
見つけてとか普通にやってる。Quick Hack程度だけどね。
たまにMakefileなんかも修正するね(autoconf使ってないものとか)。

>>53
内容を理解するだけに限定するのであれば英語は勉強するものではないと思うよ。
同じ文章ばかり読んで検証で触り続ける→自然と読めるようになる。

mozilla（seamonkey）のアドオンであるperapera-kunをインストールしたんだけど、
マウスで単語の上をなぞってもポップアップウィンドウがぜんぜん表示されない。
ソースコードを検索してみたら、どうやらC#で書かれてある。だから動かないわけか？

http://profiles.yahoo.co.jp/-/profile/?sp=oGT3BCg1eqGiCHsyTN79KJdc
Windows

てっきり音読するスレかと……

オープンソースとは言っても作成者以外に誰も読んでいないコードが大半なんでしょ？
でも、誰かが読んでくれているとは思っている。思い込んでいるだけかも。

>59
おまえの(ry
日本だと、そういうのは見えないだけで意外と読まれていると思うよ。
つか、ブログに掲載されているコードなんか毎日読んでいるよな？

たとえばブログ作ってソース書き込んでおけば外出先でも参照できる。
それにHighlightあるからhtml化して読んだら？
ttp://www.andre-simon.de/

読みたいのであればi3とかはお勧めかと思われる。
(コメントやドキュメント丁寧かつ豊富)
ttp://i3.zekjur.net/


読み方はPGやFLOSS関係者でもない限り方法は知られてないのがオチ。
(理解できるかどうかは除いて)ソースコードを読むのは意外と難しいことではないんだけどね。
時間かかるから自分との戦い。

一日で理解できないから一気に読まないとか、誰も教えないしな。

3000行以下のコードってことでQuarkWMのソース読んでいるが...
ケチつけるの大好きなら楽しめるかと(要するに初心者が書きそうなコードで普通にひどい)。
ttp://quarkwm.sourceforge.net/

むしろこういうコードでも普通に動くってのが潔いがな。

どういう点を修正したほうがいいんでしょうか？

>>62
それ(QuarkWM)本気で言っているのか？...！！
こいつは初心者のやってしまうパターンだらけなんだが...

- なにこの腐ったmain()関数は？
- マジックナンバー乱用しすぎ。なに、その11ってのは？
- unsigned intに型定義してIなんかハンガリアン風の命名を普通やらない。
やられると解析やりづらい上に構文強調表示効かなくなる。そんなことするならエディタの補完機能を使う。
- それ以前に命名規約がおかしいし、不必要なマクロ定義がいくつかある。
- includeの使い方が変というか勉強不足。関数とかexternでやるでしょ普通。
- 関数プロトタイプ宣言？なにそれおいしいの？
- 三項演算子の使い方がおかしい。というか三項演算死亡遊戯に酔っている。可読性下げているでしょ。
- カンマの後に半角スペース入れろよ。環境やフォントによっては区別付かないんだぜ。

etc...

ソースコードは書くより読むほうが時間がかかるわけで...。
これのひどさを自覚できないのであれば、まずdwmを読んだほうがいいです。

>>63
foo || dieのようなもの
というのもなかなか素敵。

#includeがuseの代わりだったりして。

良スレ乙。Linuxerにこんなに親切な人がいるとは。永久保存。

オーライリーの 詳解Linuxカーネル を読んだ事ある人、感想お願いします

>>66
OSいじりたい人なら面白い。

>>67
どうもです

今日図書館行って借りてきた
毎日興味ある所から少しずつよんでこ

オライリーの本って内容濃くて面白いんだけど、実際値段表示を見ると萎えるな。。。
中古で買うと割と安いんだが

>>63
フリーのソースにけち付ける場合は、
自分で書き直してから、
「これに差し替えるほうが良い」ってやんわりとけちを付けるのが正解だと思う。

何の生産性も無く、端から見て文句ばっかり言ってる人間ってのはクズだよ。

>>61-64
CodeGolfみたいなノリで、コードサイズまで縮めようとしたのかなこれ…それはそれで中途半端だが

#define or else if

とか最初見たとき自分の#defineについての知識を疑ったｗ
なんだコレは、最近のプリプロセッサには俺の知らない機能があるのか？と