size_t problems

[Richard Tobin]

Re: size_t problems

In article <46D92392.3E1D@ mindspring.com> ,
pete <pfiland@mindsp ring.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];

and if so, what is the type of *atwo? And is not (*atwo)[-1] legal?

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Re: size_t problems

Malcolm McLean wrote:

>

.... snip ...

>
The other possibility is that the committee will have its way, and
we've all got to write size_t for practically every array index.
This makes C a difficult language, OK for the specialist, but not
very good for beginner use. So it is no longer a good choice for a
beginning book. Either use a different language, or use a cut down,
simplified version of the existing language, with a note to say
what you've done.

You don't type an array index because it's indexing an array. You
type it according to the values it has to hold. Similarly for
anything else. If an index has to hold any value returned from
strlen (which is a size_t) then it must be a size_t. If it has to
hold "sizeof double" it can be a char, a short, an int, a long, or
a size_t, and unsigned versions of all. I don't think anyone will
take you to task for assuming "sizeof double" is no larger than
127.

If you had ever had the training of using Pascal correctly, you
would be aware of this. There you first type the variable that
indexes an array (lower and upper bounds). Then you build an array
indexed by that type. Now the error detection will catch you
anytime you exceed the preset bounds in the index, and use of the
index involves no checks.

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

[Joe Wright]

Re: size_t problems

Richard Heathfield wrote:

CBFalconer said:
>

>jacob navia wrote:
>... snip ...

>>Just
>>>
>>int Strlen_i(char *s)
>>{
>> char *start=s;
>> while (*s)
>> s++;
>> return s-start;
>>}
>>#define strlen Strlen_i;

>At which point your code has undefined behaviour.

>
No, at which point his code won't even compile.
>

>Please read the standard some day.

>
I think he should start with something a little easier to understand.
>

This compiles just fine for me.

#include <stdio.h>

size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}

#define strlen Strlen

int main(void) {
char line[80] = "Are you kidding me?";
printf("The length of string \"%s\" is %d bytes.\n",
line, (int)strlen(lin e));
return 0;
}

Is there anything wrong with it?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

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

Re: size_t problems

Joe Wright wrote:

This compiles just fine for me.
>
#include <stdio.h>
>
size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}
>
#define strlen Strlen
>
int main(void) {
char line[80] = "Are you kidding me?";
printf("The length of string \"%s\" is %d bytes.\n",
line, (int)strlen(lin e));
return 0;
}
>
Is there anything wrong with it?

No, ignoring style, there is nothing wrong with it, as long as <string.his
not included.

[Richard Heathfield]

Re: size_t problems

<much snippage>

Joe Wright said:

Richard Heathfield wrote:

>CBFalconer said:

>>jacob navia wrote:
>>>#define strlen Strlen_i;
>>At which point your code has undefined behaviour.

>>
>No, at which point his code won't even compile.
>>

>>Please read the standard some day.

>>
>I think he should start with something a little easier to understand.
>>

This compiles just fine for me.

Look at his code more closely. Much more closely. Vewy vewy cwosewy, in
fact. I have re-quoted the relevant line.

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

[Joe Wright]

Re: size_t problems

Richard Heathfield wrote:

<much snippage>
>
Joe Wright said:

>Richard Heathfield wrote:

>>CBFalconer said:
>>>jacob navia wrote:
>>>>#define strlen Strlen_i;
>>>At which point your code has undefined behaviour.
>>No, at which point his code won't even compile.
>>>
>>>Please read the standard some day.
>>I think he should start with something a little easier to understand.
>>>

>This compiles just fine for me.

>
Look at his code more closely. Much more closely. Vewy vewy cwosewy, in
fact. I have re-quoted the relevant line.
>

I see it (;) now. The admonishment to compile even your snippets before
posting is valid.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Joe Wright]

Re: size_t problems

Harald van Dijk wrote:

Joe Wright wrote:

>This compiles just fine for me.
>>
>#include <stdio.h>
>>
>size_t Strlen(char *s) {
> char *p = s;
> if (p) while (*p) p++;
> return p - s;
>}
>>
>#define strlen Strlen
>>
>int main(void) {
> char line[80] = "Are you kidding me?";
> printf("The length of string \"%s\" is %d bytes.\n",
> line, (int)strlen(lin e));
> return 0;
>}
>>
>Is there anything wrong with it?

>
No, ignoring style, there is nothing wrong with it, as long as <string.his
not included.

Style? Anyway, what changes if I include <string.hafte r <stdio.hand
before #define strlen Strlen ?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

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

Re: size_t problems

Joe Wright wrote:

Harald van Dijk wrote:

>Joe Wright wrote:

>>This compiles just fine for me.
>>>
>>#include <stdio.h>
>>>
>>size_t Strlen(char *s) {
>> char *p = s;
>> if (p) while (*p) p++;
>> return p - s;
>>}
>>>
>>#define strlen Strlen
>>>
>>int main(void) {
>> char line[80] = "Are you kidding me?";
>> printf("The length of string \"%s\" is %d bytes.\n",
>> line, (int)strlen(lin e));
>> return 0;
>>}
>>>
>>Is there anything wrong with it?

>>
>No, ignoring style, there is nothing wrong with it, as long as <string.h>
>is not included.

>
Style?

Defining your own functions with the same name as standard library functions
or macros is not something I would ever consider good style. Not even the
times when it's allowed and actually useful.

Anyway, what changes if I include <string.hafte r <stdio.hand
before #define strlen Strlen ?

If <string.halread y defines strlen as a macro, you will get a complaint
from your compiler that you're redefining the macro. If you make sure to
use #undef first, the behaviour is undefined.

[jacob navia]

Re: size_t problems

Joe Wright wrote:

Richard Heathfield wrote:

><much snippage>
>>
>Joe Wright said:

>>Richard Heathfield wrote:
>>>CBFalconer said:
>>>>jacob navia wrote:
>>>>>#define strlen Strlen_i;
>>>>At which point your code has undefined behaviour.
>>>No, at which point his code won't even compile.
>>>>
>>>>Please read the standard some day.
>>>I think he should start with something a little easier to understand.
>>>>
>>This compiles just fine for me.

>>
>Look at his code more closely. Much more closely. Vewy vewy cwosewy,
>in fact. I have re-quoted the relevant line.
>>

I see it (;) now. The admonishment to compile even your snippets before
posting is valid.
>

I do not think so.

Snippets are intended for people, not machines. Besides this, that guy
can only be satisfied with things like that:
missing semicolons, missing this or that.

[Martin Wells]

Re: size_t problems

Malcolm McLean:

Yes. But psychological factors are also important. If an index variable is
called "size" then of course the compiler will happily chug through and
index the array by variable "size". However to anyone reading the program it
is intensely irritating.

typedef size_t index_t;

Martin

[Martin Wells]

Re: size_t problems

Ian Collins:

In the little snippet I wrote just above, I'd only write a comment
with it if my target audience only started programming yesterday at 3
O'Clock.

>
That's because it can be written without the cast.

The cast is there to suppress a compiler warning. Anyway it seems we
disagree fundamentally on this so I don't think there's much point in
discussing it, other than a constant "I like cast" reply to "I don't
like cast".

>IMO, any decent compiler should issue truncation warnings.

Do you know of a "decent compiler" that does?

gcc.

Martin

[Martin Wells]

Re: size_t problems

jacob navia:

Look, it is not the C standard that runs my code.
>
It is a mindless processor, churning instruction after instruction, no
mind no standards, no nothing.
>
I have an aesthetic view of code. What is important in it, from my
viewpoint, is clarity of design and above all, that
IT WORKS.

There is a price to be paid for this: Lack of portability.

You are now paying that price, and the headache you now suffer is the
fruit of your own actions.

Portability seems to be a key issue on this newsgroup, which is why
you aren't getting the replies you desire.

Martin

[Martin Wells]

Re: size_t problems

Malcolm McLean

Two things will happen.
Probably there will be a howl of protest as desktop programs move from 32 to
64 bits, and the implications of size_t being no longer the same size as an
int (give or take a sign bit) become obvious. So something will be done, and
people will look at code saying size_t i and say "Oh, that garbage the
committee inisted on back in 2007? What obsolete code."
>
The other possibility is that the committee will have its way, and we've all
got to write size_t for practically every array index. This makes C a
difficult language, OK for the specialist, but not very good for beginner
use. So it is no longer a good choice for a beginning book. Either use a
different language, or use a cut down, simplified version of the existing
language, with a note to say what you've done.

Am I the only one who doesn't acknowledge any problems when moving
from 32-Bit to 64-Bit? That is to say, am I the only one who's being
using size_t properly?

Someone please tell me why it's so difficult to use size_t in the
following fashion:

#include <stddef.h>

void AddFiveToEachEl ement(int *p,size_t len)
{
while (len--) *p++ += 5;
}

If you throw portability out the window, as jacob navia has done, then
you are ASKING FOR THESE PROBLEMS. You're lighting a fuse... it may be
a very long fuse, but it eventually will go off.

Martin

[Martin Wells]

Re: size_t problems

Ed Jensen:

1. Writing 100% portable code. This can be non-trivial and really
slow down your development. (However, I'm sure writing 100% portable
code doesn't slow down any of the geniuses HERE. I'm talking strictly
about MORTAL developers.)

I don't consider myself to be an Einstein by any stretch of the
imagination, but still I've no problem keeping my code portable.
Likely reason being that I focused on that fashion of programming
rather than played around with int's all the time.

"Well, just write your C code so it's 100% portable in the first
place. Easy! Problem solved! Only dummies don't do that!"

Writing portable code is really a hell of a lot easier, and even a
hell of a lot more satisfying, than you make it sound.

Martin

[CBFalconer]

Re: size_t problems

Joe Wright wrote:

>
Richard Heathfield wrote:

CBFalconer said:

jacob navia wrote:
... snip ...
>Just
>>
>int Strlen_i(char *s)
>{
> char *start=s;
> while (*s)
> s++;
> return s-start;
>}
>#define strlen Strlen_i;
At which point your code has undefined behaviour.

No, at which point his code won't even compile.

Please read the standard some day.

I think he should start with something a little easier to understand.

This compiles just fine for me.
>
#include <stdio.h>
>
size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}

AFAICS this has the same action as strlen.

>
#define strlen Strlen

This leads to undefined behaviour.

int main(void) {
char line[80] = "Are you kidding me?";
printf("The length of string \"%s\" is %d bytes.\n",
line, (int)strlen(lin e));
return 0;
}
>
Is there anything wrong with it?

Yes. See above.

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