All issues
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by inspecting main, stringToBigNumber, BigNumberGetNumber, convertBase10ToN, convertCharToInt, and convertIntToChar, then reproduce conversions involving non-decimal bases and very large values. Done means source bases parse correctly, large-number conversions avoid overflow and leaks, integer arithmetic is reliable, and character handling is consistent for supported bases.
Written by the indexing model from the issue text.
Description
-
Critical Logic Failure in Base Conversion
The program is fundamentally broken. It does not correctly convert the input number from its source base to base 10. The code in main and the stringToBigNumber function incorrectly assume the input string is always a base-10 number, rendering the from argument useless. The program will only work if the source base is actually 10. -
Buggy stringToBigNumber Function
The stringToBigNumber function fails to parse numbers from any base other than 10. It uses string[i] - '0' to convert characters to integers, which only works for the characters '0' through '9'. It completely ignores the convertCharToInt helper function, so it cannot handle digits like 'A' (for hexadecimal) or any other letter-based digit. -
Integer Overflow in BigNumberGetNumber
The BigNumberGetNumber function converts a BigNumber back into a standard int. This defeats the entire purpose of the BigNumber library. If the number is too large to fit in an int, this function will overflow and return a meaningless value. This critical bug corrupts the result of the convertBase10ToN function, which relies on it. -
Significant Memory Leaks
The convertBase10ToN function leaks memory inside its while loop. In each iteration, it allocates a new BigNumber for the result of the division (BigNumberDiv) and assigns it to the temp pointer, but it never frees the memory pointed to by the old temp. This leads to a memory leak that grows with the size of the input number. -
Inefficient and Inaccurate Use of pow()
The BigNumberGetNumber function uses pow(), which is a floating-point math function, for integer arithmetic. This is highly inefficient and can introduce precision errors for large numbers, leading to incorrect calculations. -
Inconsistent Character Conversion
The character-to-integer conversion functions are mismatched:
convertCharToInt supports bases up to 36 ('0'-'9', 'A'-'Z').
convertIntToChar supports bases up to 62 ('0'-'9', 'a'-'z', 'A'-'Z').
This means the program could generate output (e.g., in base 40) that it cannot correctly read back as input.
- Dominant language
- C
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BaseMax/BigNumberBaseConverterC
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
All issues in BaseMax/BigNumberBaseConverterC
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
obsproject/obs-studio#13936 · 2 comments ·
Maintainers usually reply within 1 day
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Zenmap bugOpenZenmap
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
lexiforest/curl_cffi#864 ·
Maintainers usually reply within 1 day