Re: Delay Routine: Fully-portable C89 if possible

rob windgassen wrote:
On Wed, 10 Oct 2007 09:09:43 +0200, David Brown wrote:

First the simple part - omitting the "int" part of declarations and
definitions is an abomination

That is a matter of personal taste.


In the specific case of type names like "unsigned int", it is arguably a matter of taste - although it is a general rule of programming style that it is better to be explicit than implicit. "long", for example, can be used for both "long int" and "long double" - there is no type "long" in itself.

Other implicit "int" cases in C have been gradually dropped in newer standards. For example, it used to be legal to declare a function:

extern foo();

which returns an "int", and which takes as many "int" parameters as you want. This sort of thing is not a matter of taste - it is simply bad programming style, and contrary to every attempt at safe programming.

If the proposed newer C types _Fract and _Accum become a reality, then there will be an even stronger reason to drop the implicit "int", since these will also support specified types like "unsigned short _Fract".

brought about by the terrible keyboards
K&R had to work with when developing C.

Dunno, maybe, but it is not relevant.


On closer checking, it seems that the implicit "int" comes from the language "B", but the basic reason was to minimise keystrokes (that was also the reason for allowing functions without declarations, and other such implicit or abbreviated coding).

The type in question is called
"long unsigned int" - "long" and "unsigned" are type qualifiers.

No. Unless the C-standard has changed overnight this is not true.

per section 6.7.2 of the standard all of "long", "unsigned" and "int" are called 'type-specifier' in the standard. A list of valid _sets_ of type-
specifiers is presented in that section and it includes "long" and "long int" as well "unsigned" and "unsigned int", etc.
per section 6.7.3 'type-qualifier' is defined as one of "const", "restrict" or "volatile" and nothing else.


You are correct here regarding the official C terminology - "long", etc., are "type specifiers". But they do not in themselves form types - the "int" is implied if it is missing, but it is still part of the type.


Rob

.

Relevant Pages

  • Re: _JoyDef and _Control
    ... a declaration with no type defaults to int ... the problem wasn't "implicit int" but the LALRconflict created ... 'typedef' itself. ...
    (comp.lang.c)
  • Re: main return value stange question
    ... value (relying on implicit int), ... Now we know it won't compile, ... Dig the even newer still, yet more improved, sig! ...
    (comp.lang.c)
  • Re: References on C99
    ... notable omission: implicit "int" in declarators. ... There is actually a second deletion; implicit function declaration. ...
    (comp.std.c)
  • Re: Override the property
    ... But I am not only concerned with a string type but also a Boolean or Int or decimal etc. ... IntType x = new IntType; ... Now what if you had an implicit conversion operator method added to IntType we could now do this:- ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: couple of novice questions using Dev-C++
    ... The reserved names are cited in the C++ standard, ... to the 1990 C standard which didn't require explicit specification ... This 'implicit int' has been removed from the 1999 version of the C ...
    (alt.comp.lang.learn.c-cpp)