关于文件的读写

rickxbx

you can modify that kind of thing

littlepig

Post by rickxbx
in glibc

btw: if you want to read the code, you may download glibc source

老大误人子弟了，read/write是system call，当然在内核代码里了。
标准I/O库才是glibc的一部分。

rickxbx

Post by littlepig
老大误人子弟了，read/write是system call，当然在内核代码里了。
标准I/O库才是glibc的一部分。

请问 littlepid 兄， 你有没有在应用程序里面用过 read/write 这样的系统调用？ 如果用过，你还能说“当然在内核代码里了”吗？如果没有用过，那么先用一下再发表您的高见。 应用程序开发者眼中的“系统调用”和内核开发者眼中的“系统调用”是不一样的概念。 既然帖子发在了这里，我自然第一感觉就是从应用程序员的角度去思考，从楼主的第二个帖子才能看出一点楼主的真正意图，而我为了确认楼主确实是在讲内核，问了一句：

where did you find such a function pointer declaration?

不知道littlepid兄是否明白我在说什么

littlepig

哦，七年前开始写UNIX应用程序，今天有人问我有没有用过read/write，感觉有点怪。
我的意思是说read/write不属于glibc，而是内核提供的system call，它的实现自然也要到内核代码中去找。版主为什么就是不承认自己说错了呢？
我是看到版主对read/write的第一反应竟然是glibc，楼主又想知道read/write的实现，那是在glibc里找不到的，才跳出来说两句的，只是澄清一下，语气有点戏谑，在此致歉，还望海涵。
但是仍然要严肃指出的是：将一个系统调用误认为是标准库的一部分是不应该的。
虽然说对于应用程序开发者来说，系统调用应该和普通函数一样的，但是有时又不得不清醒认识到这是一个系统调用，要慎用，系统调用进入内核空间,开销较大，最典型的例子就是直接用read/write很多时候就不如用带缓存的标准I/O库效率高，那样可以减少进入内核空间的次数。我曾经到yahoo面试，其中一个问题就是你用read/write还是标准I/O库，为什么，什么时候用read/write，什么时候用标准I/O库？我认为应该分清楚。

rickxbx

你能说glibc里面的那些不是实现？
嗯，我并不是不承认自己的错误，从我的第二个回帖（也就是本帖的第五个回帖）开始，我就意识到开始弄错了，“果然是内核里面的东西”是我在第七个回帖中的开场，很明显，那时我已经意识到开始确实没有明白楼主的意思。

我是看到版主对read/write的第一反应竟然是glibc，楼主又想知道read/write的实现，那是在glibc里找不到的，才跳出来说两句的，只是澄清一下，语气有点戏谑，在此致歉，还望海涵。

其实看帖子不能这么看的，任何事情总有上下文，你读完所有的回帖（也许）自然就不会那样说了

另外， read/write 确实不是C标准库的一部分，也没人这么说(但却是posix标准库)。在glibc中出现，不能代表就是标准库的一部分。