Program size limitation

[AB]

Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?

 

[Ian Collins]

Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Depends on your compiler.

 

[Keith Thompson]

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?

The C standard imposes no specific limit on the number of lines either
in a translation unit or in a program. A compiler could impose such a
limit, I suppose, but there's no particular reason to do so (unless
it's a cripped demo). As far as I know, it's the same for C++.

 

[jacob navia]

AB a écrit :

Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?

Some compilers (like MSVC 6.0 for instance) would have problems
when compiling sources with more than 65535 lines. This is due
to the debug information format that MSVC was using some years ago.

Other compilers have no practical limits, even if the OS can have some
limitations.

Gcc under windows (mingw) stops at more than 65535 relocations in an
object module. lcc-win32 had this limit some years ago but I took it
away, maybe mingw has done that too, I do not know.

Of course there is the limitations of disk space (I think that above
1000 million lines your hard disk starts getting full) and there is some
limitations in executable size: under 32 bits systems you usually
can't have a program of more than 2GB size (2GB reserved for the
system) or at most 3GB... This surely puts a stop in the number of lines
of code your program can have. 64 bits systems do not have that
limitation but may have others, since no one has implemented a full
64 bit virtual space yet.

jacob

 

[Stephen Sprunk]

AB a écrit :

Of course there is the limitations of disk space (I think that above
1000 million lines your hard disk starts getting full) and there is some
limitations in executable size: under 32 bits systems you usually
can't have a program of more than 2GB size (2GB reserved for the
system) or at most 3GB... This surely puts a stop in the number of lines
of code your program can have.

Not true. Someone here recently posted an example of a program that had
thousands of lines of code, branches, computed gotos, functions, etc. that,
after optimization, resulted solely in the machine code equivalent of
"return 7;". It is a common beginner mistake to assume that source code
size has any relation to the output code size.

Also, even on 32-bit systems, there is no fundamental limit of 2GB or 3GB;
that's an implementation detail. There is at least one x86 Linux variant
that gives user code 4GB minus a few (4kB) pages for trapping NULL and for
switching to kernel page tables on a syscall. If that's not enough, the
implementation could implement overlays so that the actual program could
exceed 4GB, just not with all parts loaded at the same time. MS implemented
similar tricks in Windows for accessing parts of 36-bit PAE memory within
32-bit userland.

Even disk space is not a practical limitation, since one can always add more
disks to make bigger arrays and use multiple object files if a single object
would exceed a 64-bit filesystem.

The only practical limit is in how complex a program can get and still be
correct and maintainable.

64 bits systems do not have that limitation but may have others, since
no one has implemented a full 64 bit virtual space yet.

That's really no different than the 32-bit non-limits.

I am a little curious what happens when __line__ exceeds the range of a long
long, though...

S

 

[Keith Thompson]

I am a little curious what happens when __line__ exceeds the range of
a long long, though...

(__LINE__, not __line__)

__LINE__ expands to

The presumed line number (within the current source file) of the
current source line (an integer constant).

(C99 6.10.8p1)

Presumably it could be an unsigned long long literal. I suppose an
attempt to use __LINE__ when the line number exceeds ULLONG_MAX would
invoke undefined behavior.

The "#line" directive can be used to change the presumed line number,
but:

The digit sequence shall not specify zero, nor a number greater
than 2147483647.

(C99 6.10.4p3)

That's not in a constraint, so attempting to use #line to set the
presumed line number to ULLONG_MAX would invoke undefined behavior.

I see this is cross-posted to comp.lang.c++; the C++ rules may be
different.

 

[Scott J. McCaughrin]

: AB a ?crit :
: > Hello all,
: >
: > I heard once that there is a limitation on the number of lines of code
: > that a program can have when using C, but not for C++. Is this true?
: >
: > Any ideas?
: >

TI suspect the 4 GByte limitation is for "flat mode" with x86 architecture,
meaning un-segmented (all code in one s32-bit segment), as then the max
offset for EIP = 2^32 - 1.

-- Scott
==========


: Some compilers (like MSVC 6.0 for instance) would have problems
: when compiling sources with more than 65535 lines. This is due
: to the debug information format that MSVC was using some years ago.

: Other compilers have no practical limits, even if the OS can have some
: limitations.

: Gcc under windows (mingw) stops at more than 65535 relocations in an
: object module. lcc-win32 had this limit some years ago but I took it
: away, maybe mingw has done that too, I do not know.

: Of course there is the limitations of disk space (I think that above
: 1000 million lines your hard disk starts getting full) and there is some
: limitations in executable size: under 32 bits systems you usually
: can't have a program of more than 2GB size (2GB reserved for the
: system) or at most 3GB... This surely puts a stop in the number of lines
: of code your program can have. 64 bits systems do not have that
: limitation but may have others, since no one has implemented a full
: 64 bit virtual space yet.

: jacob