blocks|key|2929935|text|不，它不会导致溢出。它最多只能读入sizeof(buffer)字节，然后停止。它不会空终止您的字符串，所以您必须这样做。在确保最后一个字节是\0之前读取buffer将导致未定义的行为(这就是您的sscanf()调用正在做的事情)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2929936|entityMap^0|H|E|1Y|2|24|6|2P|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

No, it won't cause an overflow. It'll read in at most <code>sizeof(buffer)</code> bytes, and then stop. It doesn't null-terminate your string, so you will have to do so. Reading <code>buffer</code> before ensuring the last byte is a <code>\0</code> will lead to undefined behavior (which is what your <code>sscanf()</code> call is doing).

blocks|key|2929957|text|readlink不会溢出，因为它不会将'\0‘放在末尾。但sscanf会。您应该这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2929958|您应该这样做：|2929959|char+buf[5];
ssizet_t+len;
...
if+((len+=+readlink("/proc/self",+buf,+sizeof(buf)-1))+!=+-1)
++++buf[len]+=+'\0';|code-block|syntax|javascript|2929960|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

readlink won't overflow because it doesn't put the '\0' on the end. But the sscanf will. You should do this:

You should do this:

<pre><code>char buf[5];
ssizet_t len;
...
if ((len = readlink("/proc/self", buf, sizeof(buf)-1)) != -1)
 buf[len] = '\0';
</code></pre>

blocks|key|2929989|text|readlink()不会导致溢出，但它不会追加尾随的\0，并且sscanf()可能会造成严重的伤害(缓冲区溢出)。来自readlink()手册页。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2929990|buf+readlink()将符号链接路径的内容放入缓冲区buf中，缓冲区的大小为|2929991|。readlink()不会将空字节附加到buf。它将截断内容(到一定长度的bufsiz字符)，以防缓冲区太小而无法容纳所有内容。|blockquote|2929992|2929993|2929994|此外，readlink()读取PID的文本，该值可以大于"9999"。仅使用四个字节以文本形式存储PID值是不够的。|2929995|entityMap^0|0|A|Q|2|V|8|1N|A|0|0|0|0|0|3|A|S|6|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|10|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|12|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|P|$]]

<code>readlink()</code> will not cause an overflow, but it will not append the trailing <code>\0</code> and <code>sscanf()</code> may potentially hurt badly (buffer overflow). From the <code>readlink()</code> manpage.

<blockquote>
 readlink() places the contents of the
 symbolic link path in the buffer buf,
 which has size bufsiz. readlink() does
 not append a null byte to buf. It will
 truncate the contents (to a length of
 bufsiz characters), in case the buffer
 is too small to hold all of the
 contents.
</blockquote>

Furthermore, <code>readlink()</code> reads the text of the PID, which can be greater than <code>"9999"</code>. Using only four bytes to store the PID value in text is not enough.

blocks|key|862245|text|你的假设是完全错误的。sizeof(pid_t)为4并不意味着需要4个字节来存储表示该数字的十进制字符串。一个典型的16位pid，如12345，显然需要6个字节才能存储为字符串，如果Linux被配置为允许超过32768个进程，那么它很容易就会更长。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|862246|将foo_t整数类型保存为十进制字符串的缓冲区的正确大小为3*sizeof(foo_t)%2B2。如果你关心的话，你可以在边界上做得稍微好一点，但是我不介意在源代码中浪费几个字节的简单性(和明显的正确性)。|862247|(请注意，我假设POSIX需要8位字节，因为pids是一个POSIX概念。如果您希望支持更大的字节，则需要使用CHAR_BIT调整界限。)|862248|entityMap^0|B|D|0|1|5|T|H|0|1J|8|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|K|$]]

Your assumption is completely off-base. <code>sizeof(pid_t)</code> being 4 does not mean that it takes 4 bytes to store a decimal string representing the number. A typical 16-bit pid like 12345 obviously takes 6 bytes to store as a string, and if Linux has been configured to allow more than 32768 processes, it could easily be longer.

The correct size for a buffer to hold a <code>foo_t</code> integer type as a decimal string is <code>3*sizeof(foo_t)+2</code>. You can do slightly better on the bounds if you care, but I don't mind wasting a few bytes for simplicity (and obvious correctness) in the source.

(Note that I'm assuming 8-bit bytes, which POSIX requires, since pids are a POSIX concept. If you wanted to support larger bytes you'd need to adapt the bound using <code>CHAR_BIT</code>.)

I've the following piece of code and I think it can cause an overflow in the readlink() function.

<pre><code>pid_t get_pid_from_proc_self()
{
 char buffer[4];
 pid_t pid;

 readlink("/proc/self", buffer, sizeof(buffer));

 sscanf(buffer, "%d",(int *)&amp;pid);

 return pid;
}
</code></pre>

Since the PID is 4 bytes in Linux, <code>readlink()</code> copies 32 bits from "/proc/self" into <code>target[]</code>. Then, according to me, an extra byte should be used for <code>'\0'</code>, which makes it 5 bytes.

Also, does <code>readlink()</code> automatically inserts <code>'\0'</code> at the end if string or do I have to specifically assign it to the last byte?

Will this cause an overflow?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有下面这段代码，我认为它会导致readlink()函数溢出。pid_t get_pid_from_proc_self(){    char buffer[4];    pid_t pid;    readlink("/proc/self", buffer, sizeof(buffer));    sscanf(buf...

问这会导致溢出吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问这会导致溢出吗？EN