reading legacy floppy disks

[Steve Harvey]

On Sun, Sep 10, 2006 at 12:29:37PM -0400, John Macdonald wrote:
> On Sun, Sep 10, 2006 at 10:57:25AM -0400, Seneca Cunningham wrote:
> > 
> > On 10-Sep-2006, at 04:09 :09, John Macdonald wrote:
> > 
> > >On Sat, Sep 09, 2006 at 11:33:58PM -0400, Christopher Browne wrote:
> > >>The sizes of char/short/int/long are not required to be any  
> > >>particular
> > >>size in the standard.  If memory serves, the relationship needs to
> > >>hold that:
> > >>
> > >> sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> > >>
> > >>But having 8 bit ints *is* consistent with...
> > >>
> > >>   8 <= 8 <= 8 <= 16
> > >
> > >But it is not consistant with the other rule about the
> > >size of an int - an int has to have enough bits to
> > >hold a pointer.  For any machine with more than 256
> > >addressable units, an 8-bit int doesn't work.
> > 
> > What rule?  I've dealt with systems that are ILP32 and LP64 (which  
> > one is determined by compiler flags).  AIX is one of them, and if my  
> > recollections of porting are correct, Linux on AMD64 is another.  The  
> > assumption that many 32-bit developers seem to hold that an int is  
> > the same width as a pointer causes porting delays.
> 
> Sorry, I meant to write "rule" instead of rule.
> 
> It is not a real rule, but it was a programming practice for
> a long time.  Because the default type for a function is int,
> and int was "always" large enough to hold a pointer, people
> would not bother to specify the type of functions when they
> were just copying the results around.  K&R (original edition)
> warned about this practice ("a rather cavalier attitude toward
> copying pointers").
> 
> It meant that compiler designers were knowingly choosing to
> have portability problems if they used a smaller size for int
> than pointer.  So, it tended to be done only for cross-compilers
> that were targetting stand-alone device controllers that were
> not going to be used as general purpose computers (and for which
> porting existing programs was not such an important issue).
> 
  This was a major issue in porting System III Unix to the Honeywell
Level 6.  Storage was addressed as 16-bit words; if you needed a
char *, a 16-bit index was tacked onto the pointer making a grand
total of 48 bits.  Other pointers stayed at 32 bits, which, if
memory serves me correctly, was sizeof(long), with int being 16 bits.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wini/Mailing_lists