当前位置：首页>Excel>C 语言学习笔记 :类型安全 / sizeof / 存储单位 /

C 语言学习笔记 :类型安全 / sizeof / 存储单位 /

对应课程章节：「C是有类型的语言」「类型安全」「C语言的类型」「类型有何不同」「sizeof」

一、类型安全（关于强类型的争论）

•早期和面向底层的语言强调类型：C 诞生于写操作系统（UNIX）的年代，变量必须"先定义、确定类型"才能使用。

•C 以后的语言向两个方向发展：

•C++ / Java：更强调类型，检查更严格（编译期就大量拦截类型错误）；

•JavaScript / Python / PHP：不看重类型，甚至不需要事先定义（动态类型）。

•C 中类型的"检查力"不足：C 的类型系统相对宽松（如指针可以强制转换、整型之间隐式转换），很多类型错误编译器不报错，要到运行时才暴露，甚至完全不暴露。

•两派观点：

•支持强类型：明确的类型有助于尽早发现程序中的简单错误；

•反对强类型：过分强调类型迫使程序员面对底层、实现，而非事务逻辑。

•课程观点：这里并不评判哪个对，各有适用场景。

二、sizeof 是静态运算符

•sizeof 是一个运算符（不是函数），给出某个类型或变量在内存中所占的字节数。•sizeof(int)、sizeof(i) 都是合法写法。

•关键性质：静态运算符

•结果在编译时就确定了；

•括号里的表达式不会真正执行（不产生运算）；

•例如 sizeof(i++) 中 i++ 不会发生，i 的值不变；

•因此 sizeof 的返回值类型是 size_t，编译期常量。

三、补充：比特与字节——计算机的存储单位

•为什么是 2^10 = 1024 而不是 1000？——计算机内部是二进制，地址和容量都按 2 的幂组织。

•注意区分：网络带宽常用 Mb/s（兆比特每秒），小写 b 表示比特；硬盘容量厂商常按 10 进制（1GB = 10^9 字节）标注，所以系统里看到的容量会"缩水"。

•与课程内容呼应：

•char 占 1 字节 = 8 bit，能表示 2^8 = 256 种状态（所以 unsigned char 范围是 0~255）；•C 语言各类型在内存中占 1 ~ 16 个字节，内存中的表达形式是二进制（补码）或编码（如浮点数的 IEEE 754）。

四、新闻补充：

PHP 严重漏洞"PHP2Shell"（2026 年 10 月）事件：

2026 年 10 月 21 日，PHP 官方发布安全公告，修复两个**无需身份验证即可远程代码执行（RCE）**的严重漏洞，被合称 "PHP2Shell"。

国家互联网应急中心（CNVD）已于 10 月 22 日收录并发布公告（CNVD-2026-41674 / 41675）。

关键信息：

•影响范围：PHP 8.2.x（<8.2.35）、8.3.x（<8.3.36）、8.4.x（<8.4.27）、8.5.x（<8.5.12）；PHP-FPM、Apache mod_php、php-cgi 等所有以 Web 方式提供服务的 PHP 安装都受影响，mod_php 风险最高。

•波及生态：WordPress、Drupal、Joomla、Laravel、phpMyAdmin、Nextcloud 等大量基于 PHP 的系统；公开报道确认暴露的受影响服务器超过百万台。

•修复版本：PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35（2026-10-21 发布）；官方还为 PHP 7.4 / 8.0 / 8.1 提供了最小源码回移植补丁。

•危害：拒绝服务、敏感数据窃取、远程代码执行；技术细节与 PoC 已广泛传播，荷兰、芬兰、日本等多国机构曾临时关站避险。

与课程知识的联系（重点）：

1.PHP 解释器本身就是用 C 写的——这两个漏洞的根源都是 C 层面的内存管理错误（未初始化状态、UAF 释放后使用），正印证了"C 的类型检查力不足、内存靠程序员自己管"。

2.漏洞涉及的核心概念就是本节课内容：内存中的字节、状态的初始化与销毁、内存的分配与释放。强类型/内存安全的语言（如 Rust、Java）在设计上就很难出现这类 Use-After-Free。

3.这也解释了为什么 C++/Java 要"更强调类型、检查更严格"：把错误拦在编译期，比运行时被攻击者利用便宜得多。

参考来源：

•PHP 官方安全公告（2026-10-21）：https://www.php.net/archive/2026.php

•CNVD 公告：https://www.cert.org.cn/publish/main/9/2026/20261022162132536309183/20261022162132536309183_.html

•ENISA / EU 联合声明：https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。