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

rikardfalkeborn commented Aug 8, 2018

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
bagder approved these changes Aug 9, 2018
@bagder

This comment has been minimized.

Copy link
Member

bagder commented Aug 9, 2018

Thanks!

@bagder bagder closed this in 489ac01 Aug 9, 2018
bagder added a commit that referenced this pull request Aug 9, 2018
Its usage was removed in
84ad1fd.

Closes #2852
bagder added a commit that referenced this pull request Aug 9, 2018
Usage was removed in 5113ad0.

Closes #2852
bagder added a commit that referenced this pull request Aug 9, 2018
The macro seems to never have been used.

Closes #2852
bagder added 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 rikardfalkeborn:remove-unused-macros branch Aug 9, 2018
xquery added a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery added a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery added a commit to xquery/curl that referenced this pull request Sep 3, 2018
xquery added 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 added 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 added a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy added a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy added a commit to falconindy/curl that referenced this pull request Sep 10, 2018
falconindy added 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 added 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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.
Projects
None yet
4 participants
You can’t perform that action at this time.