emirpasic / gods

GoDS (Go Data Structures) - Sets, Lists, Stacks, Maps, Trees, Queues, and much more
Other
16.32k stars 1.77k forks source link

fix: list.first is nil not check #247

Open qlw319 opened 6 months ago

sonarcloud[bot] commented 6 months ago

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

emirpasic commented 6 months ago

Under which circumstance is the index within the range, but the first element is nil? The function withinRange should take care of that, no?

!list.withinRange(index) || list.first == nil
qlw319 commented 6 months ago

In the process of using linkedlistqueue.Queue, when calling size is greater than 0, but when calling peek, there is a null pointer exception in line 89 of singlelinkedlist.go. We used the 1.81.1 release version. 

钱龙伟 @.***

 

------------------ 原始邮件 ------------------ 发件人: "Emir @.>; 发送时间: 2024年4月12日(星期五) 下午3:30 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [emirpasic/gods] fix: list.first is nil not check (PR #247)

在什么情况下,索引在范围内,但第一个元素是零? 功能范围内应该能解决这个问题吧 !列表.范围内(指数)||列表.第一==零

- 直接回复这封邮件,在GitHub上查看,或取消订阅. 您收到此消息是因为您创建了线程。消息ID:<酋长/众神/拉/ 247 / @.***和>

emirpasic commented 6 months ago

@qlw319 I still not understand how it came to that state. Is size is bigger than zero, should not the first element exist in that case?

Is it perhaps possible to write a simple test first that causes this issue? That way, we could then understand how it came to be and if we fixed the issue

qlw319 commented 6 months ago

ok, you're right. It does need to be checked carefully. When I'm free, I'll write a test case just to make sure. 

钱龙伟 @.***

 

------------------ 原始邮件 ------------------ 发件人: "Emir @.>; 发送时间: 2024年4月12日(星期五) 下午3:50 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [emirpasic/gods] fix: list.first is nil not check (PR #247)

@qlw319 I still not understand how it came to that state. Is size is bigger than zero, should not the first element exist in that case?

Is it perhaps possible to write a simple test first that causes this issue? That way, we could then understand how it came to be and if we fixed the issue

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>