2008 高扣抵稅率概念股

經濟日報: 18檔高節稅概念股評析 (2008-05-05)

進一步觀察這些個股的可扣抵稅率,以儒鴻(1476)36.21%最高,中鋼構(2013)35.17%、中鴻(2014)33.38%,另外,全國電(6281)、三星科技(5007)、宣昶(3315)等,可扣抵稅率都超過三成。以中鋼構為例,今年配發的現金股息為1.2元,換言之,若持有一張中鋼構參與今年的除權息,投資人將可獲得1,200元的現金股息,而其可扣抵稅率為35.17%,屆時可扣抵稅額即為422元。

法人指出,股東在申報個人綜合所得稅時,「股東可扣抵稅額」取決於「發放股利」與「稅額扣抵比率」,只要「稅額扣抵比率」高於「個人綜合所得稅率」(區分為免稅、6%、13%、21%、30%與40%),股東參與除權息,不僅可享受到股利或股息報酬,亦可額外獲得抵減稅額,可謂一魚雙吃。

一個長整數各自表述 (in 64-bit system)

Size of long integer may be different between 64-bit systems (一個長整數各自表述)

不知道是不是我太落伍了…

我一直以為 C/C++ 下面 short, long, long long 三種資料型態都固定是 2, 4, 8 個 bytes 大小。只有 int 這個資料型態會因為 16-bit/32-bit 系統的不同而變成 2 或 4 bytes 的大小,所以理所當然 int 在 64-bit 的電腦也應該會變成 8 bytes (64-bit) 的大小囉 ?!

在整理前一篇文章《Bypass the 2GB file size limit on 32-bit Linux》的時候,讓我驚覺在 64-bit 的系統下,long 的長度也是各自表述的!

首先,int 的大小即使到了 64-bit 的機器上,大部分的系統仍然使用 4 bytes 的大小而已,這主要是為了避免程式從 32-bit 系統轉換到 64-bit 系統需要修改太多地方

再來,請參考 Wikipedia: 64-bit data models 的說明

絕大多數的 UNIX 系統在 64-bit 下面採用 LP64 這種 data model,這時候 long 就不再是固定為 4 bytes 大小,而是變成 8 bytes 的大小了!

然而,Win64 卻不是使用 LP64,而是採用 LLP64 這個 data model,這時候 long 的大小仍然還是 4 bytes

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers). Microsoft’s VC++ compiler uses the LLP64 model.

兩種 data model 的最大差異點就是 long 這個資料型態的大小,LP64 是 64-bit,而 LLP64 則是 32-bit

LLP64 data model 基本上可以說跟 32-bit 的系統一樣,唯一差別只有位址(pointer)改成了 64-bit 而已。資料物件(class, structure) 等如果沒有包含 pointer 的成員的話,整個物件的大小是與 32-bit 系統一樣的!

而 LP64 則是除了位址(pointer)改成 64-bit 之外,long 的大小也變成了 64-bit 大小。所以在 UNIX 下面,要把 32-bit 程式 porting 到 64-bit 可能要比 Windows 多花費多一點功夫。

所以呢,我們觀察到兩個問題影響著程式的相容性

  1. 在 UNIX 下面,long 的大小在 32-bit 與 64-bit 的系統下是不一樣的
  2. 同樣是 64-bit 系統,UNIX 與 Windows 對於 long 的大小看法是不一致的

為了使程式在 32-bit 與 64-bit 之間以及 UNIX 與 Windows 之間的相容性提昇,改用固定長度的資料型態是寫程式的一個好習慣

在 UNIX 下面,我們可以改用 stdint.h 這個 header file 中對於資料型態的定義:

int8_t     8-bit signed interger
int16_t    16-bit signed interger
int32_t    32-bit signed interger
int64_t    64-bit signed interger
uint8_t    8-bit unsigned interger
uint16_t   16-bit unsigned interger
uint32_t   32-bit unsigned interger
uint64_t   64-bit unsigned interger

在 Windows 下面,則改用下面這些整數固定大小的資料型態

INT8       8-bit signed integer
INT16      16-bit signed integer
INT32      32-bit signed integer
INT64      64-bit signed integer
UINT8      8-bit unsigned integer
UINT16     16-bit unsigned integer
UINT32     32-bit unsigned integer
UINT64     64-bit unsigned integer

絕對不要再使用 int 和 long 了!

尤其是寫網路程式時,很可能 client 是 Windows 而 server 是 UNIX,然後又有 32-bit 及 64-bit 系統混在裡面,一不小心就發生不相容的問題了…

當然,在 64-bit 的系統下寫程式,要考慮的絕對不只上面這些基本的資料型態。除了 pointer 的大小變成 64-bit 外,許多系統內建函式會用到的 size_t 及 off_t 的大小也變成 64-bit 了…. 寫程式時若有用到這些資料型態,需特別注意,尤其是 casting 時,千萬不要用 32-bit 的整數去裝這些資料,免得造成不可預期的結果!

最後提供一個小程式讓你得知你的系統主要資料型態的大小

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <stdio.h>
#include <sys types.h="">
int main()
{
        printf("sizeof(short)     = %d\n", sizeof(short));
        printf("sizeof(int)       = %d\n", sizeof(int));
        printf("sizeof(long)      = %d\n", sizeof(long));
        printf("sizeof(long long) = %d\n\n", sizeof(long long));
 
        printf("sizeof(size_t)    = %d\n", sizeof(size_t));
        printf("sizeof(off_t)     = %d\n", sizeof(off_t));
        printf("sizeof(void *)    = %d\n", sizeof(void *));
}
</sys></stdio.h>

參考資料:

  1. Wikipedia: 64-bit data models
  2. 64-Bit Programming Models: Why LP64?
  3. Introduction to Win32/Win64
  4. Porting 32-bit Applications to the Itanium® Architecture
  5. Preparing Code for the IA-64 Architecture (PDF)

Bypass the 2GB file size limit on 32-bit Linux

Bypass the 2GB file size limit on 32-bit Linux (在 Linux 上面突破 2GB 的檔案大小限制)

在 32 位元的 Linux 上面寫超過 2GB 的檔案會發生錯誤,甚至導致程式終止執行

這是因為 Linux 的系統內部處理檔案時用的指標定義為 long,而 long 在 32 位元的系統上的大小為 32 位元,因此最大只能支援 2^31-1 = 2,147,483,647 bytes 等於是 2GB 扣掉 1 byte 的檔案大小

64 位元的系統 (例如 AMD64IA64) 則因為 long 定義成 64 位元,所以不會有問題..

#  if __WORDSIZE == 64
typedef long int int64_t;
# endif

不過在 FreeBSD 上面,即使是 32 位元的系統,也不會有 2GB 檔案大小的限制,這是因為 FreeBSD 內部處理檔案時,本來就是使用 64 位元的數字當作指標,所以不會有問題

因此在 32 位元的 Linux 上面,程式需要作一些額外處理才能正確寫超過 2GB 的檔案

我們先寫一個小程式來測試一下 (large.c)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
void sig_xfsz(int sig)
{
        printf("ERROR: SIGXFSZ (%d) signal received!\n", sig);
}
int main()
{
        int     i, fd;
        char    dummy[4096];
 
        signal( SIGXFSZ, sig_xfsz );
 
        unlink("large.log");
        fd = open("large.log", O_CREAT|O_WRONLY, 0644 );
 
        bzero( dummy, 4096 );
        /* 2GB = 4KB x 524288 */
        for( i = 0 ; i < 524287 ; i++ )
                write( fd, dummy, 4096 );
        write( fd, dummy, 4095 );
        printf("large.log: 2147483647 bytes\n");
 
        if( write( fd, dummy, 1 ) < 0 )
                printf("ERROR: %s [errno:%d]\n",strerror(errno),errno);
        else
                printf("large.log: 2147483648 bytes\n");
 
        close(fd);
        exit(0);
}

在 32 位元的 Linux 下面,以上程式編譯後若沒有特殊處理,執行結果如下:

# gcc -o large32 large.c
# ./large32
large.log: 2147483647 bytes
ERROR: SIGXFSZ (25) signal received!
ERROR: File too large [errno:27]

在寫第 2147483648 byte 的時候,程式會收到 signal SIGXFSZ,同時 write() 會回傳 -1 錯誤,errno 則為 27 (File too large)。更甚者,如果程式沒有像上面一樣去處理 SIGXFSZ 的話,內定的 signal handler 甚至會造成程式停止執行並產生 core dump

接下來,我們在編譯同一個程式的時候加入 -D_FILE_OFFSET_BITS=64 再試看看:

# gcc -D_FILE_OFFSET_BITS=64 -o large64 large.c
# ./large64
large.log: 2147483647 bytes
large.log: 2147483648 bytes

果然順利突破 2GB 的限制了!

而同樣的程式在 32 位元的 FreeBSD 下面,不論有沒有加這個定義,跑起來都是正確的

不過處理這些大檔案的時候,除了編譯程式時的參數不同外,有些函數的使用上也要作一些調整,例如 fseek() 與 ftell() 這兩個原本使用到 long integer 當作 offset 的函數:

1
2
int fseek(FILE *stream, long offset, int whence);
long ftell(FILE *stream);

只要系統是 32 位元,即使是在 FreeBSD 下面,都需要改為使用 off_t 的版本:

1
2
int fseeko(FILE *stream, off_t offset, int whence);
off_t ftello(FILE *stream);

在 Linux 下面,如果 _FILE_OFFSET_BITS 定義為 64,則 off_t 這個型態會自動轉成 64 位元的大小(在 FreeBSD 上面,off_t 本來就是 64 位元的大小)

每種系統支援大於 2GB 的檔案讀寫所需要的編譯選項都會有一些差異,即使是同樣是 Linux 也會因為 32 位元或 64 位元而有不同。有一個簡單的方法可以判斷,就是利用 glibc 提供的 getconf 來取得編譯(compile)以及連結(linking)時所需的參數:

# getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
# getconf LFS_LDFLAGS 
 
#

上面是在 32 位元的 Redhat Linux 上面跑出來的結果,代表的是在這個系統上,若要讓程式支援 2GB 的檔案讀寫,編譯(compile)時需要加上 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 這兩個參數,連結(linking)時則不用加任何參數

參考資料:

China blocked FeedBurner (problem for FeedSmith)

這次到大陸出差,讓我發現到一個嚴重的問題,就是 Great Firewall (GFW) 把著名的 feed service provider FeedBurner 給擋掉了,這已經是去年八月發生的事了。所以如果您自己以 WordPress 架設的 blog 使用了 FeedBurner FeedSmith 這個 WordPress plugin,就會有一些奇怪的問題發生…

首先是 blog 的 RSS/Atom 等都無法直接被訂閱了,因為 FeedSmith 自動把 RSS/Atom 導向到 FeedBurner 那邊了,所以大陸那邊的人就無法直接訂閱。

例如: 我的 blog 的 feed 是: http://blog.urdada.net/feed/ 就會被 FeedSmith 使用 HTTP Status Code 307 (Temporary Redirect) 重導到 http://feeds.feedburner.com/cdsheen,所以大陸人就看不到啦…

當然,從大陸透過 BloglinesGoogle Reader 可能還是可以間接訂閱就是了…

另外一個問題是,所有 RSS/Atom 內文章的原始連結都會被 FeedSmith 代換成 FeedBurner 的網址來追蹤點擊率,但是這些連結在大陸都沒有任何作用,無法導回原始網站了… 因此即使大陸人可以使用 Bloglines 或 Google Reader 來間接訂閱,但是當要回原網站查看原文時,也會因為 FeedBurner 被擋而無法正確連結!

暫時還想不到比較好的解決方法,有人建議額外使用一個沒被 GFW 擋掉的 feed service provider 來專門給大陸客使用,例如: FeedSky,這是大陸的公司,我想應該不會被擋。不過為了不讓阿共仔的陰謀輕易得逞,我暫時還是維持只使用 FeedBurner,但是另外提供一個 feed 讓苦難的大陸同胞訂閱(雖然這樣就無法追蹤那邊的訂閱狀況了..)

# cp wp-rss.php rss-china.php

如果您人在大陸,想要訂閱我的 blog,請改用下面這個未經 FeedSmith 處理過的 feed 吧:

http://blog.urdada.net/rss-china.php

真是無奈… 大陸對於言論審查的尺度一直跟不上經濟自由化的腳步,總有一天會出問題的

2008 夜上海俱樂部

2008 夜上海俱樂部

沒錯!這是敝公司今年的春酒主題,一進會場就可看到華麗的舞台佈景:

福委會鼓勵大家以「上海風」的主題打扮,同時會頒發三名最佳服裝造型獎,有豐厚的獎金。許多同事還精心去租借禮服打扮,走入會場彷彿回到民國初年的上海灘..



近年來線上遊戲已經是公司主要的業務,所以會場還擺了輪盤、骰子及 Black Jack 三張賭桌讓大家玩一玩.. 通通玩過後可以換得一張刮刮樂彩券

最後是充滿創意的菜單:

節目是還蠻精彩的,開頭還有播放由員工合力自製的爆笑的 MV,會場有樂團的現場演唱,甚至還有請到羅賓老師來表演魔術。唯一遺憾的是,我今年又槓龜了,眼睜睜看著 Sony Bravia 40吋液晶電視、Canon EOS 400DPSP 以及數十萬的現金大獎落入別人的口袋… 賓果遊戲沒有連線,連拿到的兩張刮刮樂彩券都沒刮中… @@

夜上海俱樂部精彩落幕,巧的是下禮拜就要去上海出差,真正體驗現代的上海灘風情了 XD

富邦momo購物網的 Touch Cruise 驚爆價!(標錯價?)

話說一個禮拜前貼的一篇文章才提到說我的手機 Siemens 3618 用了五年多了,一直都還是頭好壯壯的,沒想到今天慘事就發生了…



液晶畫面突然變得亂七八糟,雖然看起來還可以接聽來電,但根本看不出來是誰找我,也無法查詢電話簿,看來真的是該換一隻手機了…

不過這一篇的重點不在這邊…

我從 momo 富邦購物網訂購(疑似標錯價錢)的 HTC Touch Cruise PDA 手機今天又有最新消息了,下午有一位 momo 的客服人員打電話過來,說我訂購的手機缺貨,可能要一陣子才能到貨,問我要不要取消訂單。我當然是嚴詞拒絕囉,要求 momo 必須依照網站上的說明於五個工作天內到貨。而且既然客服人員這樣說明,就表示沒有標錯價錢的問題囉 !?

不過這隻手機雖然熱門,但也不可能達到這麼缺貨的地步,網路上甚至有人說被 momo 客服告知要兩個月才會到貨!其實就算標錯價錢,還是有辦法協商的,購物網站仍不見得要完全履行(可參考之前的聯邦銀行案例)如果富邦想用這招來騙買家取消訂單,未免也太低級了一點… 而且這樣可能適得其反,富邦是不是就等於承認沒有標錯價錢了呢?如果有人不接受取消訂單,那 momo 是不是兩個月內都不用想賣這支手機了呢? 沒貨源還放上網站去賣,momo 以後不想混了嗎?

從 momo 網站的訂單查詢已經可以看到目前我這筆訂單處於「物流作業」狀態:



另外,我使用信用卡分期繳費,也已經在信用卡網站上看到第一期的扣款了



關於 momo 富邦購物網這次出的包,可參考 Mobile01 上的 [相關討論],上面還有人說去年十二月底已經遇過相同的事了,那時主角是 HTC 的手機 TyTN II,富邦反悔推說沒貨,強制取消訂單,只送了一個保溫杯,沒想到現在又來一次,這個網站問題還真大…

[2008/02/21 update] 後來 momo 客服說 23 號才會出貨,目前東西還沒收到,慢慢等囉
[2008/02/23 update] 還是沒有收到貨,客服說 HTC 把貨扣住了,真爛的理由..
[2008/02/25 update] 出發到大陸上海出差,但東西還沒收到
[2008/03/01 update] 晚上回到台灣,大樓警衛說剛好今天到貨了,有圖有真相:

[總結]
2008/02/07 大年初一訂貨,二十三天後(2008/03/01) 收到貨品 (照規定應於五個工作日內到貨),與市價約有五千多元價差,從頭到尾富邦 momo 都沒說這是標錯價錢,看來真的是驚爆價吧 🙄