Re: integer size and portability-a wishful controversy

From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 03/17/04 

Date: 17 Mar 2004 14:00:27 GMT

In <40575174.520B9B46@yahoo.com> CBFalconer <cbfalconer@yahoo.com> writes:

>Dan Pop wrote:
>>
>... snip ...
>>
>> You're using an old version of Turbo C, designed for a 16-bit
>> processor and a 16-bit operating system. The Microsoft compiler,
>> OTOH, was designed for a 32-bit processor and a 32-bit operating
>> system. Hence the difference.
>>
>> BTW, there is no point in using the old Turbo C compiler, unless
>> you still have the machine and OS it was originally designed for.
>
>I disagree. It can be very useful in checking for foolish coding
>assumptions. An example would be a piece of code recently posted
>here entitled "GetFileSize()". Another would be any code that
>assumes a pointer can be stored in an int, and then extracted.

These days, a 64-bit platform is more appropriate for this kind of
checking, most of them having (or supporting) the I32LP64 model.

I do NOT consider programs relying on int having at least 32 bits as
being badly designed (these days, int is the de facto 32-bit type, long
being 64-bit on many 64-bit platforms). I consider backward compatibility
to MSDOS as a design flaw, rather than as a positive/desirable feature
for a program written these days. Less than 32-bit int's have been a
feature of freestanding implementations only, for quite a while.

16-bit compilers for PCs are, these days, tools for the experts who
use the PC as an almost freestanding platform for developing/testing
device drivers for various pieces of PC hardware. Of course, such
code is non-portable by definition. It is, nevertheless, extremely
helpful to someone wanting to write a device driver for the same
piece of hardware for a real OS.

Another example is test suites for various pieces of PC hardware.
The final product fits on a single bootable diskette that works
regardless of the OS actually installed on the machine. I have even
seen such diskettes for applying firmware upgrades/patches to various
types of IDE hard disks.

But I wouldn't want such software to be developed by people like the OP...

Dan 

-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Relevant Pages

  • Re: Moving from C++ to VC++
    ... A long doesn't have to be wider than an int - it just can't be narrower. ... If there is more than one type that has the corresponding "maximally long hardware type", ... platform, those who will switch to that platform will fix breakage caused by the change? ... It was perceived by most to be necessary because the 16 bit platform was in _reality_ as well as in perception inadequate for the tasks at hand. ...
    (microsoft.public.vc.language)
  • Re: c dll to c#
    ... just name me a C compiler that targets the Microsoft Windows ... platform who has a 64 bit "built-in" long type. ... mapping for an int and a long looks like: ...
    (microsoft.public.dotnet.languages.csharp)
  • printf anomaly
    ... My understanding is that the 1000 will default to int ... Then it will be promoted to unsigned long (since on our platform long ... and printf is a variadic ... I must be missing something or the compiler is broken? ...
    (comp.lang.c)
  • Re: data types
    ... ...but the manual for the compiler I am using says int is 16-bit. ... typedef [whatever type is 16 bits in your platform] int16; ...
    (comp.lang.c)
  • Re: misaligned access clarification
    ... i was doing some tinkering and wrote the following code on a HPUX ... cast it to int* and dereference it, it's expected to be the adddress ... why does the compiler expect to get an aligned address... ... is split over interesting hardware boundaries can be slower ...
    (comp.lang.c)