• Re: 这段代码可能存在啥问题?

    这哥们之前还提交过一些更无语的 patch,比如这个 https://lore.kernel.org/lkml/20210407000913.2207831-1-pakki001@umn.edu/

    --- a/net/rds/send.c

    +++ b/net/rds/send.c

    @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head *messages, int status)

    unlock_and_drop:

    spin_unlock_irqrestore(&rm->m_rs_lock, flags);

    rds_message_put(rm);

    -               if (was_on_sock)

    +               if (was_on_sock && rm)

    rds_message_put(rm);

    }

    上面一行都直接用 rm 了,下一行莫名其妙又加一个判断 rm 是否为空

    【 在 qlogic (戒网了) 的大作中提到: 】

    : 看明大一个博士生提交了一个patch,被批

    : -    xxx_put(msg);

    : +    if(msg)

    : ...................

    今天 14:33
  • Re: 这段代码可能存在啥问题?

    看完整这个函数的上下文:

    static void

    gss_pipe_destroy_msg(struct rpc_pipe_msg *msg)

    {

    struct gss_upcall_msg *gss_msg = container_of(msg, struct gss_upcall_msg, msg);

    if (msg->errno < 0) {

    refcount_inc(&gss_msg->count);

    gss_unhash_msg(gss_msg);

    if (msg->errno == -ETIMEDOUT)

    warn_gssd();

    gss_release_msg(gss_msg);

    }

    gss_release_msg(gss_msg);

    }

    这个函数显然约定了输入的 msg 不是 NULL(因为上面已经直接用了),从而 gss_msg 也不可能是 NULL,在这里加一个对它是否为 NULL 的判断没有任何意义。

    他认为这里有 double free。后面有人解释了,其实没有,只不过原来的代码写得不好,if 里面那一对 refcount_inc/gss_release_msg 是多余的,不仔细看会以为它有 double free 。即便真有 double free,正确的修复方式也是删掉 if 里面那一句 gss_release_msg,他加的那一句判断 gss_msg 是否为 NULL 属于莫名其妙。

    【 在 qlogic (戒网了) 的大作中提到: 】

    : 标  题: 这段代码可能存在啥问题?

    : 发信站: 水木社区 (Fri Apr 23 12:58:41 2021), 转信

    : 看明大一个博士生提交了一个patch,被批

    : -    xxx_put(msg);

    : +    if(msg)

    : +      xxx_put(msg);

    : 这个修改可能引入什么问题?

    : 是不是put之前需要检查msg的引用计数,if/put之间不是原子性操作,可能导致问题?

    : --

    今天 13:15
  • Re: [讨论] Process 真是不好翻译

    不赞成。

    翻译没有义务解决原文就存在的问题。

    专业术语的翻译要尽可能保持一一映射,一对多、多对一的翻译都只会让读者更困惑。

    【 在 lambdago (foool) 的大作中提到: 】

    : 谢谢解释,

    : 是不是可以考虑中文可以用新的中文名词,如核程,表示内核态任务/进程Process的含义(类似于一词多义),类似于协程表示用户态线程,虽然它有对应的英文名称coroutine。

    前天 23:43
  • Re: 美国同事不让我们用blacklist这个词 (转载)

    blackbox testing --> opaque box testing / closed box testing

    【 在 nikezhang (难得糊涂) 的大作中提到: 】

    : 黑盒测试呢?飞机上的黑匣子呢

    前天 19:19
  • Re: 美国同事不让我们用blacklist这个词 (转载)

    大部分只要求用户界面,代码里也要严格要求的应该不多

    【 在 PaoloMaldini (solo con te) 的大作中提到: 】

    : 后面这一条,应该稍微有点常识的外企都这么执行了

    前天 14:58
  • Re: 主题:请教UTF8和ANSI 转换问题,要抓狂了。

    我们之前有些代码积极拥抱新标准,用了 u8"..." 来强调字符串是 UTF-8 编码(其实源代码也是 UTF-8,加个 u8 只是为了强调)

    结果 C++20 把 u8"..." 的类型从 const char[] 改成 const char8_t[],而且 const char8_t* 还不能隐式转为 const char*,一堆地方要改,一种吃了屎的感觉

    如果说标准建议凡是 Unicode 字符串都用 char8_t/char16_t/char32_t,想要 deprecate 掉 char/wchar_t,那也行,我都能接受这种阵痛。但尼玛他们又不把支持搞全,std::locale 不支持也就算了,连 C++20 才新增的 std::format 也只有 char/wchar_t 的版本,没有 char8_t/char16_t/char32_t 的版本,真是不知道他们想给我们什么导向。

    【 在 hgoldfish (老鱼) 的大作中提到: 】

    : 个人觉得 win msvc 的做法是不对的。c++11 的标准引入 u8, u 这些做法也是自讨苦吃。

    : 我的做法是所有的源代码都要求是 utf-8,直接用 "" 普通字符串表达式,在 windows 底下,要求 msvc 使用 utf-8 编码:

    : add_compile_options("$<$<C_COMPILER_ID:MSVC>:/utf-8>")

    : ...................

    前天 14:44
  • Re: 美国同事不让我们用blacklist这个词 (转载)

    至少五年前就听过微软禁止使用 white list, black list 了,不仅是用户界面不能用,变量/函数命名也不行

    微软还禁用 country,必须写全 country or region

    【 在 hothail (沸冰!无尽的华尔兹) 的大作中提到: 】

    : 据说,微软很早就搞过这个

    : 最近是漫延到master上

    前天 14:23
  • Re: 请教UTF8和ANSI 转换问题,要抓狂了。

    这个在 exe 里只能是 UTF-16

    编译器需要知道源代码的编码,VS 里面有配置,GCC 有 -finput-charset

    【 在 hgoldfish (老鱼) 的大作中提到: 】

    : 这个在标准里面并没有说明是存储在 EXE 里面的是 GBK 还是 UTF16,

    : 跟编译器的实现有关。跟源代码也有关。

    星期二
  • Re: 请教UTF8和ANSI 转换问题,要抓狂了。

    Windows 上的正确姿势是在程序内部始终使用 WCHAR(就是微软所谓的  "Unicode",实际上特指 UTF-16),只在输入输出时若有必要才进行编码转换

    【 在 easior (潜行) 的大作中提到: 】

    : Windows 的本地化策略集到底怎么定的,中文版程序内码必须是 cp936 吗?

    : 在 Codeblocks 中,MinGW 编译带中文字串的程序,好像必须在区域设置里勾选中文,

    : 否则,无论怎么调整其他区域语言以及UTF-8本地策略集,都会出现乱码。

    : ...................

    星期二
  • Re: [转载]Linus Torvalds 称 C++ 是一种很烂的语言

    Linux kernel 里面的 struct file_operations 不就是虚表吗

    用 C 人肉写一个能用,看不出来有啥本质原因就不能用编译器生成出来的,最多给 G++ 提个需求加个 __attribute__((vtable_section("..."))) 之类的东西应该就差不多了

    【 在 xieyf ( meitian ) 的大作中提到: 】

    : 一切源自虚表吧。去掉虚表的c++就可以安全的做内核开发了吧,一切都手动处理。

    : 编译器就不能禁用虚表?

    星期一
  • Re: Java农转写cpp发现,写Java比写cpp省心太多了

    使用第三方库的时候避免不了,很多库提供的是 C 风格的接口

    【 在 xiaoju (可爱的龙猫) 的大作中提到: 】

    : 写C++的基本求生法则是熟读inside the C++ object model

    : 不过理论上说,现代C++不必也不应该手动分配任何一个raw的资源。不如立条规则,破一次例罚款200块钱,请其他人吃东西。

    星期一
  • Re: Java农转写cpp发现,写Java比写cpp省心太多了

    使用异常的 C++ 代码得把所有涉及到打开/关闭、获取/释放此类操作的代码都用 class 封装起来(所谓 RAII),在实际工程开发中挺麻烦。

    而且,RAII 鼓励在构造函数中完成完整的初始化(与之相对的做法是在构造函数里基本不做什么事,真正的初始化由一个单独的 Init 函数来执行),这样就避免不了构造函数抛异常。

    然而,只要允许了构造函数抛异常,那写代码就需要更小心了。举个例子,请问下面代码中,分别在以下几种情况下:

    * 构造 b_ 时抛了异常

    * 构造 c_ 时抛了异常

    * (1) 处抛了异常

    * (2) 处抛了异常

    ~A() 会执行吗?c_ 的析构函数会执行吗?b_ 的析构函数会执行吗?

    class A {

    public:

    A() : b_(), c_() { /* ... */ }

    A(int x) : b_(), c_() { /* (1) */ }

    A(float x) : A() { /* (2) */ }

    ~A() { /* ... */ }

    private:

    B b_;

    C c_;

    }

    【 在 hgoldfish (老鱼) 的大作中提到: 】

    : 异常安全有什么坑吗?

    : 不是抛出 Exception,接收的时候用 Exception & 就行了吗?

    星期一
  • Re: Java农转写cpp发现,写Java比写cpp省心太多了

    C++ 异常最大的问题是,知道怎样写异常安全代码的程序员太少。。

    语言本身在降低写异常安全代码的难度这一块也不上心,只会教育人 RAII,又不提供好用点的支持,学 Go 提供一个 defer 也行啊,甚至哪怕加一个 finally 也比现状好

    【 在 xiaoju (可爱的龙猫) 的大作中提到: 】

    : 可以不代表该这么用

    : 我见了太多的纯C风格java,python和javascript代码,都是印度培训班杰作

    : 一般来说用什么语言就应该按照什么语言的标准库的规矩写,stl和boost为什么要抛异常啊

    : ...................

    星期日
  • Re: 10天10万行

    2空格现在已经很普遍了,不接受也没办法

    在 Google code style 的带动下,现在连 C++ 都一大把二空格的了。。

    【 在 hgoldfish (老鱼) 的大作中提到: 】

    : 现在 js 社区流行把分号去掉,缩进二空格。。简直是有毛病。

    : 分号已经用了二十年了,我想不明白为啥非要在编程规范里面做这个变化。而且也不是所有的地方都能去掉分号,这不是增加了记忆负担么。

    : 缩进二空格更是丧心病狂!四空格已经很短了,以前的程序员都用 8 空格 80 列。现在 js 居然搞到 2 空格,120 列都不够用。

    : ...................

    04月15日
  • Re: [0xfor x in (1,2,3)]

    还是 C++ 的完备,可以让任何字符都不用转义。。虽然那个括号很讨厌

    【 在 eGust (十年) 的大作中提到: 】

    : 这个比法不太公平啊……

    : foo`template string` 并不改变 `` 本身既支持 escaping 又支持 interpolation 的语法,而 String.raw 和其它的函数也没有任何区别,并不起到改变语义的作用

    : c# 的甚至还支持 @"foo""bar" == "foo\"bar",表达能力非常完整

    : ...................

    04月15日
  • Re: [0xfor x in (1,2,3)]

    我指的是 String.raw

    String.raw`\r\n` === '\\r\\n'

    String.raw`\`  --> Unexpected end of input

    不过,它在语法上真的是把后面的这个字符串(附带上解释转义字符之前的 "raw string")作为参数喂给函数 String.raw。定了这个实现方式,就没法避免不能用 \ 结尾的缺陷。当然我也很想吐槽它这种纠结的设计。

    【 在 eGust (十年) 的大作中提到: 】

    : js 并没有 raw string 的语法啊,你指的是哪个?

    : c# 里 @"" 基本一样的用法,人家也没不能用 \ 结尾

    04月15日
  • Re: [0xfor x in (1,2,3)]

    js 的 raw string 也是这个德行。。。

    【 在 eGust (十年) 的大作中提到: 】

    : 变量不能以数字开头是废话,你倒是说个能用数字开头当变量名的语言瞧瞧?

    : lexer 写成这德行只是偷懒而已,就跟 r'' 不能用 \ 结尾一样,根本毫无道理可言

    04月14日
  • Re: 一个简单的例子说明string_view的好处

    C++98 就允许 basic_string 使用 COW,C++11 好不容易禁止了,又改回去?

    再说 COW 也解决不了无 copy 引用字符串常量、无 copy 引用字符串的子串,这两个场景才是 string_view 的重点。

    标准库没有 string_view 的时候,一大把 C++ 库都自己造了一个 StringRef/StringPiece/StringView,这个需求是真实存在的。

    【 在 roy (天上掉大饼:学思行言) 的大作中提到: 】

    : c++ 20为啥不直接把basic_string改成cow机制的,而是另外又整出一个类来?

    : 然后啥时候该用string 啥时候用stringview,误用了会咋样,又增加了坑啊

    04月14日
  • Re: 主题:像ultraedit那种几百兆的文件秒开是怎么做到的?

    对于用户态程序,没有特别需求的时候,仍然应该以 fread/fseek/read/lseek 这一套“远古”接口为首选。

    用 mmap 并不一定能让你程序变快(用不好还会变慢),而且除非你能 100% 保证你的程序运行时不会有其他进程去修改文件,否则很容易在不可预知的时候 SIGBUS。

    【 在 xiaoju (可爱的龙猫) 的大作中提到: 】

    : filemap是现代OS对文件操作的实现方式,是实际的底层操作。fseek是远古时代OS的顺序读取方式,现在是作为兼容层存在的。

    : 你可以看看nt源代码,文件,cache,虚拟内存这些玩意底层最后都是一套代码

    04月14日
  • Re: 有什么办法能让CPU一直在10%-15%的使用状态。 (转载)

    算啥原周率啊。。 写个忙等+sleep就完了

    这样就可以单核15%了:

    while (true) {

    target_time = curtime() + 15

    while (curtime() < target_time) {}

    sleep(85);

    }

    (curtime和sleep是示例,不是真实函数)

    【 在 MrBright (没有烟抽的日子) 的大作中提到: 】

    : 没错,我后来就是用的这个方法。。

    : 机器是四线程的。

    : 网上找了个用BASH算圆周率的口令。每过几分钟跑一次。

    : ...................

    04月12日