<p>I am working with RPCs flags that may have a boolean argument which is extracted using <code>GetBoolArg</code> and there are various ways to pass Boolean arguments. For example</p>
<pre><code>-fastprune=1     // true
-fastprune=0     // false
-fastprune       // true 
-fastprune=abc   // true
-nofastprune    // false

(please correct me if any one of them is wrong or if there are more)
</code></pre>
<p>Why is there no consistensy in tests to pass the arguments like <code>=1/=0</code> for <code>true/false</code> or just pass the flag for <code>true</code> and don't pass it for <code>false</code> ? This adds to confusion and adds unnecessary extra cases ! Is there any other rationale behind it excluding backward compatibilty ?</p>

CC BY-SA 4.0
2024-07-22T21:32:53.537Z
`-stopatheight` is an integer argument though, not boolean?
Vojtěch Strnad
CC BY-SA 4.0
2024-07-22T23:36:05.507Z
@VojtěchStrnad thanks for pointing out. Replaced it with boolean rpc.
Prabhat Verma
CC BY-SA 4.0
2024-07-23T10:28:55.547Z
There are some good points here. However, as the final sentence makes clear, this is opinion based. See [tour] regarding opinion based questions.
RedGrittyBrick
CC BY-SA 4.0
2024-07-23T18:19:09.067Z
@RedGrittyBrick thanks for pointing it out. Updated my question !
Prabhat Verma
CC BY-SA 4.0
2024-07-25T02:10:11.900Z
Is the question about the accepted options, or about the tests?
Pieter Wuille
CC BY-SA 4.0
2024-07-25T21:35:06.010Z
@PieterWuille . The question is targeted towards why are there these many options instead of 2 standard ones.
Prabhat Verma
<json-rpc><bitcoin-core-development>
Clarity on rpc flag design to pass boolean arguments
Prabhat Verma
# Clarity on rpc flag design to pass boolean arguments

(Asked by: username_0 on 2024-07-22)

I am working with RPCs flags that may have a boolean argument which is extracted using GetBoolArg and there are various ways to pass Boolean arguments. For example
-fastprune=1     // true
-fastprune=0     // false
-fastprune       // true 
-fastprune=abc   // true
-nofastprune    // false

(please correct me if any one of them is wrong or if there are more)

Why is there no consistensy in tests to pass the arguments like =1/=0 for true/false or just pass the flag for true and don't pass it for false ? This adds to confusion and adds unnecessary extra cases ! Is there any other rationale behind it excluding backward compatibilty ?

**Tags:** json-rpc, bitcoin-core-development

> **Comments:**
> **username_1**: `-stopatheight` is an integer argument though, not boolean?  
> **username_0**: @VojtěchStrnad thanks for pointing out. Replaced it with boolean rpc.  
> **username_2**: There are some good points here. However, as the final sentence makes clear, this is opinion based. See [tour] regarding opinion based questions.  
> **username_0**: @username_2 thanks for pointing it out. Updated my question !  
> **username_3**: Is the question about the accepted options, or about the tests?  
> **username_0**: @PieterWuille . The question is targeted towards why are there these many options instead of 2 standard ones.  

---

## 0 answers

