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
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@rikardfalkeborn
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. :)

rikardfalkeborn added some commits Aug 5, 2018

asyn-thread: Remove unused macro
The macro seems to never have been used.
test1540: Remove unused macro TEST_HANG_TIMEOUT
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.

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

bagder added a commit that referenced this pull request Aug 9, 2018

bagder added a commit that referenced this pull request Aug 9, 2018

asyn-thread: Remove unused macro
The macro seems to never have been used.

Closes #2852

bagder added a commit that referenced this pull request Aug 9, 2018

test1540: Remove unused macro TEST_HANG_TIMEOUT
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

asyn-thread: Remove unused macro
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

test1540: Remove unused macro TEST_HANG_TIMEOUT
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

asyn-thread: Remove unused macro
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

test1540: Remove unused macro TEST_HANG_TIMEOUT
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.

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.

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

data-binary.d: clarify default content-type is x-www-form-urlencoded
- 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

data-binary.d: clarify default content-type is x-www-form-urlencoded
- 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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment