Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove (some) unused macros #2852

Closed

Conversation

rikardfalkeborn
Copy link
Contributor

I gave Clangs -Wunused-macros a go and it showed a couple of warnings. IMO the warning is far too noisy to turn on for normal builds (I don't think it is not worth conditionally defining certain macros depending on which platform/compiler/configuration is used, and it'd be silly to remove i.e. CURL_MASK_SCHAR from warnless.c even though it's not used since just about every other MASK exists and is used). The macros in this PR should be fine to remove. Perhaps I could have just squashed the commits, but one at the time makes it possible to be more verbose in the commit message. :)

The macro seems to never have been used.
The macro has never been used, and it there is not really any place
where it would make sense to add timing checks.
@bagder
Copy link
Member

bagder commented Aug 9, 2018

Thanks!

@bagder bagder closed this in 489ac01 Aug 9, 2018
bagder pushed a commit that referenced this pull request Aug 9, 2018
bagder pushed a commit that referenced this pull request Aug 9, 2018
bagder pushed a commit that referenced this pull request Aug 9, 2018
The macro seems to never have been used.

Closes #2852
bagder pushed a commit that referenced this pull request Aug 9, 2018
The macro has never been used, and it there is not really any place
where it would make sense to add timing checks.

Closes #2852
@rikardfalkeborn rikardfalkeborn deleted the remove-unused-macros branch August 9, 2018 20:35
xquery pushed a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery pushed a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery pushed a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery pushed a commit to xquery/curl that referenced this pull request Sep 3, 2018
The macro seems to never have been used.

Closes curl#2852
xquery pushed a commit to xquery/curl that referenced this pull request Sep 3, 2018
The macro has never been used, and it there is not really any place
where it would make sense to add timing checks.

Closes curl#2852
falconindy pushed a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy pushed a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy pushed a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy pushed a commit to falconindy/curl that referenced this pull request Sep 10, 2018
The macro seems to never have been used.

Closes curl#2852
falconindy pushed a commit to falconindy/curl that referenced this pull request Sep 10, 2018
The macro has never been used, and it there is not really any place
where it would make sense to add timing checks.

Closes curl#2852
@pps83
Copy link
Contributor

pps83 commented Oct 2, 2018

Perhaps unrelated, but I recently discovered that to my surprise if I post some binary data using libcurl it's posted with application/x-www-form-urlencoded content-type. IMO libcurl shouldn't do that: should either post plain binary or fail and require explicit content-type.

@jay
Copy link
Member

jay commented Oct 3, 2018

Perhaps unrelated, but I recently discovered that to my surprise if I post some binary data using libcurl it's posted with application/x-www-form-urlencoded content-type.

How's it related to this issue? --data-binary doesn't do any processing with the provided data but that does not imply octet stream, as far as I see it.

jay added a commit to jay/curl that referenced this pull request Oct 3, 2018
- Advise user that --data-binary sends a default content type of
  x-www-form-urlencoded, and to have the data treated as arbitrary
  binary data by the server set the content-type header to octet-stream.

Ref: curl#2852 (comment)

Closes #xxxx
jay added a commit that referenced this pull request Oct 3, 2018
- Advise user that --data-binary sends a default content type of
  x-www-form-urlencoded, and to have the data treated as arbitrary
  binary data by the server set the content-type header to octet-stream.

Ref: #2852 (comment)

Closes #3085
@pps83
Copy link
Contributor

pps83 commented Oct 3, 2018

How's it related to this issue? --data-binary doesn't do any processing with the provided data but that does not imply octet stream, as far as I see it.

It's not related, but I noticed that HTTPPOST_CONTENTTYPE_DEFAULT is deleted and I recalled that behavior where libcurl would add x-www-form-urlencoded if I post some binary data.
I would rather prefer that it failed with an error instead of waiting for that moment where my posted binary data suddenly can be trated by the server as url-encoded instead

@lock lock bot locked as resolved and limited conversation to collaborators Jan 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants