Fixes a memory leak issue in the Avro C library under abnormal data scenarios.

[kwenzh]

What is the purpose of the change

• Does not properly validate that the string length does not exceed available buffer space, potentially leading to buffer overflow
• Add a macro definition AVRO_SAFE_READ to release memory upon exception return.

Verifying this change

• Construct a schema and data that do not match, and call the read_string function to read them.
• Observe memory usage.
• Stop reading，Observe if memory usage decreases.

Alternatively, you can use valgrind to check for memory leaks.

Documentation

[martin-g]

This returns only the buffered bytes, not all remaining bytes as the memory io branch above

[kwenzh]

sorry， I haven't found a way to get the remaining buffer length for file I/O. My goal is to check the maximum readable length before malloc to avoid memory leaks caused by the length exceeding the limit during avro_read_memory checks. Are there any other good solutions?

[kwenzh]

This returns only the buffered bytes, not all remaining bytes as the memory io branch above

maybe use (int64_t) sizeof(reader->buffer) , Am I understanding this correctly?

[kwenzh]

This returns only the buffered bytes, not all remaining bytes as the memory io branch above

I re-optimized the function logic.

[fabiocfabini]

Is anything preventing this particular request to be merged?

[fabiocfabini]

Why can't the fix simply include the addition of the AVRO_READ_OR_FREE macro and replace the AVRO_READ calls in the read_string and read_bytes functions?

[martin-g]

Is anything preventing this particular request to be merged?

There are no active maintainers of the C SDK...

We will need to the community to review and approve the changes before merging it.

[kwenzh]

Is this issue confirmed? Are there any other questions regarding the code modification logic?

[fabiocfabini]

Is anything preventing this particular request to be merged?

There are no active maintainers of the C SDK...

We will need to the community to review and approve the changes before merging it.

How can one become such a maintainer? Also, what does it mean the community needs to review?

[fabiocfabini]

Is this issue confirmed? Are there any other questions regarding the code modification logic?

Is there a reasons why the modifications can't simply revolve around replacing AVRO_READ for AVRO_READ_OR_FREE in the read_string and read_bytes functions?

[martin-g]

How can one become such a maintainer?

https://community.apache.org/contributors/becomingacommitter.html

Also, what does it mean the community needs to review?

It means that the users of the C SDK are encouraged to review the PR(s) and comment on them - what is good and bad. Once a PR is approved by a few users we (the maintainers of the other SDKs) can merge it and make it part of the next release.

[kwenzh]

Is this issue confirmed? Are there any other questions regarding the code modification logic?

Is there a reasons why the modifications can't simply revolve around replacing AVRO_READ for AVRO_READ_OR_FREE in the read_string and read_bytes functions?

The current modification is as follows, isn't ?

[fabiocfabini]

The current modification is as follows, isn't ?

What is the purpose of the avro_max_read function being introduced? The current error reporting already accurately reports if the string size is bigger then the size of the encoded buffer. What other purpose does it serve?

[kwenzh]

The current modification is as follows, isn't ?

What is the purpose of the avro_max_read function being introduced? The current error reporting already accurately reports if the string size is bigger then the size of the encoded buffer. What other purpose does it serve?

safe code to preventtoo big mem allocate