size_t problems

[Malcolm McLean]

Ed Jensen wrote
Ahh the "regulars" here. Always the pompous claims but then, they
present a few lines of code with such an OBVIOUS bug!

I didn't spot it.
Either I'm another stupid regular, or the bug isn't so obvious.

 

[Mark McIntyre]

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Undefined - for all we know, read could do the following

size_t read(void *buf, size_t siz)
{
int x;
fflush(stdin);
siz = x;
x = x++ + x++;
strcpy(buf, "supercalifrajilisticexpialidocious");
return strlen(buf);
}
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Ian Collins]

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

To quote someone you might know "or they practice good progamming(sic)
technique and isolate interface code into different (and replaceable)
libraries".

 

[Harald van =?UTF-8?B?RMSzaw==?=]

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

No, but every function not provided by the standard library has to be
defined by the program.

 

[Ian Collins]

On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?
Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

No, but every function not provided by the standard library has to be
defined by the program.

Quite. The function read would be in a library.

 

[Malcolm McLean]

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Undefined - for all we know, read could do the following

size_t read(void *buf, size_t siz)
{
int x;
fflush(stdin);
siz = x;
x = x++ + x++;
strcpy(buf, "supercalifrajilisticexpialidocious");
return strlen(buf);
}

It obviously performs some output, otherwise the program can be optimised to
nothing.
Also the assignment to n is purposeless in standard C. However if read()
performs some action oustide the standard, for instance setting a memory
trap, it might make sense.

 

[Richard Heathfield]

Keith Thompson said:

Everyone makes mistakes.

The "regulars", in my experience, are distiguished by their
willingness to acknowledge and correct their mistakes, and to thank
those who point them out.

Indeed. Everyone makes mistakes. To err is human, and all that. People
are not criticised here for making mistakes, but they *are* (rightly)
criticised for refusing to acknowledge them or to learn from them.

<snip>

 

[Richard]

Pardon me, I should have said "in standard C, the topic of this
newsgroup"


Some would disagree.

Who? If it is a function being called in a C program and that function
is callable then it is C. Not the function. But the code calling it. And
C details how one might deal with the data from that function.

 

[Richard]

No, but we don't know what the code does.

Yes "we" do. You look at the prototype.

read is almost certainly reading bytes into buffer. However it might
also clobber the stack and set size to zero, disallowed for a standard
function. There might be some reason this is desired and useful
behaviour.

Oh, please.

 

[Malcolm McLean]

Indeed. Everyone makes mistakes. To err is human, and all that. People
are not criticised here for making mistakes, but they *are* (rightly)
criticised for refusing to acknowledge them or to learn from them.

It would be nice if that were true.

 

[Richard Heathfield]

Malcolm McLean said:

It would be nice if that were true.

I think it *is* true, by and large. Mistakes *are* pointed out, and
rightly so, but to point out a mistake is *not* the same as to
criticise the person who made it. I make my fair share of mistakes (or
perhaps more!), but when people in clc point this out, I don't feel
threatened or intimidated by the fact. On the contrary, I welcome
corrections for what they really are - opportunities to learn and to
improve my programming.

 

[Richard Tobin]

Is the following legal:

typedef int array_type[7];
array_type *atwo = (array_type *)&aone[3];

[/QUOTE]

It depends on the alignment requirements of array_type.

Are you suggesting an array type can have different alignment requirements
from those of its elements?

-- Richard

 

[Joe Wright]

I didn't spot it.
Either I'm another stupid regular, or the bug isn't so obvious.

Having 'fclose(fp);' the value of fp becomes indeterminate. Subsequent
use of it is undefined.

 

[pete]

Is the following legal:

typedef int array_type[7];
array_type *atwo = (array_type *)&aone[3];

It depends on the alignment requirements of array_type.

Are you suggesting an array type can have different alignment
requirements from those of its elements?[/QUOTE]

Yes.

 

[pete]

Is the following legal:

typedef int array_type[7];
array_type *atwo = (array_type *)&aone[3];

It depends on the alignment requirements of array_type.

Are you suggesting an array type can have different alignment
requirements from those of its elements?

Yes.

However I'll admit that I had not considered
that object types aren't intrinsic properties of objects,
when I stated
"If (&p) is the address of an object of an array type,
then p[-3] isn't defined."
and that my statement wasn't the example of
"a sufficiently restricted interpretation of array index"
that I had intended it to be.

 

[santosh]

IO is hardware dependent, the rest is not.

Also other things. Exceptions, privileged instructions, debugging etc.

 

[CBFalconer]

.... snip ...

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Without the (standard C) source code for 'read', not standard C.
Think of it this way: Can anybody reproduce the action with your
source and a C compiler on any compliant C system?

 

[CBFalconer]

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?

Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

Not at all. But the source has to be available, and in std. C.

 

[CBFalconer]

As specified in the C standard, main returns zero, and it is not
necessary to write a return statement.

Before you start talking nonsense read the standard.

That does not apply to C90. So, for portable use omitting the
return is still a failure, especially since that failure fails to
report any possible i/o errors.

and failure to test the result from printf. From N869:

[#14] The fprintf function returns the number of characters
transmitted, or a negative value if an output or encoding
error occurred.

A correct version could be:

#include <stdio.h>
#include <stdlib.h>
int main(void) {
if (0 > printf("hello\n")) return EXIT_FAILURE;
return 0;
}

If you re read your code you will see that you missed the ELSE
arm of the IF statement. You see?

The only if statement with an else arm was in the above code
snippet, which I wrote as an example for you. And it didn't
contain an else, only implied by bypassing the first return
statement. Ignoring the facts while beating your chest does not
lead to good software. BTW, your code snippet is still fully
quoted above, which should enable you to check my statement. But I
advise calming down first.

Incidentally, in C the else and if keywords are written in lower
case. By convention upper case versions are macros. Failure to
use lower case appropriately can cause unexpected failures in
carelessly written software.

 

[CBFalconer]

.... snip ...

There's no reason it couldn't do exactly the same thing for an
explicit call to strlen().

The call itself may be longer than the execution of the inline, for
suitably short strings. And lets face it, 99% of C strings are
short, meaning under 10 chars or so. This is highly system and CPU
specific, and thus really OT here.

Maybe somebody will build a modified strlen routine which keeps
length statistics and install it in his system library. After some
test period that can validate (or invalidate) my claim above.