title: Can sizeof(int) ever be 1 on a hosted implementation?
body: <p>My view is that a C implementation cannot satisfy the specification of certain <code>stdio</code> functions (particularly <code>fputc</code>/<code>fgetc</code>) if <code>sizeof(int)==1</code>, since the <code>int</code> needs to be able to hold any possible value of <code>unsigned char</code> or <code>EOF</code> (-1). Is this reasoning correct?</p>
  
  <p>(Obviously <code>sizeof(int)</code> cannot be 1 if <code>CHAR_BIT</code> is 8, due to the minimum required range for <code>int</code>, so we're implicitly only talking about implementations with <code>CHAR_BIT&gt;=16</code>, for instance DSPs, where typical implementations would be a freestanding implementation rather than a hosted implementation, and thus not required to provide <code>stdio</code>.)</p>
  
  <p><strong>Edit</strong>: After reading the answers and some links references, some thoughts on ways it might be valid for a hosted implementation to have <code>sizeof(int)==1</code>:</p>
  
  <p>First, some citations:</p>
  
  <p>7.19.7.1(2-3):</p>
  
  <blockquote>
    <p>If the end-of-ﬁle indicator for the input stream pointed to by stream is not set and a
    next character is present, the fgetc function obtains that character as an unsigned
    char converted to an int and advances the associated ﬁle position indicator for the
    stream (if defined).</p>
    
    <p>If the end-of-ﬁle indicator for the stream is set, or if the stream is at end-of-ﬁle, the endof-ﬁle indicator for the stream is set and the fgetc function returns EOF. Otherwise, the
    fgetc function returns the next character from the input stream pointed to by stream.
    If a read error occurs, the error indicator for the stream is set and the fgetc function
    returns EOF.</p>
  </blockquote>
  
  <p>7.19.8.1(2):</p>
  
  <blockquote>
    <p>The fread function reads, into the array pointed to by ptr, up to nmemb elements
    whose size is speciﬁed by size, from the stream pointed to by stream. For each
    object, size calls are made to the fgetc function and the results stored, in the order
    read, in an array of unsigned char exactly overlaying the object. The ﬁle position
    indicator for the stream (if deﬁned) is advanced by the number of characters successfully read.</p>
  </blockquote>
  
  <p>Thoughts:</p>
  
  <ul>
  <li><p>Reading back <code>unsigned char</code> values outside the range of <code>int</code> could simply have <strike>undefined</strike> implementation-defined behavior in the implementation. This is particularly unsettling, as it means that using <code>fwrite</code> and <code>fread</code> to store binary structures (which while it results in nonportable files, is supposed to be an operation you can perform portably on any single implementation) could appear to work but silently fail. <strike>essentially always results in <em>undefined behavior</em>. I accept that an implementation might not have a usable filesystem, but it's a lot harder to accept that an implementation could have a filesystem that automatically invokes nasal demons as soon as you try to use it, and no way to determine that it's unusable.</strike> Now that I realize the behavior is implementation-defined and not undefined, it's not quite so unsettling, and I think this might be a valid (although undesirable) implementation.</p></li>
  <li><p>An implementation <code>sizeof(int)==1</code> could simply define the filesystem to be empty and read-only. Then there would be no way an application could read any data written by itself, only from an input device on <code>stdin</code> which could be implemented so as to only give positive <code>char</code> values which fit in <code>int</code>.</p></li>
  </ul>
  
  <p><strong>Edit (again):</strong> From the C99 Rationale, 7.4:</p>
  
  <blockquote>
    <p>EOF is traditionally -1, but may be any negative integer, and <em>hence distinguishable from any valid character code</em>.</p>
  </blockquote>
  
  <p>This seems to indicate that <code>sizeof(int)</code> may not be 1, or at least that such was the intention of the committee.</p>