C语言中直接使用*argv[]中的char指针是否安全？

直接赋值是否安全？ #

直接将optarg赋值给自定义char*指针是标准、合法的用法，本身没有内存安全问题，不需要强制做内存拷贝。
首先你现有代码有一个容易踩的坑：getopt()遍历完所有参数后返回值是-1，你当前的while循环判断没有显式和-1对比，在char类型默认无符号的编译环境下，-1转成无符号char会变成255，永远不等于0，直接触发死循环。正确的循环写法应该是：

while ((ch = getopt(argc, argv, ":f:")) != -1) {
    // 分支逻辑
}

optarg的本质是指向argv数组内部元素的指针，它指向的内存生命周期和main函数传入的argv完全一致，只要你还在main函数的执行流程里、没有主动篡改argv的内存，这个指针就一直有效，只读访问完全没问题。

什么时候需要用strcpy拷贝？ #

不需要无脑拷贝，只有以下几种场景需要你主动申请独立内存、把optarg指向的字符串复制过去再用：

• 你需要修改参数字符串的内容：optarg指向的是进程启动时传入的原始命令行参数，直接修改虽然不会立刻崩溃，但会丢失原始输入值，如果后续逻辑还要读取原始参数就会出逻辑错误。
• 你需要在argv失效后（比如封装函数返回后、主动覆盖了argv内存区域）继续使用这个参数值。
• 额外提醒：就算要拷贝也别直接用无边界检查的strcpy，要先计算字符串长度，申请足够的内存空间，优先用带长度限制的拷贝函数（比如strndup、snprintf），避免缓冲区溢出。

修改argument指向内容会不会导致环境变量被篡改？ #

完全不会。
optarg指向的内存属于argv参数区，和进程存储环境变量的environ内存块是完全独立的两个区域，修改optarg指向的内容根本碰不到环境变量。
但这里确实存在安全风险：如果你往argument指向的地址写入超过原参数长度的内容，会发生栈/堆溢出，覆盖相邻的其他命令行参数、栈上的函数返回地址，这是典型的可被利用的内存漏洞，但这是C语言字符串操作的通用风险，不是getopt或者直接赋值写法独有的问题。
如果你全程只是读取参数内容、不做修改，直接用赋值得到的指针是效率最高、也足够安全的选择，不需要额外拷贝徒增内存管理成本。

内容的提问来源于stack exchange，提问作者Michael M.