Opened 6 years ago

Closed 5 years ago

#2558 closed defect (fixed)

fromJSON is not able to handle full uint32 range

Reported by: tomek Owned by:
Priority: medium Milestone: Kea0.8
Component: configuration Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I've got a problem with failing Dhcp4ParserTest.Uint32Parser and need some help. DHCP uses various parameters that are unsigned 32 bits. The test tries to verify if certain boundary values (-1, 0, UINT_MAX, UINT_MAX + 1) are parsed or rejected as expected. My test calls fromJSON(), which in turn calls from_stringstream_number() method in src/lib/cc/data.cc.

That function is not able to handle values greater than INT_MAX on 32 bit systems. Note that it does so on 64 bit systems.

Muks suggested:
[10:55:00] <muks> so i suppose we can use strtoll() in there
[10:55:10] <muks> so it works on ILP32 platforms
[10:55:45] <muks> and perhaps have an Element::create() for it..
[10:56:25] <muks> hmm
[10:56:44] <muks> maybe it's better to change IntElement? to hold a long long
[10:57:59] <muks> tomek: can you file a bug for it?
[10:58:24] <muks> it's larger than a simple patch and would need to be reviewed
[10:58:37] <tomek> Sure.
[10:58:46] <muks> we can update IntElement? to hold a int64_t i guess
[10:59:23] <muks> and use strtoll() in from_stringstream_number()

To verify that it indeed works as expected, it seems useful to enable Dhcp4ParserTest.Uint32Parser in src/bin/dhcp4/tests/config_parser_unittest.cc and confirm that it indeed works on 32 bit systems.

Subtickets

Attachments (1)

0003-2558-Update-Session-for-the-new-int64_t-IntElement.patch (8.0 KB) - added by tomek 6 years ago.
Fixed other compilation issues after int->int64_t

Download all attachments as: .zip

Change History (8)

comment:1 Changed 6 years ago by muks

trac2558 has an implementation to make IntElement hold an int64_t.

Changed 6 years ago by tomek

Fixed other compilation issues after int->int64_t

comment:2 Changed 6 years ago by jinmei

btw I believe we should be able to support uint64 values via msgq
for statistics counters.

comment:3 Changed 6 years ago by shane

  • Defect Severity changed from N/A to Medium
  • Milestone changed from New Tasks to DHCP Outstanding Tasks

Putting this onto the DHCP Outstanding Tasks, as it affects Kea.

comment:4 Changed 5 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to DHCP-Kea1.0-alpha

comment:5 Changed 5 years ago by muks

I think this has been fixed already by JPRS in another ticket.

comment:6 Changed 5 years ago by muks

#3015 seems to be the one.

comment:7 Changed 5 years ago by tomek

  • Resolution set to fixed
  • Status changed from new to closed

Włodek confirmed that this is working for DHCPv4 component. v4.options.malformed.values.arp-cache-timeout is used as an example of test that uses 4294967295 value.

Tomek checked that it is working for DHCPv6.

Closing ticket.

Note: See TracTickets for help on using tickets.