2017/10/21

[c/c++]URIスキームはラベル扱いになってしまう

お仕事でプログラムを作っている。
まだテスト段階なので仮実装が多く、忘れないように#warningなどで目印にしている。


だから、ビルドするとwarningはたくさん出てしまうのだが、エラーは出ないようにしている。
しかし、ソースを見直しているとこんな行が出てきた。

xxx {
   ...
   for (...) {
      ...
  }http://www.yahoo.co.jp/
}

参照したURLをコメントに書こうとしたのだろうが、間違えてソース中にそのまま貼り付けてしまったようなのだ。

にもかかわらず、エラーになっていない。
なんでだ?


単純なソースファイルにしてみる。

int main(void)
{
    http://www.yahoo.co.jp/
    printf("Hello, World!\n");
    return 0;
}

エラーにならないし、ちゃんと動く。


-Wallをつけてようやく分かったのだが、これは「http」というラベル扱いになったのだ。
こう書くと、printfは実行されずに終了する。

int main(void)
{
    goto http;
    printf("Hello, World!\n");

http://www.yahoo.co.jp/
    return 0;
}


何か使い道はないかと考えたが・・・ないな。
「なんか間違ってるよ」と思われるのがオチなので、やめておこう。

2017/10/19

[git]forkして作業するか、forkせずに作業するか (1)

githubでソース管理することを考えている。
まだ一人なので何とでもなっているのだが、そのせいでチーム開発向けのルールが考えついていないのを、なんとかしようとしているのだ。


いつもは、なるべく作業前にブランチを作って、そこで作業して、終わったらpull requestしてマージしてもらう、というやり方にしている(一人しかいないので、自作自演なんだけどね)。


まず、各作業をする人が同じリポジトリを使った方が良いのか、リポジトリを各人で作ってforkした方が良いのか、というので悩んでいる。

最初は同じリポジトリで試して、今は別アカウントでforkしている。
前者が使えるのは、リポジトリへのアクセス権をもらった場合(organizationに追加してもらうなど)だけのようだから、混ぜてやるなら後者しかないか。

前者の利点は、forkしていないから、git pullなどとすれば最新版がmergeできるというところか。
後者だと、相手のリポジトリにmergeしてもらったあと、fork先からのmergeという手段になってしまうと思うのだ。
GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita

今はそれでやっているのだが、けっこうfork先からのmergeを忘れてしまう。。
私が悪いと言えばそれまでなのだが、なまじどちらにも同じ権限を持っているだけに、どっちのリポジトリにマージしたのか忘れてしまうこともあった。

そのちょっと前までは、forkしたリポジトリでブランチを作って、fork先にpull requestしてmergeして、fork先からfork元にpull requestする、という2段階でやっていたのだが、さすがに面倒だったのでやめた。
githubでも、pull requestすると、最初にfork元が候補に出てくるから、直接やる方を推奨しているんじゃないかと思っている。


書いていて気付いたが、組織内であればforkさせる理由はあまりないか。
間違ってmainlineを直接編集してしまうという心配はあるのだが、それを避けたければREAD権限にして...forkしてpull request出すのが安全なのか?
branchにprotectをかけるということができるようだから、mainlineだけ保護してしまえばよいのかな?


しばらく、protectして使ってみて、また考えよう。

2017/10/18

[win]SysinternalsのStrings.exeと他のstringsで結果が違うがわからん

WindowsでSlackアプリを使っている。
未読があると、タスクトレイアイコンに赤か青のドットが表示されるのだが、見逃さないように通知領域に出している。

image

Slackアプリは更新が多く、困ったことに更新されると通知領域に表示させる設定がOFFに戻ってしまうのだ。
デスクトップ版もUWP版も変わらないので、OS側なのかな?


私の心が狭いのか、このOFFに戻ったときがどうにも腹立たしい。
「設定アプリ>個人用設定>タスクバー>タスクバーに表示するアイコンを選択してください」と、たどるのが深いのが、また腹立たしさをいや増す。

タスクバーの設定画面までは通知領域のコンテキストメニュー表示から飛べるのだが、最後の画面にたどりつくには、そこからリンクをクリックせんといかん。
設定画面への直接のURIはいくつかあるのだが、この画面に対しては存在しないようだった。


というのが、前置き。

調べていると、この記事が見つかった。

山市良のうぃんどうず日記(102):Windows 10 Fall Creators Updateで増える「設定」は「ms-settings:URI」で狙い撃ち (2/2) - @IT

この人は、DLLからURIを探し出して、Microsoftのページに書いていない画面も探すことに成功している。
私も同じことをしてみようと、フォルダまで飛んで、cygwinを立ち上げてstringsで文字列を出し、grepでフィルタ挿せた。
が、"ms-settings"が1つも出てこない・・・。

記事の時期のせいかもしれんと思ったが、2017年7月なので、それはなさそうだ。
念のため、Bash on Windows on Ubuntuでもやってみたが、結果は同じ。
むう。

最後に、書いてあるとおりにSysinternalsのStrings.exeでもやってみることにした。
こっちは、出てくる。
結果が全然違うのだ。
なんでー!


あり得るとしたら、Windowsだから2byteのUnicodeを使っていて、Sysinternalsはそれに対応しているから・・・か?
理由はよくわからんものの、Windowsアプリの文字列を取ってくるときにはSysinternalsの方を使うのが無難だということはわかった。

2017/10/17

トラックボールを使ってみる

技術ネタではないのだが、今回はトラックボールに持ち替えて1日目になるので、感想を書いておく。


歳を取ってきて、マウスによる腱鞘炎に悩むことも多くなった。。。
私の場合は、右人差し指の第2関節か、右親指の第2関節がよくやられる。

親指の方はよく理由が分からないのだが、人差し指はホイールを動かす量が多い場合だということがわかっている。
デバッグしていて、ひたすらログを上下に眺める状況が数日続くと、もう危ない。

ロジクールの、ホイールがするする回転するマウスを使うようになって軽減したのだが、限界はある。
中指で代用することもあるのだが、使い勝手が悪い。


マウス以外の選択肢となると、トラックボールかペンタブか。
ペンタブは用途に合わないので、トラックボールか・・・と思ったが、踏ん切りが付かない。

そういうとき、飲み会でトラックボールに変えた人がいたので、思い切ってやってみたというわけだ。


買ったのは、ケンジントンのトラックボール。
ネットで買うともっと安いのだが、ヨドバシでは5,100円だった。

image

前方後円墳みたいな見栄えになっているが、下の方は付属品のパームレストだ。
付けた方がよいのかどうかは、まだ悩んでいるところである。

ボタンは2つしかないが、アプリによって同時押しもカスタマイズできる。
私は中央ボタンに割り当てた。
ブラウザでは「戻る」が使えると便利なのだが・・・と思ったら、アプリ単位での割り当てもできた。

ホイールは、ボタンの周りをくるくる回すことになる。
私は親指と薬指で回している。
これのおかげで、スクロールはかなり楽になった。

ホイールのチルトによる水平スクロールはないし、カスタマイズするアプリにもないのだが、他のアプリでShiftキーを押したままホイール回転させることで代用できるものがあるらしい。
今のところ必要に駆られていないので、そういうときはマウスを使うことにしよう。


肝心の使い勝手だが、まだ思った位置にカーソルを動かすことはできないものの、素早い移動はしやすい。
一番難しいのは、ドラッグだ。
まあ、これもやっていれば慣れるんじゃなかろうか。

期待した方向に動かすことができないというのが、慣れの問題なのか、そうでないのか。。。
上下に動かしているつもりでも、ボールを動かす量が多いとぶれてしまうのだ。
ブラウザのマウスゼスチャーなんかは、あんまりうまくできていない。


このままトラックボールでいくか、マウスに戻るのかはわからないけど、もうしばらく使っていてもよいと思った。
とにかくよいのは、指の関節をあまり使わなくて済むところだ。
うまくいけば腱鞘炎対策になりそうだし、そうでなくても腱鞘炎になったらマウスからトラックボールにする、という選択肢が増える。

2017/10/14

[c/c++]16bit→32bitへの拡張は行われるが、32bit→64bitへの拡張は自動で行われない

ミスった・・・。

Windows 10 64bit(Bash on Ubuntu on Windows)
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)

#include <stdio.h>
#include <stdint.h>

int main(void)
{
    int32_t  a = -1;
    uint32_t b =  1;
    if (a < b) {
        printf("OK\n");
    } else {
        printf("NG\n");
    }
}


私は、符号違いのために64bitまで自動で拡張されてOKルートを通ると考えていたのだ。
たぶん、過去にも同じような記事を書いていたと思うが、そうではなくNGルートを通った。
変数が32bitではなく、16bitであればOKルートを通る。


『Cクイックリファレンス』のp.48に、同じような例が書かれていた。
まず、-1の方がuint32_tに変換されるのだ。
もちろん、明示的にint64_tに変換すればOKルートを通るのだ。


符号の有無が異なるところは、明示的にキャストした方が無難だな。
昔はコンパイラでwarningが出ていたような気がするけど、-Wallしても出ないんだよなぁ。
-Wだけの方がよいかもしれん。