使用DeepSeek、豆包、Kimi生成的libcoap程序所遇到的问题总结

引言

最近需要写一个CoAP协议的服务端,使用C语言,所以就用DeepSeek、豆包、Kimi生成了基于libcoap的代码,不管哪个工具都有错误,花了一个下午才把程序调试好,记录一下。三个大模型都不能生成100%正确代码。我厂商用一个模型去自动修复另一个模型的错误代码,也失败了,在修复时他们会偏重代码的规范性检查,而不是代码中真正的错误。这里就不比较哪个大模型更好一些了。

问题

结构体中字符串溢出

这个问题在三个大模型中都有,请看下面的代码:

/* 车位资源结构体 */
typedef struct {
    int id;
    char status[10];  // "free", "occupied", "maintenance"
} parking_slot_t;

/* 全局车位资源 */
parking_slot_t slots[] = {
    {1, "free"}, {2, "occupied"}, {3, "free"}, {4, "maintenance"}
};

这里的status长度设置为10,但是字符串“maintenance”已经超过10个字符了,所以会导致溢出,好在编译器在初始化结构体的地方给出了警告。如果没有初始化结构体,可能不容易发现这个错误。这里的另外一个经验是所有的警告都要当做错误去检查一遍

回调函数参数个数不对

下面的代码中,回调函数的参数多了一个token,删除掉就对了。这个地方也是有warning,register那里只是一个函数指针,编译器是可以生成代码的,但是由于参数错误,如果运行肯定会导致参数错误,严重的话会崩溃,因为牵扯指针操作。再次提醒我们:所有的警告都要当做错误去检查一遍

void handle_parking_slot(coap_resource_t *resource, coap_session_t *session,
                         const coap_pdu_t *request, const coap_binary_t *token,
                         coap_string_t *query, coap_pdu_t *response) {
…… 
}


……

        coap_register_request_handler(resource, COAP_REQUEST_GET, handle_parking_slot);

coap_get_data函数的用法错误

coap_get_data函数的作用是从CoAP PDU中取得载荷的,按理说是个常用函数,但是三个大模型都不能正确处理这个函数,不是参数少,就是参数多,比如DeepSeek生成的代码是这样的:

    size_t len;
    const uint8_t *data = coap_get_data(request, &len);
    if (!data || len == 0) {
        coap_pdu_set_code(response, COAP_RESPONSE_CODE(400));
        return;
    }

正确的代码应该是

    size_t len;
    const uint8_t *data;
    uint8_t ret = coap_get_data(request, &len, &data);
    if (!ret || len == 0) {
        coap_pdu_set_code(response, COAP_RESPONSE_CODE(400));
        return;
    }

 这个错误倒是比较容易发现,因为编译器报告了错误。 

coap_add_option参数个数错误

DeepSeek生成的代码如下:

    coap_add_option(response, COAP_OPTION_CONTENT_FORMAT,
                    coap_encode_var_safe(NULL, 0, COAP_MEDIATYPE_APPLICATION_LINK_FORMAT));

coap_add_option有4个参数,而生成的代码是3个参数,显然编译器会报告错误。

size_t 	coap_add_option (coap_pdu_t *pdu, uint16_t type, size_t len, const uint8_t *data)

coap_encode_var_safe的用法也有小问题。coap_encode_var_safe是libcoap新加的函数,用以替代原来的coap_decode_var_bytes,以提高代码的安全性,它的定义如下:

unsigned int coap_encode_var_safe	(	uint8_t * 	buf,
size_t 	length,
unsigned int 	value 
)	

 修改的代码如下:

    uint8_t buf[3];
    coap_add_option(response, COAP_OPTION_CONTENT_FORMAT,
                    coap_encode_var_safe(buf, sizeof(buf), COAP_MEDIATYPE_APPLICATION_LINK_FORMAT), buf);

出现了libcoap没有的函数

这个问题主要出现在豆包,它出现了明显的幻觉,生成了诸如coap_context_get_resources、coap_session_get_context这样的函数,我让Kimi和DeepSeek修复代码,他们都能改掉这部分。

结语

总的来看,生成的CoAP代码没有MQTT代码质量高,主要的原因可能还是CoAP没有MQTT用的多,另外libcoap的API还在演进中,不同版本代码的学习可能也导致大模型有点混乱。对大模型生成的代码一定要认真检查,否则运行时不知道要出啥事。

DeepSeek豆包Kimi以及GPT都是涉及人工智能技术的不同产品和服务,各自有着不同的特点和发展背景。 DeepSeek是一个由360公司支持的人工智能搜索引擎项目。除了提供传统的搜索功能之外,还集成了多种AI服务,例如通过与多家国内顶尖的大模型合作来实现更复杂的任务处理,如文本生成、图像转视频等。此外,360为DeepSeek提供了专门的安全服务通道——"DeepSeek高速专线",确保数据传输的安全性和速度。 豆包Kimi是中国互联网巨头腾讯旗下的一个大模型系列之一。这类模型通常被集成进腾讯的各种应用中,比如微信、QQ和其他社交平台,以增强用户体验和互动性。虽然最初可能受到较多关注和支持,但随着时间推移,某些版本可能会减少官方推广力度而转向自然发展状态。 GPT(Generative Pre-trained Transformer)是由OpenAI开发的一系列大型语言模型的名字。它代表了一类先进的机器学习算法,能够根据给定提示生成类似人类编写的文本段落。由于其强大的自然语言理解和生产能力,GPT在全球范围内获得了广泛的应用,并成为许多对话系统和技术的基础组件。 联系方面: - 这些平台都在利用深度学习技术和大规模的数据训练来改进自身的性能。 - 它们均属于现代信息技术领域内的创新成果,旨在提高人们获取信息及交流沟通效率。 区别在于: - DeepSeek侧重于构建综合性的AI服务平台,结合了安全防护措施; - 豆包Kimi更多地融入到了具体的消费级应用程序之中; - GPT作为一个开源框架,强调的是开放共享的精神及其在研究领域的贡献; 综上所述,尽管这三个实体之间存在一些共通之处,但在定位、目标市场和技术路径等方面各有千秋。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

神一样的老师

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值