Newbie question about "malloc" ???

[Old Wolf]

int i;

void foo(void)
{
auto i = 6;
}

I read somewhere that omitting the implicit 'int' was going to be
deprecated soon (or maybe already deprecated), eg. in the following
expressions:
long i;
short i;
const i;
They didn't mention "auto i;" but I presume it would be similar.

 

[Ben Pfaff]

I read somewhere that omitting the implicit 'int' was going to be
deprecated soon (or maybe already deprecated), eg. in the following
expressions:
long i;
short i;
const i;
They didn't mention "auto i;" but I presume it would be similar.

Inserting "int" following "auto" above doesn't change Richard's
point.

 

[Richard Heathfield]

(Hence my disclaimer.)

Inserting "int" following "auto" above doesn't change Richard's
point.

Actually, it does, because then you'd have:

void foo(void){auto int i = 6;}

and

void foo(void){int i = 6;}

which are synonymous, whereas

void foo(void){auto i = 6;}

and

void foo(void){i = 6;}

are not.

 

[Ben Pfaff]

Inserting "int" following "auto" above doesn't change Richard's
point.

Yes it does. Dammit.

 

[nrk]

I read somewhere that omitting the implicit 'int' was going to be
deprecated soon (or maybe already deprecated), eg. in the following
expressions:
long i;
short i;
const i;
They didn't mention "auto i;" but I presume it would be similar.

I was under the impression that implicit int deprecation applied to
functions without return type, and variable declarations with no type
specified. Does it also apply to declarations along the lines of:
long i;
short i;
??? That, I would find quite annoying.

-nrk.

 

[glen herrmannsfeldt]

(snip)

Have they dropped "auto" from the keyword list behind my back? ;-)
It's by far the most useless keyword, but it's still there.

It may be there. I have never used it, though.

But I only said that AUTOMATIC wasn't, which I will extend to
automatic, but it still isn't auto.

Some attributes in PL/I have abbreviations, and AUTOMATIC does
have the abbreviation AUTO. CONTROLLED has the abbreviation CTL.

The example in the PL/I manual seems to have it as the only
attribute for a variable, such that all others have the default.

Would C take a declaration

auto i;

and consider int the optional default, the way it is in
unsigned int, short int, or long int?

-- glen

 

[Kevin Goodsell]

I was under the impression that implicit int deprecation applied to
functions without return type, and variable declarations with no type
specified. Does it also apply to declarations along the lines of:
long i;
short i;
??? That, I would find quite annoying.

I certainly hope not, and my impression is the same as yours - that it
applies to declarations with no type specified. If Old Wolf was
referring to changes in the C99 standard, then I think "implicit int" in
cases like this is safe. C99 considers 'long', 'short', 'unsigned', etc.
to be type specifiers all by themselves. Unlike C89, it requires that at
least one type specifier be present in a declaration.

From C89:

3.5.2 Type specifiers

Syntax

type-specifier:
void
char
short
int
long
float
double
signed
unsigned
struct-or-union-specifier
enum-specifier
typedef-name

Constraints

Each list of type specifiers shall be one of the following sets; the
type specifiers may occur in any order, possibly intermixed with the
other declaration specifiers.

* int , signed , signed int , or no type specifiers

<remainder of list snipped>



And from C99:

6.7.2 Type specifiers

Syntax

[#1]

type-specifier:
void
char
short
int
long
float
double
signed
unsigned
_Bool
_Complex
_Imaginary
struct-or-union-specifier
enum-specifier
typedef-name

Constraints

[#2] At least one type specifier shall be given in the
declaration specifiers in each declaration, and in the
specifier-qualifier list in each struct declaration and type
name. Each list of type specifiers shall be one of the
following sets (delimited by commas, when there is more than
one set on a line); the type specifiers may occur in any
order, possibly intermixed with the other declaration
specifiers.

<list snipped, but it does not contain anything allowing
the type specifier to be omitted.>


-Kevin

 

[Kevin Goodsell]

Would C take a declaration

auto i;

and consider int the optional default, the way it is in
unsigned int, short int, or long int?

Prior to C99, yes. In C99, no.

-Kevin

 

[Lew Pitcher]

August Derleth wrote:
[snip]

Well, not really. Lew Pitcher gave a full accounting of the C++ code's
failure to be C code in his first response to this thread. [snip]
(Not that this makes much difference, mind you. I merely take delight
in recounting random details on Usenet. It's nothing personal.)

I'm getting used to being a "random detail on Usenet" <grin>.
No offense taken.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Dave Thompson]

Dan Pop wrote:

PL/I calls the storage attributes STATIC, AUTOMATIC, and CONTROLLED.
Those are the language keywords for them.

And BASED. CONTROLLED is (probably) allocated from a heap, but can be
accessed (by name) only in a LIFO fashion, but LIFO separately per
variable, not for all variables in a scope as for automatic. BASED can
be used for arbitrary heap patterns, as well as overlaying and some
special cases (like system-supplied "locate mode" I/O buffers).

C only seems to have
static as a keyword. Automatic seems to be a commonly used word
for that type of dynamic allocation, but I don't think anyone
ever uses controlled for the memory allocated by malloc().

C has auto as a keyword, but it is very rarely used because never
needed -- except in C89 for implicit int locals, which were always
horrible style and now outlawed. There was some discussion a few
months ago on c.s.c (or maybe c.s.c++? I forget) about 'recycling' it
for variable (or local-constant) declarations which take their type
automatically from the required initializer.

Yes, automatic allocation is dynamic, and in C89 must have a
constant size.

-- glen

- David.Thompson1 at worldnet.att.net

 

[nrk]

I was under the impression that implicit int deprecation applied to
functions without return type, and variable declarations with no type
specified. Does it also apply to declarations along the lines of:
long i;
short i;
??? That, I would find quite annoying.

I certainly hope not, and my impression is the same as yours - that it
applies to declarations with no type specified. If Old Wolf was
referring to changes in the C99 standard, then I think "implicit int" in
cases like this is safe. C99 considers 'long', 'short', 'unsigned', etc.
to be type specifiers all by themselves. Unlike C89, it requires that at
least one type specifier be present in a declaration.

From C89:

3.5.2 Type specifiers

Syntax

type-specifier:
void
char
short
int
long
float
double
signed
unsigned
struct-or-union-specifier
enum-specifier
typedef-name

Constraints

Each list of type specifiers shall be one of the following sets; the
type specifiers may occur in any order, possibly intermixed with the
other declaration specifiers.

* int , signed , signed int , or no type specifiers

<remainder of list snipped>



And from C99:

6.7.2 Type specifiers

Syntax

[#1]

type-specifier:
void
char
short
int
long
float
double
signed
unsigned
_Bool
_Complex
_Imaginary
struct-or-union-specifier
enum-specifier
typedef-name

Constraints

[#2] At least one type specifier shall be given in the
declaration specifiers in each declaration, and in the
specifier-qualifier list in each struct declaration and type
name. Each list of type specifiers shall be one of the
following sets (delimited by commas, when there is more than
one set on a line); the type specifiers may occur in any
order, possibly intermixed with the other declaration
specifiers.

<list snipped, but it does not contain anything allowing
the type specifier to be omitted.>


-Kevin

That makes it quite clear that:
long a;
is *not* an instance where the implicit int deprecation is applicable.
Thanks.

-nrk.