how this works? is it or bug or not???

C

CBFalconer

Ioannis said:
stdio.h is not mentioned defining size_t explicitly in the
standard, although we can infer that it is defined in it from
the included functions.

Please control your line length. It should not exceed 72, but 67
is better. FYI, the following clip is from N869. Note paragraph
1.

7.17 Common definitions <stddef.h>

[#1] The following types and macros are defined in the
standard header <stddef.h>. Some are also defined in other
headers, as noted in their respective subclauses.

[#2] The types are

ptrdiff_t

which is the signed integer type of the result of
subtracting two pointers;

size_t

which is the unsigned integer type of the result of the
sizeof operator; and
 
B

Ben Bacarisse

CBFalconer said:
Ioannis said:
stdio.h is not mentioned defining size_t explicitly in the
standard, although we can infer that it is defined in it from
the included functions.

Please control your line length. It should not exceed 72, but 67
is better. FYI, the following clip is from N869. Note paragraph
1.

7.17 Common definitions <stddef.h>

[#1] The following types and macros are defined in the
standard header <stddef.h>. Some are also defined in other
headers, as noted in their respective subclauses.

Ioannis Vranos's post says:

#include <stddef.h> /* It defines size_t type*/

Did you think he was asking for the paragraph number? What new
information does your "FYI" refer to?
 
C

CBFalconer

Ben said:
CBFalconer said:
Ioannis said:
Han from China wrote:
Ioannis Vranos wrote:

#include <stdio.h> /* Correction 1: Needed for printf() */
#include <stddef.h> /* It defines size_t type*/

stdio.h defines size_t as well.

stdio.h is not mentioned defining size_t explicitly in the
standard, although we can infer that it is defined in it from
the included functions.

Please control your line length. It should not exceed 72, but 67
is better. FYI, the following clip is from N869. Note paragraph
1.

7.17 Common definitions <stddef.h>

[#1] The following types and macros are defined in the
standard header <stddef.h>. Some are also defined in other
headers, as noted in their respective subclauses.

Ioannis Vranos's post says:

#include <stddef.h> /* It defines size_t type*/

Did you think he was asking for the paragraph number? What new
information does your "FYI" refer to?

His post implies that size_t is defined only in stddef.h
 
B

Ben Bacarisse

CBFalconer said:
Ben said:
CBFalconer said:
Ioannis Vranos wrote:
Han from China wrote:
Ioannis Vranos wrote:

#include <stdio.h> /* Correction 1: Needed for printf() */
#include <stddef.h> /* It defines size_t type*/

stdio.h defines size_t as well.

stdio.h is not mentioned defining size_t explicitly in the
standard, although we can infer that it is defined in it from
the included functions.

Please control your line length. It should not exceed 72, but 67
is better. FYI, the following clip is from N869. Note paragraph
1.

7.17 Common definitions <stddef.h>

[#1] The following types and macros are defined in the
standard header <stddef.h>. Some are also defined in other
headers, as noted in their respective subclauses.

Ioannis Vranos's post says:

#include <stddef.h> /* It defines size_t type*/

Did you think he was asking for the paragraph number? What new
information does your "FYI" refer to?

His post implies that size_t is defined only in stddef.h

So to help out you told him that is was defined in stddef.h? Or maybe
the point of the whole quote was the vague "some are also defined in
other headers" which says nothing about whether size_t is included in
that "some".

Look at the quotes to see far the discussion had come before you
offered the quote from stddef.h. Ioannis had been told that stdio.h
defines size_t and he had claimed that this was not the case (as far
he could tell). You come along and quote a section that says that
size_t *might* be one of the types that *might* be defined elsewhere.
All of the this hours after several posters have quoted the exact
place in the standard that says that size_t is declared in stdio.h.
 
I

Ioannis Vranos

The code without the unneeded inclusion of stddef.h.

Your code corrected:


#include <stdio.h> /* Correction 1: Needed for printf() */
int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

const size_t SIZE= sizeof(ar)/sizeof(ar[0]); /* this gets 8 perfectly */

int main(void)
{
/* Correction 1: We must pass the expected argument
in a variadic function
*/
printf("%lu", (unsigned long)SIZE);


/* Correction 2: */
if(-1L <= (long)SIZE)
printf("1");

else
printf("2");

puts("");


return 0;
}


People let's not make it a flame.
 
K

Keith Thompson

Ioannis Vranos said:
The code without the unneeded inclusion of stddef.h.
Your code corrected:

#include <stdio.h> /* Correction 1: Needed for printf() */

int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

Given the initializer, the size needn't be specified.

int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

On the other hand, if you get the size wrong the compiler will
complain; that might be the point.
const size_t SIZE= sizeof(ar)/sizeof(ar[0]); /* this gets 8 perfectly */

The parentheses are unnecessary but harmless. All-caps identifiers
are conventionally used for macros, but using one for a constant isn't
too bad.

Whether changing -1 to -1L and casting SIZE to long is a "correction"
depends on what the program is supposed to do. I would argue that the
original program is *supposed* to illustrate a particular case of
argument promotion; given that goal, the change breaks the program
rather than fixing it.

Alos, the indentation is very misleading; the puts() call is not part
of the else clause, and the return statement is 8 columns too far to
the right.

If I really wanted to show the result of the comparison, I might write:

printf("-1L <= (long)SIZE : ");
if (-1L <= (long)SIZE) {
puts("Yes");
}
else {
puts("No");
}

Or, of course, the whole thing could be replaced by either:
puts("1");
or
puts("2");
People let's not make it a flame.

Ok, I'm not flaming, just finding as many things to complain about as
I can. :cool:}
 
I

Ioannis Vranos

I am talking about C90/C95.


Keith said:
int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

Given the initializer, the size needn't be specified.
And?




int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

On the other hand, if you get the size wrong the compiler will
complain; that might be the point.

It isn't bad practice to specify the size of an array explicitly, under any circumstances, and of course one
may not specify it explicitly and depend on the initializer.

So there was no point for making these comments.


const size_t SIZE= sizeof(ar)/sizeof(ar[0]); /* this gets 8 perfectly */

The parentheses are unnecessary but harmless. All-caps identifiers
are conventionally used for macros, but using one for a constant isn't
too bad.


There was no point for this comment too.

Alos, the indentation is very misleading; the puts() call is not part
of the else clause, and the return statement is 8 columns too far to
the right.

If I really wanted to show the result of the comparison, I might write:

printf("-1L <= (long)SIZE : ");
if (-1L <= (long)SIZE) {
puts("Yes");
}
else {
puts("No");
}


The spaces thing in my quoted code must be a bug of my newsgroup program, my first post with the redundant
#include <stddef.h> had spaces placed well.
 
K

Keith Thompson

Ioannis Vranos said:
I am talking about C90/C95.

As opposed to C99, I presume? I see nothing in this thread that's
C99-specific.
Keith said:
int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

Given the initializer, the size needn't be specified.
And?


int ar[8]= {1, 2, 3, 4, 5, 6, 7, 8};

On the other hand, if you get the size wrong the compiler will
complain; that might be the point.

It isn't bad practice to specify the size of an array explicitly,
under any circumstances, and of course one may not specify it
explicitly and depend on the initializer.

So there was no point for making these comments.

I'll grant you that there wasn't *much* of a point, but there was some.
If you declare the array as:

int ar[] = {1, 2, 3, 4, 5, 6, 7, 8};

then you don't have to update the size constant when you add new
elements to the array:

int ar[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

Incidentally this was in the original code, which you copied; I wasn't
criticizing you, just commenting on the code.
const size_t SIZE= sizeof(ar)/sizeof(ar[0]); /* this gets 8 perfectly */

The parentheses are unnecessary but harmless. All-caps identifiers
are conventionally used for macros, but using one for a constant isn't
too bad.


There was no point for this comment too.

The point is that the parentheses are unnecessary but harmless, and
that all-caps identifiers are ... well, see above. Personally, I
prefer not to use parentheses on a sizeof operator unless they're
necessary. It emphasizes the important point that sizeof an an
operator, not a function. I don't object to the extra parentheses;
I'm just pointing out that they're not needed.
The spaces thing in my quoted code must be a bug of my newsgroup
program, my first post with the redundant #include <stddef.h> had
spaces placed well.

Were you using tab characters, perhaps without knowing it?
 
D

David Thompson

Surely you realize that the expression 8 has type int. If the OP had
written your expression instead of his, I wouldn't have made the
comment. As it is, the #define does not produce an int though on some
systems it may produce an unsigned int. I expect on most it probably
produces an unsigned long.

Almost. sizeof yields size_t, which must be an unsigned integer type,
definitely not int. In C90 it is most likely u-int or u-long; in C99
it can quite reasonably be u-long long.

IF size_t is lower in rank than (signed/unsigned) int, and it is
strictly narrower (so that its range fits in the positive half of
int), then the division promotes to int and produces int result.
Otherwise it promotes to unsigned int, or remains size_t.

int must be the 'natural size' for the machine but at least 16 bits.
C99 size_t must be at least 16 bits, so if int is wider than 16 bits
it should be because that is efficient, and thus it is doubtful there
is a good reason why size_t should be narrower. But it is allowed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,438
Messages
2,571,699
Members
48,796
Latest member
Greg L.
Top