469,366 Members | 2,198 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,366 developers. It's quick & easy.

size_t problems

I am trying to compile as much code in 64 bit mode as
possible to test the 64 bit version of lcc-win.

The problem appears now that size_t is now 64 bits.

Fine. It has to be since there are objects that are more than 4GB
long.

The problem is, when you have in thousands of places

int s;

// ...
s = strlen(str) ;

Since strlen returns a size_t, we have a 64 bit result being
assigned to a 32 bit int.

This can be correct, and in 99.9999999999999999999999999%
of the cases the string will be smaller than 2GB...

Now the problem:

Since I warn each time a narrowing conversion is done (since
that could loose data) I end up with hundreds of warnings each time
a construct like int a = strlen(...) appears. This clutters
everything, and important warnings go lost.
I do not know how to get out of this problem. Maybe any of you has
a good idea? How do you solve this when porting to 64 bits?

jacob
Aug 29 '07
409 9584
On 2007-09-01 20:28, Malcolm McLean <re*******@btinternet.comwrote:
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...
>and the admission of long, double, long long or any other type.

Let's face it, admitting types to C was a mistake.
We should go back to B.
The campaign for 64 bit ints wants int to be 64 bits.
I think somebody's irony detector needs adjusting.
You've still got the problem of real numbers of course. The existence of two
and now three formats creates inefficiencies enough. But at least we'll have
^^^

Now? "long double" exists at least since C89. I think some pre-ANSI
compilers I used had it, too. Oh, I forgot. You are the guy who knows
that C in hundred years will look like C 30 years ago, and everything
added in between is just a short-lived fashion which will eventually be
removed again.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 1 '07 #201
Martin Wells wrote:
>
>>IMO, any decent compiler should issue truncation warnings.
>Do you know of a "decent compiler" that does?


gcc.
Nope, your example compiles cleanly without the cast with -Wall -ansi
-pedantic

--
Ian Collins.
Sep 1 '07 #202
On the larger issue of "write portable code in the first place",
Martin Wells and Craig Gullixson are correct (in my opinion) and
I will not add more than that.

On the specifics of mixing signed and unsigned...

In article <11**********************@m37g2000prh.googlegroups .com>,
Bart <bc@freeuk.comwrote, in part:
>Signed/unsigned numbers have different ranges. Why is it a big deal to
compare these two types of values? Is it because one type can store a
value that does not exist in the other? That's also a problem with
short and long ints. Anyway the solution can be simple, such as
converting the numbers into a type that accommodates both ranges.
Indeed.

I think the "big deal" is that people get confused about the
possible problems. It helps, I think, to take a step or two
back and think about the actual inputs.

Suppose that you have two variables denoted "x" and "y", which
have differing types, but which are otherwise comparable with
relational operators.

The possible range for x is X_MIN to X_MAX, and the possible
range for y is Y_MIN to Y_MAX.

If there is a common type Z, for which numbers in X_MIN to X_MAX
and Y_MIN to Y_MAX always fit within Z_MIN to Z_MAX, then the
C code:

(Z)x < (Z)y

suffices. For example, if x and y are "signed char" and "unsigned
char" respectively, and we can be reasonably sure that INT_MAX meets
or exceeds UCHAR_MAX, then a simple:

(int)x < (int)y

suffices. If x is near SCHAR_MIN, say -125, and y is a value such
as (say) 200, we just get -125 < 200, which is true.

If there is no such common type -- for instance, if the type for
x is "signed long long" and the type for y is "unsigned long long"
-- then we have a *slightly* thornier problem. In this particular
case, we must decide whether negative values of "x" are less than
all values of "y". If so:

x < 0 || (unsigned long long)x < y

will do the trick. Even if x is near LLONG_MIN, so that forcing
x to "unsigned long long" produces a number very near ULLONG_MAX,
the first test takes care of the problem.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Sep 1 '07 #203
Mark McIntyre wrote:
On Sat, 01 Sep 2007 20:51:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific stuff.
2) Any notion of the keyboard. To handle the keyboard you need system
specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

So? in any typical application, all the above interface specific stuff
can (and should) be separated from the meat of the programme.
Um, I've just finished a little application to interface to a serial
port through a socket (make it look like an Ethernet to serial adapter).
I think there might be a portable line or two (the argument checking),
but the bulk is target specific. That's not uncommon for system code.

--
Ian Collins.
Sep 1 '07 #204

"Ian Collins" <ia******@hotmail.comwrote in message
news:5j************@mid.individual.net...
Mark McIntyre wrote:
>On Sat, 01 Sep 2007 20:51:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific stuff.
2) Any notion of the keyboard. To handle the keyboard you need system
specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

So? in any typical application, all the above interface specific stuff
can (and should) be separated from the meat of the programme.
Um, I've just finished a little application to interface to a serial
port through a socket (make it look like an Ethernet to serial adapter).
I think there might be a portable line or two (the argument checking),
but the bulk is target specific. That's not uncommon for system code.
IO is hardware dependent, the rest is not.
I call subroutines that do IO "procedures" and those that don't "functions".
I know these words are used in other ways by other people.
I give my procedures capital letters, and keep the functions in lower case.
Everything in lower case is portable. Except main(), of course, as Richard
Heathfield once pointed out.
(This system isn't used on the website or book. stdio IO is also in
lowercase, because it is reasonably portable).

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 1 '07 #205
Malcolm McLean wrote, On 01/09/07 20:04:
>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...
>Ed Jensen wrote:
And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

It is easy to play the guru here. More difficult in reality.
It is also a lot easier to find errors in books than to write one.
It is even harder to write a good book.
Having been through the same process I won't criticise Heathfield too
much. They can creep in during formatting as well as in development and
testing. My book had some errors as well.
I just checked and your book STILL has errors since it has not been
updated. Please you the correct tense. Unless, of course, you are
deliberately trying to mislead.
--
Flash Gordon
Sep 1 '07 #206
Flash Gordon <sp**@flash-gordon.me.ukwrites:
Malcolm McLean wrote, On 01/09/07 20:04:
>>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr.. .
>>Ed Jensen wrote:
And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

It is easy to play the guru here. More difficult in reality.
It is also a lot easier to find errors in books than to write one.

It is even harder to write a good book.
You really are quite a nasty person.
>Having been through the same process I won't criticise Heathfield
too much. They can creep in during formatting as well as in
development and testing. My book had some errors as well.

I just checked and your book STILL has errors since it has not been
updated. Please you the correct tense. Unless, of course, you are
deliberately trying to mislead.
I suspect he will do it in his good time.
Sep 2 '07 #207
On Sun, 02 Sep 2007 09:19:51 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>Um, I've just finished a little application to interface to a serial
port through a socket (make it look like an Ethernet to serial adapter).
I think there might be a portable line or two (the argument checking),
but the bulk is target specific. That's not uncommon for system code.
*shrugs*.
System code is by, um, definition, system-specific. You can't write it
in C. I'm not sure where you're going with this - are you suggesting
that C should include a superset of all possible system-specific
interfaces? If so, feel free to write that library and propose it to
the Committee.

--
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
Sep 2 '07 #208
Mark McIntyre wrote:
On Sun, 02 Sep 2007 09:19:51 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>Um, I've just finished a little application to interface to a serial
port through a socket (make it look like an Ethernet to serial adapter).
I think there might be a portable line or two (the argument checking),
but the bulk is target specific. That's not uncommon for system code.

*shrugs*.
System code is by, um, definition, system-specific. You can't write it
in C.
Oh it's C all right, it just uses system specific libraries.

There's nothing "not C" about "unsigned s = read( buffer, size);" for a
given definition of read.

Calling system specific functions does not prevent code from being C.

--
Ian Collins.
Sep 2 '07 #209
Martin Wells wrote:
CBFalconer:
>>size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}

AFAICS this has the same action as strlen.

Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all
zeros. It's a hell of a lot faster than using a canonical loop.
Well, I wasn't clear. I meant as a black box, not as to code.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #210
Martin Wells <wa****@eircom.netwrote:
>Writing extremely portable code IS easy, just not in C.

Now you're just preaching about your own incompetence. Sorry to sound
hostile, but it's the truth.
Don't worry about it, Martin. To be honest, I was expecting that kind
of response much sooner. It's just sort of the...personality...of
this newsgroup. Since I've been online since about 1979, I've had
ample time to marvel at this kind of fascinating emergent behavior in
online communities.

There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial. People get awfully
religious about strange things, even computer programming languages.
Your religion of choice is C. Hey, that's cool.

Therefore, I knew before I walked down this path, that the response
would ultimately be, "The problem can't possibly be that it's
non-trivial to write 100% portable C code; the problem must be you."
I've seen the denizens of comp.lang.c use this response on several
people. Why should I be immune?

But, instead of pointless and unfounded insults, let's try a real
world test for a change. You paste one or two thousand lines of C
code you've written from your most recent project, and we'll see if
anyone on the newsgroup can identify any code that's not 100% portable
C code.

Since you've made the claim that writing 100% portable C code isn't
just easy, but VERY easy, I'm quite sure you're up to the challenge.
It's time to put your code where your mouth is.

And while we're on the topic, I'd like to present a little poll: Is
there anyone else here that agrees with Martin when he says that
writing 100% portable C code is VERY easy? Keep in mind the question
isn't whether or not it's possible or desirable, just whether or not
it's VERY easy.
Sep 2 '07 #211
>Martin Wells <wa****@eircom.netwrote:
>Writing extremely portable code IS easy, just not in C.
In article <13*************@corp.supernews.com>
Ed Jensen <ej*****@visi.comwrote [in part, and one insertion of
mine in brackets below]:
>There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial. ...

Since you've made the claim that writing 100% portable C code isn't
just easy, but [in a later post that is not quoted above] VERY easy ...

... I'd like to present a little poll: Is
there anyone else here that agrees with Martin when he says that
writing 100% portable C code is VERY easy?
I would say "often easy enough, rarely VERY easy", although of
course the precise meaning of "enough" and "VERY" is tough to
pin down.

Furthermore, the easy-ness of portability varies with the goal of
the code. Clearly, something like "calculate mortgage payments"
or "concatenate files specified by argv[] elements" is going to be
easier than "write an operating system" or "do bitmapped graphics":
the latter two *require* at least *some* non-portable code.

The trick in this case is to know when to make the tradeoff -- but
this in turn requires being able to write portable code (or even
"extremely" or "100%" portable code, whatever that may mean :-) )
in the first place. That, of course, requires knowing what is
portable, i.e., at least some degree of study of Standard C. This
is where the comp.lang.c newsgroup comes in: here in comp.lang.c,
you can find out what is "portable", or how to take any given chunk
of code with "not very portable" parts and rewrite it to have large
"portable parts", and thus learn when to make tradeoffs.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Sep 2 '07 #212
Richard Tobin wrote:
>
In article <46***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:
int aone[10];
int *const atwo = &aone[3];
(&aone[3]) is the address of an object of type int.

I realise this is just pedantry, but who can complain?

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.

N869
6.3.2.3 Pointers
[#7] A pointer to an object or incomplete type may be
converted to a pointer to a different object or incomplete
type. If the resulting pointer is not correctly aligned
for the pointed-to type, the behavior is undefined.

--
pete
Sep 2 '07 #213
jacob navia wrote:
>
.... snip ...
>
Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific
stuff.
2) Any notion of the keyboard. To handle the keyboard you need
system specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

C is very popular for systems programming but none of those programs
is written in standard C.
Utter rubbish. Most good systems programs are written in as
standard a form as is available of their language. Some may have a
system specific GUI add-on. Some (such as an IDE) may be a
combination of several standard programs with GUI interface. Some
(such as an editor) may require special keyboard input (system
specific).

.... snip ...
>
All this people talking about "Portable standard C" are just talking
nonsense. Or they do not use the network, nor do they do any
graphics, nor do they use any i/o, etc etc.

Yes, for toy applications it is barely portable, but even this program:

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

is portable since the errors of printf are NOT specified, so you
have no way to know what happened if printf returns a negative
result, besides going into implementation specific stuff!
Purely because the writer was too lazy to write the program
'correctly'. As shown it contains at least two serious errors -
failure to return status, 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;
}

BTW, systems have various possibilities of returning details on
printf errors, such as ferror and perror. See the standard. There
is a value known as QOI attached to most implementations.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #214
Joe Wright wrote:
>
.... snip ...
>
I suppose you don't like '#define strlen Strlen'. It has the effect
of removing a reference to a standard library function and replacing
it with the name of a local function before compilation. Harmless.
Possibly so on your present system. However, according to the C
standard, any such redefinition of standard library facilities
leads to undefined behaviour. Note that that behaviour may be
exactly what you want and expected. It doesn't have to be such.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #215
Ed Jensen wrote:
>
.... snip ...
>
And while we're on the topic, I'd like to present a little poll:
Is there anyone else here that agrees with Martin when he says
that writing 100% portable C code is VERY easy? Keep in mind the
question isn't whether or not it's possible or desirable, just
whether or not it's VERY easy.
It all depends on the mindset. If you've been writing portable
code, you have the habit, and the unusual thing is non-portable
code. And the inverse also applies, and unfortunately is the more
common situation.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #216
Ed Jensen said:
Martin Wells <wa****@eircom.netwrote:
>>Writing extremely portable code IS easy, just not in C.

Now you're just preaching about your own incompetence. Sorry to sound
hostile, but it's the truth.

Don't worry about it, Martin. To be honest, I was expecting that kind
of response much sooner. It's just sort of the...personality...of
this newsgroup. Since I've been online since about 1979, I've had
ample time to marvel at this kind of fascinating emergent behavior in
online communities.

There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.
I'm one of them, however.

I think it's easy to write *very* portable code, but difficult to write
100% portable code. Consider, for example, this simple program:

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main(int argc, char **argv)
{
int rc = EXIT_SUCCESS;
unsigned long fa[UCHAR_MAX + 1] = {0};
int ch = 0;
size_t i = 0;
FILE *fp = argc 1 ? fopen(argv[1], "rb") : NULL;
if(fp != NULL)
{
while((ch = getc(fp)) != EOF)
{
++fa[ch];
}
fclose(fp);
if(ferror(fp))
{
fputs("Input error.\n", stderr);
rc = EXIT_FAILURE;
}
else
{
for(i = 0; i < sizeof fa / sizeof fa[0]; i++)
{
if(fa[i] 0)
{
printf("%lu: %lu\n", (unsigned long)i, fa[i]);
}
}
}
}
else
{
fputs("Can't open input file.\n", stderr);
rc = EXIT_FAILURE;
}
return rc;
}

This will work (I have tested it, so I know that it will at least
compile!) on Linux. It will work on Windows. With appropriate JCL,
it'll work on a mainframe. It will work on an Atari ST or an Amiga.
It'll work on MS-DOS. I see no reason why it wouldn't work on a Cray.
It'll work on lots of platforms, in fact.

It'll even work on a Mac - or will it? If not, why not?

And on what other platforms will it not work? And for what reasons? The
code /looks/ portable - but there are more problems in the code than
are immediately obvious to the eye.

I can see - well, several, at any rate! :-)

<snip>
And while we're on the topic, I'd like to present a little poll: Is
there anyone else here that agrees with Martin when he says that
writing 100% portable C code is VERY easy? Keep in mind the question
isn't whether or not it's possible or desirable, just whether or not
it's VERY easy.
It depends on the code. It's often possible but not always. It's always
desirable, but not necessarily the most significant requirement. *Some*
code is indeed very easy to write portably.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 2 '07 #217
Richard Heathfield wrote:
Ed Jensen said:
>Martin Wells <wa****@eircom.netwrote:
>>>Writing extremely portable code IS easy, just not in C.

Now you're just preaching about your own incompetence. Sorry to sound
hostile, but it's the truth.

Don't worry about it, Martin. To be honest, I was expecting that kind
of response much sooner. It's just sort of the...personality...of
this newsgroup. Since I've been online since about 1979, I've had
ample time to marvel at this kind of fascinating emergent behavior in
online communities.

There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.

I'm one of them, however.

I think it's easy to write *very* portable code, but difficult to write
100% portable code. Consider, for example, this simple program:

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main(int argc, char **argv)
{
int rc = EXIT_SUCCESS;
unsigned long fa[UCHAR_MAX + 1] = {0};
int ch = 0;
size_t i = 0;
FILE *fp = argc 1 ? fopen(argv[1], "rb") : NULL;
if(fp != NULL)
{
while((ch = getc(fp)) != EOF)
{
++fa[ch];
}
fclose(fp);
if(ferror(fp))
{
fputs("Input error.\n", stderr);
rc = EXIT_FAILURE;
}
else
{
for(i = 0; i < sizeof fa / sizeof fa[0]; i++)
{
if(fa[i] 0)
{
printf("%lu: %lu\n", (unsigned long)i, fa[i]);
}
}
}
}
else
{
fputs("Can't open input file.\n", stderr);
rc = EXIT_FAILURE;
}
return rc;
}

This will work (I have tested it, so I know that it will at least
compile!) on Linux. It will work on Windows. With appropriate JCL,
it'll work on a mainframe. It will work on an Atari ST or an Amiga.
It'll work on MS-DOS. I see no reason why it wouldn't work on a Cray.
It'll work on lots of platforms, in fact.

It'll even work on a Mac - or will it? If not, why not?

And on what other platforms will it not work? And for what reasons? The
code /looks/ portable - but there are more problems in the code than
are immediately obvious to the eye.

I can see - well, several, at any rate! :-)
I can see one very obvious one: you're using a file after closing it. That's
not the way you should be writing code even if it's not meant to be
portable.

I can see one more potential problem, but it doesn't explain why you think
it might not work on a Mac. Could you give a hint?
Sep 2 '07 #218
Harald van D?k said:
Richard Heathfield wrote:
<snip>
>It'll even work on a Mac - or will it? If not, why not?

And on what other platforms will it not work? And for what reasons?
The code /looks/ portable - but there are more problems in the code
than are immediately obvious to the eye.

I can see - well, several, at any rate! :-)

I can see one very obvious one: you're using a file after closing it.
That's not the way you should be writing code even if it's not meant
to be portable.
Oh, stupid stupid stupid (me, not you). You're right, of course. That
was unintentional, by the way!
I can see one more potential problem, but it doesn't explain why you
think it might not work on a Mac. Could you give a hint?
I've never owned a Mac, nor executed my own code on own, so I'm going on
rumour and supposition, but it is my understanding that, on at least
*some* Mac implementations, argc is always 0, so the program will run,
but with unsatisfactory results.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 2 '07 #219
CBFalconer wrote:
jacob navia wrote:
... snip ...
>Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific
stuff.
2) Any notion of the keyboard. To handle the keyboard you need
system specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

C is very popular for systems programming but none of those programs
is written in standard C.

Utter rubbish. Most good systems programs are written in as
standard a form as is available of their language. Some may have a
system specific GUI add-on. Some (such as an IDE) may be a
combination of several standard programs with GUI interface. Some
(such as an editor) may require special keyboard input (system
specific).

... snip ...
>All this people talking about "Portable standard C" are just talking
nonsense. Or they do not use the network, nor do they do any
graphics, nor do they use any i/o, etc etc.

Yes, for toy applications it is barely portable, but even this program:

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

is portable since the errors of printf are NOT specified, so you
have no way to know what happened if printf returns a negative
result, besides going into implementation specific stuff!

Purely because the writer was too lazy to write the program
'correctly'. As shown it contains at least two serious errors -
failure to return status,
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.
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;
}

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

That was precisely my point. How do you know what happened?
What error? You have to be system specific!

jacob
Sep 2 '07 #220
On Sun, 02 Sep 2007 12:20:03 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Oh it's C all right, it just uses system specific libraries.
Pardon me, I should have said "in standard C, the topic of this
newsgroup"
>Calling system specific functions does not prevent code from being C.
Some would disagree.
--
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
Sep 2 '07 #221

"Ian Collins" <ia******@hotmail.comwrote in message
news:5j*************@mid.individual.net...
>
There's nothing "not C" about "unsigned s = read( buffer, size);" for a
given definition of read.

Calling system specific functions does not prevent code from being C.
No, but we don't know what the code does.
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 2 '07 #222
On Sun, 02 Sep 2007 10:10:14 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>CBFalconer wrote:
>jacob navia wrote:
... snip ...
>>#include <stdio.h>
int main(void){printf("hello\n");}
As shown it contains at least two serious errors -
failure to return status,

As specified in the C standard, main returns zero, and it is not
necessary to write a return statement.
True in C99, but not in the widely-implemented and still widely used
C89. Compilers conforming to that standard will emit garbage and can
(and do) upset their host environments.

--
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
Sep 2 '07 #223
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5j*************@mid.individual.net...
>>
There's nothing "not C" about "unsigned s = read( buffer, size);" for a
given definition of read.

Calling system specific functions does not prevent code from being C.
No, but we don't know what the code does.
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.
#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?

--
Ian Collins.
Sep 2 '07 #224
Martin Wells wrote:
CBFalconer:
>>size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}
AFAICS this has the same action as strlen.


Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all zeros.
It's a hell of a lot faster than using a canonical loop.

Martin
To do that, it has to find an address multiple of four.
Since strings aren't naturally aligned (they could start at
ANY address) it has to make a few comparisons before finding the
right starting address. This means more setup time.

For strings with length less than 80-100 this, together with the
function call, will kill any performance improvements.

When using the optimizer, lcc-win32 generates an inline loop
of 4-5 assembler instructions, comparing character by
character. For relatively short strings, this will beat
any strlen function since the overhead of the function call
is much greater...

Sep 2 '07 #225
Ed Jensen wrote
There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.
Then,Richard Heathfield answered:
I'm one of them, however.
I think it's easy to write *very* portable code, but difficult to write
100% portable code. Consider, for example, this simple program:
[code snipped]

Harald van Dijk answered:
>I can see one very obvious bug: you're using a file after closing it.
That's not the way you should be writing code even if it's not meant
to be portable.
And heathfield had to acknowledge...
Oh, stupid stupid stupid (me, not you). You're right, of course. That
was unintentional, by the way!

Ahh the "regulars" here. Always the pompous claims but then, they
present a few lines of code with such an OBVIOUS bug!
jacob
Sep 2 '07 #226
jacob navia <ja***@jacob.remcomp.frwrites:
Martin Wells wrote:
>CBFalconer:
>>>size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}
AFAICS this has the same action as strlen.
Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all zeros.
It's a hell of a lot faster than using a canonical loop.

To do that, it has to find an address multiple of four.
Since strings aren't naturally aligned (they could start at
ANY address) it has to make a few comparisons before finding the
right starting address. This means more setup time.

For strings with length less than 80-100 this, together with the
function call, will kill any performance improvements.

When using the optimizer, lcc-win32 generates an inline loop
of 4-5 assembler instructions, comparing character by
character. For relatively short strings, this will beat
any strlen function since the overhead of the function call
is much greater...
There's no reason it couldn't do exactly the same thing for an
explicit call to strlen().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 2 '07 #227
Malcolm McLean wrote:
"Harald van D?k" <tr*****@gmail.comwrote in message
news:fb**********@news5.zwoll1.ov.home.nl...
>Richard Heathfield wrote:

I can see one more potential problem, but it doesn't explain why you
think it might not work on a Mac. Could you give a hint?
The Mac supports every character knwon to man.
So UCHAR_MAX is 0xFFFFFFFFFFFFFFFF
No, that's not the case on Macs, and while I realise there are some real
systems that have a 64-bit char, it is my understanding that they are
freestanding implementations which do not use the standard I/O functions.
(I would appreciate details on implementations with 64-bit char and
<stdio.h>, though.)
Sep 2 '07 #228
jacob navia <ja***@jacob.remcomp.frwrites:
Ed Jensen wrote
>There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.

Then,Richard Heathfield answered:
>I'm one of them, however.
>I think it's easy to write *very* portable code, but difficult to write
100% portable code. Consider, for example, this simple program:

[code snipped]

Harald van Dijk answered:
>>I can see one very obvious bug: you're using a file after closing it.
That's not the way you should be writing code even if it's not meant
to be portable.

And heathfield had to acknowledge...
>Oh, stupid stupid stupid (me, not you). You're right, of
course. That was unintentional, by the way!


Ahh the "regulars" here. Always the pompous claims but then, they
present a few lines of code with such an OBVIOUS bug!
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.

Incidentally, you recently claimed that "C Unleashed" contains some
code that assumes sizeof(int) == sizeof(int*). Can you be more
specific? I'm sure the authors would like to know about it. I think
Richard Heathfield has you killfiled; if you'll post the specifics,
I'll re-post for his benefit.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 2 '07 #229
Richard Heathfield wrote:
Harald van D?k said:
>I can see one more potential problem, but it doesn't explain why you
think it might not work on a Mac. Could you give a hint?

I've never owned a Mac, nor executed my own code on own, so I'm going on
rumour and supposition, but it is my understanding that, on at least
*some* Mac implementations, argc is always 0, so the program will run,
but with unsatisfactory results.
Oh, thanks for the explanation. That's not the case with OS X, though it may
well be true for some of the implementations for older systems.
Sep 2 '07 #230

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 2 '07 #231
On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>#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
Sep 2 '07 #232
Mark McIntyre wrote:
On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>#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".

--
Ian Collins.
Sep 2 '07 #233
Ian Collins wrote:
Mark McIntyre wrote:
>On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>>#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.
Sep 2 '07 #234
Harald van Dijk wrote:
Ian Collins wrote:
>Mark McIntyre wrote:
>>On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

#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.

--
Ian Collins.
Sep 2 '07 #235
Keith Thompson said:
jacob navia <ja***@jacob.remcomp.frwrites:
<snip>
>Ahh the "regulars" here. Always the pompous claims but then, they
present a few lines of code with such an OBVIOUS bug!

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 Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 2 '07 #236

"Mark McIntyre" <ma**********@spamcop.netwrote in message
news:g3********************************@4ax.com...
On Sun, 02 Sep 2007 20:38:04 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>>#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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 2 '07 #237

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6e******************************@bt.com...
>
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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 2 '07 #238
Mark McIntyre <ma**********@spamcop.netwrites:
On Sun, 02 Sep 2007 12:20:03 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>>Oh it's C all right, it just uses system specific libraries.

Pardon me, I should have said "in standard C, the topic of this
newsgroup"
>>Calling system specific functions does not prevent code from being C.

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.
Sep 2 '07 #239
"Malcolm McLean" <re*******@btinternet.comwrites:
"Ian Collins" <ia******@hotmail.comwrote in message
news:5j*************@mid.individual.net...
>>
There's nothing "not C" about "unsigned s = read( buffer, size);" for a
given definition of read.

Calling system specific functions does not prevent code from being C.
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.
Sep 2 '07 #240
Malcolm McLean said:
>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6e******************************@bt.com...
>>
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.
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 Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 2 '07 #241
In article <46***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:
>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?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 2 '07 #242
Malcolm McLean wrote:
>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...
>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.
Having 'fclose(fp);' the value of fp becomes indeterminate. Subsequent
use of it is undefined.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Sep 2 '07 #243
Richard Tobin wrote:
>
In article <46***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:
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.

--
pete
Sep 2 '07 #244
pete wrote:
>
Richard Tobin wrote:

In article <46***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:
>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.

--
pete
Sep 2 '07 #245
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5j************@mid.individual.net...
>Mark McIntyre wrote:
>>On Sat, 01 Sep 2007 20:51:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific
stuff. 2) Any notion of the keyboard. To handle the keyboard you need
system
specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

So? in any typical application, all the above interface specific stuff
can (and should) be separated from the meat of the programme.
Um, I've just finished a little application to interface to a serial
port through a socket (make it look like an Ethernet to serial adapter).
I think there might be a portable line or two (the argument checking),
but the bulk is target specific. That's not uncommon for system code.
IO is hardware dependent, the rest is not.
Also other things. Exceptions, privileged instructions, debugging etc.

Sep 2 '07 #246
Malcolm McLean wrote:
>
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...
>On 2007-09-01 19:25, Malcolm McLean <re*******@btinternet.comwrote:

By that kind of reasoning a snail is about as fast as a jet.
The snail, going West, is moving towards the Andromeda galaxy at
50.000001 km/s. The jet, going East, is moving towards Andromeda at
about 49.660 km/s, assuming it's a Concorde.
That was a fast snail! :)

AFAIK, M31 is closing in on the Sun at 300 km/s, and on Milky Way at 100
km/s, so how did you arrive at ca. 50 km/s?
Rolling your own standard functions, is usually a bad idea, in
particularly when the replacement is *much* slower.

--
Tor <torust [at] online [dot] no>
Sep 2 '07 #247
Ian Collins wrote:
Mark McIntyre wrote:
>Ian Collins <ia******@hotmail.comwrote:
>>#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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #248
jacob navia wrote:
CBFalconer wrote:
>jacob navia wrote:

... snip ...
>>Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific
stuff.
2) Any notion of the keyboard. To handle the keyboard you need
system specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

C is very popular for systems programming but none of those
programs is written in standard C.

Utter rubbish. Most good systems programs are written in as
standard a form as is available of their language. Some may have
a system specific GUI add-on. Some (such as an IDE) may be a
combination of several standard programs with GUI interface.
Some (such as an editor) may require special keyboard input
(system specific).

... snip ...
>>>
#include <stdio.h>
int main(void){printf("hello\n");}

is portable since the errors of printf are NOT specified, so you
have no way to know what happened if printf returns a negative
result, besides going into implementation specific stuff!

Purely because the writer was too lazy to write the program
'correctly'. As shown it contains at least two serious errors -
failure to return status,

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #249
Ian Collins wrote:
>
.... 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?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 2 '07 #250

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Steffen Fiksdal | last post: by
17 posts views Thread by candy_init | last post: by
5 posts views Thread by edware | last post: by
12 posts views Thread by Alex Vinokur | last post: by
23 posts views Thread by bwaichu | last post: by
318 posts views Thread by jacob navia | last post: by
73 posts views Thread by Yevgen Muntyan | last post: by
89 posts views Thread by Tubular Technician | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.