Update c curl generator to support float

[amoweb]

Fix for issue #21092

PR checklist

• Read the contribution guidelines.
• [ x Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit ./bin/generate-samples.sh ./bin/configs/*.yaml || exit ./bin/utils/export_docs_generators.sh || exit 

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@eafer

[eafer]

Hi! I just took a quick look at the new generated samples, and I see that petId for deletePet becomes a pointer. What's the point of that? The petId is not nullable, right?

[eafer]

Also, would you mind adding some tests for these issues to the petstore.yaml for C? That would make it much easier to understand what you are doing, and it would prevent other people from breaking this again in the future.

[amoweb]

Hi! Thanks for your answer @eafer ! Considering your comments, I changed the strategy. I added an example in petstore.yaml and I no longer change the function signature.

[eafer]

Thanks. I can see a new UserAPI_testInt32Int64FloatDouble() function in the generated samples, but I'm not seeing the changes to the yaml file that made that happen. Am I missing something, or maybe you forgot to commit that?

[amoweb]

Sorry. I commited the missing yaml file.

[eafer]

Thanks. Why did you set MAX_NUMBER_LENGTH_FLOAT to 32, is this an arbitrary limit? For big float numbers the output of snprintf() will be off. I think in this case it would be better to call snprintf twice, the first time to get the size of the buffer needed.

[amoweb]

Good remark. I defined a default size and reallocate only if needed (so in most case, we only call snprintf once).

Additionally, I figured out that %f displays only 6 decimals by default which is not sufficient for double. I think %.7e for float and %.16e for double is more relevant since they roughly correspond to the float precision (log2(2**significand)).

[eafer]

I defined a default size and reallocate only if needed (so in most case, we only call snprintf once).

What's the advantage of this over just calling snprintf() twice? My concern is that the long float path will almost never get tested.

I think %.7e for float and %.16e for double is more relevant since they roughly correspond to the float precision

Ah yes, that makes more sense.

[eafer]

By the way, what's this change about? Are you using the returned value anywhere?

+ int s = snprintf(valueQuery_{{{paramName}}}, MAX_NUMBER_LENGTH, "%d", *{{{paramName}}}); 

[amoweb]

I think it's less performant to call snprintf() twice. The initial size is sufficient for most numbers (except very big ones). I can still change it if you prefer.

I removed the useless "int s = ".

[eafer]

I think it's less performant to call snprintf() twice.

Sure, but this code only runs right before making a blocking network request, so I don't think it could ever be a bottleneck. I think it's better to keep it simple (unless you have any benchmarks that show otherwise).

I removed the useless "int s = ".

Thanks.

[eafer]

Thank you for making the changes. This looks good to me now @wing328

[amoweb]

@eafer @wing328 Hello, did you had time to have a look to my PR? Thanks

[eafer]

I had already agreed to your PR, I guess @wing328 never saw this. Of course it's been a while so this may no longer apply cleanly.

[wing328]

Sorry I missed it. Will get it reviewed tomorrow.

cc @zhemant (2018/11) @ityuhui (2019/12) @michelealbano (2020/03) @eafer (2024/12)

[wing328]

Thanks for the PR, which has been merged.

Sorry for the delay as there are too many PRs for this project.

Have a good day.