user59861: I am reading the docs on DigitalRead() and wondering why it stores seemingly boolean HIGH and LOW inputs in int data type variable. 
I have two issues with that:

int is 2-byte, while bool and uint8_t are 1-byte so it seems like a waste of memory for no benefit whatsoever.
It gets me confused when reading the code about whether the input came from digital or analog since int can have a wide range.

Is there any particular reason for storing digital inputs as int?
EDIT: bool and uint8_t are out of the question as per the answer below. int8_t still looks suitable for the purpose though.

user63752: The smallest unit in most languages is a byte (8 bits), whether signed or unsigned. 
So returning a byte, even if it only returns three different values, is the smallest and most efficient unit available, that I'm aware of.  
If you want to store later, you can assign each bit of a byte as a high or low, thus giving you 8 storage spots. 

user16780: I did not check the internals a while, but in early days there was a 
 #define HIGH 1

meaning that HIGH is a const int. 
Perhaps someone did not want to disable some TRI-STATE digital logic in the beginning, and since then nobody wanted to change the basics.
But of course bool is a more appropriate data type for HIGH/LOW and of course you can always treat them this way, for example like
if (! digitalRead(pin) ) { // pin is LOW
   ... 
} 


jsotola's answer why Serial.read() returns  an int is a different issue. And correct of course.

user40318: You receive the data as int, but you store it as byte.
For example, when you call the serial library function to receive a data byte, the library will return either the data or a -1 if a problem has occurred.
The binary value of -1 is a byte 11111111 or int 1111111111111111.
The binary value of 255 is a byte 11111111 or int 0000000011111111.
I think that you can see the problem if you use byte data and the data is 255.
So, if you receive an int -1, then you do not process the data.  Otherwise you cast the int to uint8_t.
You could receive byte data, but then the value of 255 would be undefined.

59861: <p>I am reading the docs on <a href="https://www.arduino.cc/reference/en/language/functions/digital-io/digitalread/" rel="nofollow noreferrer">DigitalRead()</a> and wondering why it stores seemingly boolean <code>HIGH</code> and <code>LOW</code> inputs in <code>int</code> data type variable. </p>

<p>I have two issues with that:</p>

<ol>
<li><code>int</code> is 2-byte, while <code>bool</code> and <code>uint8_t</code> are 1-byte so it seems like a waste of memory for no benefit whatsoever.</li>
<li>It gets me confused when reading the code about whether the input came from digital or analog since <code>int</code> can have a wide range.</li>
</ol>

<p>Is there any particular reason for storing digital inputs as <code>int</code>?</p>

<p>EDIT: <code>bool</code> and <code>uint8_t</code> are out of the question as per the answer below. <strong><code>int8_t</code></strong> still looks suitable for the purpose though.</p>
 63752: <p>The smallest unit in most languages is a byte (8 bits), whether signed or unsigned. 
So returning a byte, even if it only returns three different values, is the smallest and most efficient unit available, that I'm aware of.  </p>

<p>If you want to store later, you can assign each bit of a byte as a high or low, thus giving you 8 storage spots. </p>
 16780: <p>I did not check the internals a while, but in early days there was a </p>

<pre><code> #define HIGH 1
</code></pre>

<p>meaning that HIGH is a <code>const int</code>. </p>

<p>Perhaps someone did not want to disable some TRI-STATE digital logic in the beginning, and since then nobody wanted to change the basics.</p>

<p>But of course <code>bool</code> is a more appropriate data type for HIGH/LOW and of course you can always treat them this way, for example like</p>

<pre><code>if (! digitalRead(pin) ) { // pin is LOW
   ... 
} 
</code></pre>

<hr>

<p>jsotola's answer why Serial.read() returns  an <code>int</code> is a different issue. And correct of course.</p>
 40318: <p>You receive the data as <code>int</code>, but you store it as <code>byte</code>.</p>

<p>For example, when you call the serial library function to receive a data byte, the library will return either the data or a -1 if a problem has occurred.</p>

<p>The binary value of -1 is a byte 11111111 or int 1111111111111111.</p>

<p>The binary value of 255 is a byte 11111111 or int 0000000011111111.</p>

<p>I think that you can see the problem if you use <code>byte</code> data and the data is 255.</p>

<p>So, if you receive an <code>int</code> -1, then you do not process the data.  Otherwise you <code>cast</code> the <code>int</code> to <code>uint8_t</code>.</p>

<p>You could receive <code>byte</code> data, but then the value of 255 would be undefined.</p>
