Re: Type of argc

Richard Heathfield wrote:

Douglas A. Gwyn said:

"ad288" <spamoff@xxxxxxxxxxx> wrote in message
news:slrnfe6aeu.6lc.spamoff@xxxxxxxxxxxxxxxxx
Wouldn't it be more consistent to phase out the existing prefferred
proto-type for main and replace it with
int main(size_t argc, char **argv)

No, that would impose a sudden inconsistency with existing practice.

So did removing implicit int, but it improved the language nevertheless.

That thing would only visually improve the language. It wouldn't really improve the language.
It would have a transition cost, unless it's not adopted by programmers.
You may think, "but my proposal is backward compatible".
But ANY change in the language creates problems. Why?

Because, it makes porting programs hard.

1) New stupid programmer #1 write on platform #1:
long long main(size_t, char** argv);
2) Clever programmer #2 has to port the program to platform #2 which has a compiler not up to date.
He has to change the declaration of main.

The whole point of size_t is to record object counts and sizes, and the
role of argc is to provide a count of the number of pointers in the
array to whose first element argv points, so size_t is absolutely the
right type for it.

Yes, it would be the right type, but to make the committee adopt a change, you've to *prove* that it would be useful (pretty isn't useful) *right now*, for at least *one existing* implementation, for at least *one existing project*.

For example, for the variable return type, you could argue that you were developing project X on platform Y using the LP64 model with 128 bits long long, and you had to return a 128 bits MD5 to the system through the return value, but you couldn't do it with the standard function prototype because int was 32 bits, which is stupid because *this system* currently *supports* 128 bits return values through a call to a system function SysExit. Unfortunately this SysExit functions doesn't clean up correctly your program resources so that you cannot call it: You must either call exit() or return from main(), otherwise some system-wide resouces may leak.

In that case, we could start discussing. e.g. I could said that the portable workaround would be to output the MD5 on stdout, which would make the program portable to *NIX systems (you can only return one byte of status code on those systems), and that the next revision of your program could use a 256 bits number without changing the interface of your program.
I could also have argued that, since programs using this feature *cannot* produce portable programs, this feature should be provided as an extension. e.g. THIS implementation could support "long long main()" since the C standard explicitly allow this type of extension.
5.1.2.2.3p1 "If the return type is not compatible with int, the termination status returned to the host environment is unspecified."

For size_t, you could have argued that you were developing project X on platform Y and you *needed* more than INT_MAX parameters, that the system provided a size_t much larger than INT_MAX and had the capacity of passing more than INT_MAX parameters to your program but the parameter list was pushed as an argument to a startup function and your C implementation couldn't report all the arguments to your main() function so that you couldn't get all the parameters.

Then, I would have argued that for such big bunch of data, stdin is more appropriate. And that this C implementation could provide a non-standard way to access all the parameters (i.e. this is a QOI issue), such as making argv a NULL-terminated string of pointers to char.

Since, in our own code, most of us normally put the
pointer-to-first-element argument first, and the count afterwards
(memcpy and fgets are good standard library examples of my meaning), my
own preference for the main interface would be:

Changing order of parameters is pointless. The transition is painful for programmers for ZERO benefits but a ridiculously tiny consistency issue.


int main(char **argv, size_t argc)


You seem to ignore constness issues. This is an half-baked false improvement of main.

int main(size_t argc,char * const * argv);

Would be closer to something meaningful, but is not acceptable, as it doesn't bring anything needed.

but I accept that this would be, for most people, a change too far.


As any change in the prototype of main() would be.



--
You can contact me at <tabkanDELETETHISnaz@xxxxxxxxxxxxxxxxxx>
.

Relevant Pages

  • Re: learning c and c++
    ... >> books on each desired language, more would be better, but of course ... > possible) int to char, ... 'int') If you know that a particular 'int' value is within ... to a 'string'. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Binary-mode i/o, width of char, endianness
    ... where should fread put this? ... >>into a long int. ... > Consider a platform with 11-bit bytes. ... type 'char' interchangably with 'an int that is one _byte_ big'. ...
    (comp.lang.c)
  • Re: Explain this
    ... At least in C and C++, the fact that we're assigning a char to x ... and C++ in a different way: in C, a character literal has type int, ... compiling it as C++ would assign to the global. ... but a language that was considerably different ...
    (comp.lang.cpp)
  • Re: Simplicity has a future
    ... simpler language it is the language of choice when you want something ... char **raster(int width, int height) ... The snag with exceptions is that people try to complicate things by allowing ...
    (comp.lang.c)
  • Re: Integer types "ambiguous"
    ... likely to only be 32 bitsw on a 32 bit platform, but could well be 64 on a 64 bit platform? ... The other requirement is that each type (char, short, int, long, long long) in sequence be no smaller than the preceding one. ... and it specifies ranks of the types such that conversion from a lower order rank to a higher does not cause changes of the value. ...
    (comp.os.linux.development.apps)