string to integer
KJ
void main()
{
int a[10];
printf("enter string ");
scanf("%s",a);
printf("%s",a);
}
its a simple program written in msdos turbo c++ version 3.0, by
convention this program should give an error, (sting is returning a
value whereas the variable define is integer) but infact this is
returning a right value
thanks for ur answers
Ben Pfaff
> #include<stdio.h>
>
> void main()
`int' is the only portable return type for main().
> {
> int a[10];
> printf("enter string ");
You should either call fflush(stdout); or append a new-line to
the prompt in order to make sure it appears.
> scanf("%s",a);
That's undefined behavior. You need to change this call to be
scanf("%d", a);
> printf("%s",a);
Again, that's undefined behavior. You need to change this call
to be printf("%d", a[0]);
main() needs to return a value; e.g., return 0;
> }
>
> its a simple program written in msdos turbo c++ version 3.0, by
> convention this program should give an error, (sting is returning a
> value whereas the variable define is integer) but infact this is
> returning a right value
*shrug* Undefined behavior is unpredictable. The compiler is
not required to diagnose it.
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield
EkriirkE
@posting.google.com:
erm, i sometimes do things like this, it always works, look
a = 10 ints, 4*10 = 40 bytes of variable data (assuming int is 32bits)
say a[0] is located at 0x12345678 (&a[0]=0x12345678)
then a[1] would be 4 bytes after a0, 0x1234567C
its all linear
char a[40] is no different
a[0] is still 0x12345678
a[1] is only 1 byte after since char is 1 byte long, making a[3] in the
same place as a[1] of the previous declaration
dynamic-parameter functions such as scanf and printf, accept any data
type
in such parameters, arrays being passed, with or without &, as pointers
so the adress 0x12345678 would be passed in any case
only depending on the % code (%s/%d) does it know what the supposed
variable type is, printf's %s only cares about a pointer, and data
located
at the pointer terminating in a null
scanf only cares that there is buffer/variable space to place input'd
data
if you typed "Hello", int a[0] would be 'lleH', a[1], '..\0o', a[2]
'....',
etc (..=undef'd ["random" memory]), if a were a char array, a[0]='H', a
[1]
='e', etc
ok, im done rambling
--
I'm not a foreigner, honest! I just suck at typing...
Ben Pfaff
> kanwarj...@yahoo.com (KJ) wrote in news:dfbe016d.0210212117.73eebff9
> @posting.google.com:
>
> > #include<stdio.h>
> >
> > void main()
> > {
> > int a[10];
> > printf("enter string ");
> > scanf("%s",a);
> > printf("%s",a);
> > }
>
> erm, i sometimes do things like this, it always works,
Only because of implementation details.
> look
> a = 10 ints, 4*10 = 40 bytes of variable data (assuming int is 32bits)
> say a[0] is located at 0x12345678 (&a[0]=0x12345678)
> then a[1] would be 4 bytes after a0, 0x1234567C
> its all linear
Your arithmetic assumes, of course, that bytes are 8 bits each,
which C doesn't guarantee. C also doesn't guarantee that
pointers are linear. That said, it does guarantee that you can
access any data type as an array of char, and so it would valid,
if rather strange, to use an array of 10 int as an array of
10 * sizeof(int) bytes.
Unfortunately, that's not the code above does. It actually
passes a pointer to int where scanf() and printf() each expect
arguments of type pointer to char. C doesn't guarantee that
these pointers have the same size or format, and so the program
above will go *boom* on certain computers.
The solution is to declare the array element type to be char, or
to cast the arguments to char *. I recommend the former.
Also, it's necessary to limit the number of characters read by
scanf()'s %s so that it can't overflow the input buffer.
> char a[40] is no different
It's the correct type.
> dynamic-parameter functions such as scanf and printf, accept any data
> type
> in such parameters, arrays being passed, with or without &, as pointers
Again, this is implementation dependent.
> [...further misinformation snipped...]
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Bertrand Mollinier Toublet
"Ben Pfaff" <b...@cs.stanford.edu> a écrit dans le message de news:
87n0p7x...@pfaff.Stanford.EDU...
> kanwarj...@yahoo.com (KJ) writes:
>
> > #include<stdio.h>
> >
> > void main()
>
> `int' is the only portable return type for main().
>
> > {
> > int a[10];
> > printf("enter string ");
>
> You should either call fflush(stdout); or append a new-line to
> the prompt in order to make sure it appears.
>
> > scanf("%s",a);
>
> That's undefined behavior. You need to change this call to be
> scanf("%d", a);
>
> > printf("%s",a);
>
> Again, that's undefined behavior. You need to change this call
> to be printf("%d", a[0]);
>
> main() needs to return a value; e.g., return 0;
A somewhat recent post (no more than 2000 posts ago, that is two weeks) made
me wonder about that one. Though main does need to return a value, we don't
necessarily need to use a return statement at the end, as you are pointing
out, isn't that right ? And if it is, would you point out the exact rules
for that behaviour.
Cheers
bmt
Richard Bos
<bertrand.mol...@enst-bretagne.fr> wrote:
> "Ben Pfaff" <b...@cs.stanford.edu> a écrit dans le message de news:
> 87n0p7x...@pfaff.Stanford.EDU...
> > main() needs to return a value; e.g., return 0;
>
> A somewhat recent post (no more than 2000 posts ago, that is two weeks) made
> me wonder about that one. Though main does need to return a value, we don't
> necessarily need to use a return statement at the end, as you are pointing
> out, isn't that right ?
In C99, we don't, because (barf!) a missing return from main() is
guaranteed to return 0. In C89, the fool who forgets to return something
from main() gets the garbage return value he deserves.
Richard
EkriirkE
news:87vg3ux...@pfaff.Stanford.EDU:
> EkriirkE <m...@ss.hle> writes:
>
>> kanwarj...@yahoo.com (KJ) wrote in
news:dfbe016d.0210212117.73eebff9
>> @posting.google.com:
>>
>> > #include<stdio.h>
>> >
>> > void main()
>> > {
>> > int a[10];
>> > printf("enter string ");
>> > scanf("%s",a);
>> > printf("%s",a);
>> > }
>>
>> erm, i sometimes do things like this, it always works,
>
> Only because of implementation details.
>
>> look
>> a = 10 ints, 4*10 = 40 bytes of variable data (assuming int is 32bits)
>> say a[0] is located at 0x12345678 (&a[0]=0x12345678)
>> then a[1] would be 4 bytes after a0, 0x1234567C
>> its all linear
>
> Your arithmetic assumes, of course, that bytes are 8 bits each,
> which C doesn't guarantee. C also doesn't guarantee that
> pointers are linear. That said, it does guarantee that you can
> access any data type as an array of char, and so it would valid,
> if rather strange, to use an array of 10 int as an array of
> 10 * sizeof(int) bytes.
ive never seen a non 8-bit-byte.. even on lunix where it uses "7bit"
bytes.. its still 8 disreguarding b7
im talking about a single pointer here, referring the the first item of
the array
>
> Unfortunately, that's not the code above does. It actually
> passes a pointer to int where scanf() and printf() each expect
> arguments of type pointer to char.
for the first parameter, yes, the rest are void/wild/any
> C doesn't guarantee that
> these pointers have the same size or format, and so the program
> above will go *boom* on certain computers.
i am not saying that both char and int versions are defined, its an
either/or, just an example of the data buffer same size, different types
> The solution is to declare the array element type to be char, or
> to cast the arguments to char *. I recommend the former.
type casting it or not, when passed the same value would be passed
> Also, it's necessary to limit the number of characters read by
> scanf()'s %s so that it can't overflow the input buffer.
right, as i was explaining about the same-sized buffers of different
types, it doesnt matter as long as theres the space
>
>> char a[40] is no different
>
> It's the correct type.
that it be
>
>> dynamic-parameter functions such as scanf and printf, accept any data
>> type
>> in such parameters, arrays being passed, with or without &, as
pointers
>
> Again, this is implementation dependent.
maybe, but it would just wasteful to push the entire
structure/array/other large object onto the stack ..hence pointers..and
from pointers you can pull any data type os any size, and printf/scanf
interperate according the the % formatting sequences
>
>> [...further misinformation snipped...]
:P
Zoran Cutura
7-bit-bytes are not allowed in C but anything bigger than or
equal 8 is allowed and some systems/platforms do have 16 or 32
bits per byte. Note that in C a byte is a char and a char is a
byte and you must not confuse this with the meaning of byte in
storage devices or else.
> im talking about a single pointer here, referring the the first item of
> the array
>
Yes, that is also what Ben is talking about. As he said
sizeof(int) is by no means guaranteed to be 4 which is what you
are saying. It can even be 1. This depends on how your system
chooses to implement data types.
>>
>> Unfortunately, that's not the code above does. It actually
>> passes a pointer to int where scanf() and printf() each expect
>> arguments of type pointer to char.
>
> for the first parameter, yes, the rest are void/wild/any
Incorrect. The arguments passed thru the ellipsis (', ...') are
object to the default argument promotion and are accessed from
the called function in a certain manner. The called function on
the other hand has only limited abilities to access these
parameters and you must provide a value of a compatible type so
that the calling function can access it correctly.
If your tell printf (for example) that you are passing a long
("%ld") but actually pass a double, the value is accessed with an
incopatible type and this invokes undefined behavior. The same
happens when you tell printf to print a string ("%s"), which
expects an pointer to char to be passed, but pass a pointer to
int instead. The two are not compatible and undefined behavior is
invoked thereby.
>
>> C doesn't guarantee that
>> these pointers have the same size or format, and so the program
>> above will go *boom* on certain computers.
>
> i am not saying that both char and int versions are defined, its an
> either/or, just an example of the data buffer same size, different types
>
I don't understand this.
>> The solution is to declare the array element type to be char, or
>> to cast the arguments to char *. I recommend the former.
>
> type casting it or not, when passed the same value would be passed
>
Again, the same value may be passed on some systems others may
have for example 32-bit char pointers but 48-bit int pointers and
the two would not be compatible. You have to make sure that the
value passed thru the ellipsis is of correct type, otherwise your
program may break on some systems.
>> Also, it's necessary to limit the number of characters read by
>> scanf()'s %s so that it can't overflow the input buffer.
>
> right, as i was explaining about the same-sized buffers of different
> types, it doesnt matter as long as theres the space
>
Can you pretend how many characters a user will pass as input?
>>
>>> char a[40] is no different
>>
>> It's the correct type.
>
> that it be
>
>>
>>> dynamic-parameter functions such as scanf and printf, accept any data
>>> type
>>> in such parameters, arrays being passed, with or without &, as
> pointers
>>
>> Again, this is implementation dependent.
>
> maybe, but it would just wasteful to push the entire
> structure/array/other large object onto the stack ..hence pointers..and
> from pointers you can pull any data type os any size, and printf/scanf
> interperate according the the % formatting sequences
Nobody says that C implementations have to use a stack at all.
Also there could be systems that might copy a struct in just one
operation. You can't tell from the languages point of view. It
all depends on your implementation.
--
Z (Zoran....@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
A. Sinan Unur
huh?
> im talking about a single pointer here, referring the the first item of
> the array
>
>>
>> Unfortunately, that's not the code above does. It actually
>> passes a pointer to int where scanf() and printf() each expect
>> arguments of type pointer to char.
>
> for the first parameter, yes, the rest are void/wild/any
the variadic stdio functions deduce the types of arguments that follow the
format string using the formats you specified in the format string. it is a
good idea not to lie in the format string.
>> C doesn't guarantee that
>> these pointers have the same size or format, and so the program
>> above will go *boom* on certain computers.
>
> i am not saying that both char and int versions are defined, its an
> either/or, just an example of the data buffer same size, different types
>
>> The solution is to declare the array element type to be char, or
>> to cast the arguments to char *. I recommend the former.
>
> type casting it or not, when passed the same value would be passed
read ben's comment carefully.
> maybe, but it would just wasteful to push the entire
> structure/array/other large object onto the stack ..hence pointers..and
> from pointers you can pull any data type os any size, and printf/scanf
> interperate according the the % formatting sequences
I am not clear what you mean by this, but i would venture to guess that
planting bugs like this in your program is more wasteful. just be honest to
scanf, and pass it what you tell you are passing.
of course, you are, in no way, obligated to follow good advice.
> I'm not a foreigner, honest! I just suck at typing...
foreigner where? and if you care so much, why don't you go ahead and fix
your typing.
--
A. Sinan Unur
as...@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:u...@ftc.gov
Richard Heathfield
>
<snip>
>
> ive never seen a non 8-bit-byte.. even on lunix where it uses "7bit"
> bytes.. its still 8 disreguarding b7
"There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy."
Hamlet I(v).
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Joona I Palaste
> foreigner where? and if you care so much, why don't you go ahead and fix
> your typing.
The universal definition of "foreigner" is "non-USA citizen". Therefore,
I am a foreigner in my own country.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
Dan Pop
>> main() needs to return a value; e.g., return 0;
>
>A somewhat recent post (no more than 2000 posts ago, that is two weeks) made
>me wonder about that one. Though main does need to return a value,
Nope, the initial invocation of main doesn't need to return a value: the
caller is not a piece of user-written C code that uses its return value.
>we don't
>necessarily need to use a return statement at the end, as you are pointing
>out, isn't that right ?
It's right.
>And if it is, would you point out the exact rules for that behaviour.
C89: the program's exit status is undefined.
C99: reaching the final } of main is equivalent to a return 0 statement.
C99 doesn't specify what happens in the following case:
int main()
{
return;
}
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>C99 doesn't specify what happens in the following case:
>
> int main()
> {
> return;
> }
That's because this code requires a diagnostic in C99 :-)
I forgot this change between C89 and C99.
E. Gibbons
main() must be declared as returning int. However, if you don't care
what kind of garbage gets returned to the OS, you don't have to have a
"return" statement (nor call "exit()"). So all those people who argue
for "void main()" can still have it their way and not return anything,
*and* save a character, by prototyping main() with int return type.
I.e.:
LEGAL:
int main(void)
{
}
ILLEGAL:
void main(void)
{
}
As of C99, the returned value is guaranteed to be 0 if you "fall off"
main() without a "return", but most implementations are not C99-compliant
yet.
--Ben
--
John Smith
> erm, i sometimes do things like this, it always works, look
<snip ungrammatical drivel>
> ok, im done rambling
Good, because you're not helping.
> -- I'm not a foreigner, honest! I just suck at typing...
Look, even your sig's annoying me.
those who know me have no need of my name
>main() must be declared as returning int. However, if you don't care
>what kind of garbage gets returned to the OS, you don't have to have a
>"return" statement (nor call "exit()").
not true. the effect required by all versions of the c standard is to pass
the return value from main as the argument to exit. it is almost certain
that exit will care that it have a valid argument -- even an ms-windows
`winapp' will return it to the o/s (where it's likely to be ignored), and
it may be that the platform will care. c99 added an implicit `return 0;'
at the end of main so you are safe if that's the implementation, as you
noted, but a pre-c99 implementation would pass an indeterminate (possibly
trap) value to exit.
so i'd say you need a bit more qualifier ...
if you:
are using a c99 implementation,
or
a pre-c99 implementation that provides an implicit `return 0;' at the end
of main(),
or
don't care whether or if your program terminates properly, including but
not limited to: the last data written to a file disappearing or the
controlling application (if any) taking inappropriate action,
then you don't have to have a return statement in main() or a call to
exit(). i.e., always supply one or the other, or both.
--
bringing you boring signatures for 17 years
A. Sinan Unur
news:ap3nob$gsg$1...@oravannahka.helsinki.fi:
> A. Sinan Unur <as...@c-o-r-n-e-l-l.edu> scribbled the following:
>> EkriirkE <m...@ss.hle> wrote in
>> news:Xns92AF2B245...@216.148.227.77:
>>> I'm not a foreigner, honest! I just suck at typing...
>
>> foreigner where? and if you care so much, why don't you go ahead and
>> fix your typing.
>
> The universal definition of "foreigner" is "non-USA citizen".
> Therefore, I am a foreigner in my own country.
a-ha! :)
E. Gibbons
those who know me have no need of my name <not-a-rea...@usa.net> wrote:
>in comp.lang.c i read:
>
>>main() must be declared as returning int. However, if you don't care
>>what kind of garbage gets returned to the OS, you don't have to have a
>>"return" statement (nor call "exit()").
>
>not true. the effect required by all versions of the c standard is to pass
>the return value from main as the argument to exit. it is almost certain
>that exit will care that it have a valid argument -- even an ms-windows
>`winapp' will return it to the o/s (where it's likely to be ignored), and
>it may be that the platform will care. c99 added an implicit `return 0;'
>at the end of main so you are safe if that's the implementation, as you
>noted, but a pre-c99 implementation would pass an indeterminate (possibly
>trap) value to exit.
Yes -- but there's no prohibition against returning nothing. Pre-C99,
you'd get garbage if you did (i.e., implementation-defined results).
I.e., what I said was true. Please note that I am by no means
recommending not returning a value or calling exit(), just pointing
out that you are *allowed* to neglect these things. You're also allowed
to neglect calling free() on malloc()ed objects, before terminating.
You're *not* allowed to declare main() as returning void (and still hope
to have a valid C program -- god knows, you're unfortunately "allowed"
to void main() on way too many implementations...).
>so i'd say you need a bit more qualifier ...
>
>if you:
>
> are using a c99 implementation,
>
> or
>
> a pre-c99 implementation that provides an implicit `return 0;' at the end
> of main(),
>
>or
>
> don't care whether or if your program terminates properly, including but
> not limited to: the last data written to a file disappearing or the
> controlling application (if any) taking inappropriate action,
But I think this last case is incorrect. It's only, if you don't care
what kind of garbage the OS (or calling entity) receives from main().
There shouldn't be license to lose data written to a file.
>then you don't have to have a return statement in main() or a call to
>exit(). i.e., always supply one or the other, or both.
Well, yes.
--
Eric G. Miller
> A. Sinan Unur <as...@c-o-r-n-e-l-l.edu> scribbled the following:
>> EkriirkE <m...@ss.hle> wrote in news:Xns92AF2B245...@216.148.227.77:
>>> I'm not a foreigner, honest! I just suck at typing...
>
>> foreigner where? and if you care so much, why don't you go ahead and fix
>> your typing.
>
> The universal definition of "foreigner" is "non-USA citizen". Therefore,
> I am a foreigner in my own country.
Pure nonsense. Let's try to stay on-topic, okay?
EkriirkE
$jn7$1...@news.sns-felb.debis.de:
anyway, all this is irrelevant to what im trying/failing to explain, or
most of you actually dont know what pointers really are at all. i was
just using for example 2 different kinds of variabes, in array, which
happen to be of the same total size
maybe if i speak C, you will understand
for the purpose of this example int will be 32bits(4bytes), and chat an *
8-bit* single byte [aha! there! now you cant needlessly vent your anger
on this point!]
int *a=mallc(sizeof(int)*10);
char *a=malloc(sizeof(char)*40);
now by these 2 *seperate* examples (dont be lame and say something
pointless like 'hey, you cant redifine a!, youre and idiot, go read the
faq')
the number passed to malloc, in this *example* is 40 in both cases
for this purpose, too.. *assume* c arrays are linear (as i, myself, have
seen this to be that case 100%, in borland, msvc & metrowerks beos c
[thats gcc, isnt it?]..maybe unless theres some special build switch for
it.. but i dont see why, because its MUCH easier & faster to caculate the
data by; posofbaseindex+sizeof(variabletype)*indexnumber)
if you were to pass 'a', a being a *pointer* ( a pointer is a pointer is
a pointer, it will not be different depending on what type or variable
it's pointing to), you are in reality pushing a number, a locatin in
memory of the variable data.
now, saying that when you gave scanf the 'int *a', you were really just
pushing the position in memory (or offset depending on build), and thats
all scanf/printf care about for things like %s, its a location in memory
where to put/read data.
Am I still not making sense?
Kinda-OT; Learn assembly, it will give you a much better realization of
how things work, especially pointers.
--
I'm not a foreigner, honest! I just suck at typing... (Vote to change
to: I suffer from chat-typing syndrome)?
Richard Heathfield
>
> "Zoran Cutura" <Zoran....@daimlerchrysler.com> wrote in news:ap3fgv
> $jn7$1...@news.sns-felb.debis.de:
>
> anyway, all this is irrelevant to what im trying/failing to explain, or
> most of you actually dont know what pointers really are at all. i was
> just using for example 2 different kinds of variabes, in array, which
> happen to be of the same total size
>
> maybe if i speak C, you will understand
>
> for the purpose of this example int will be 32bits(4bytes), and chat an *
> 8-bit* single byte [aha! there! now you cant needlessly vent your anger
> on this point!]
>
> int *a=mallc(sizeof(int)*10);
>
> char *a=malloc(sizeof(char)*40);
>
> now by these 2 *seperate* examples (dont be lame and say something
> pointless like 'hey, you cant redifine a!, youre and idiot, go read the
> faq')
Well, how about
int *firstexample = malloc(sizeof *firstexample * 10);
int *secondexample = malloc(sizeof *secondexample * 40);
> the number passed to malloc, in this *example* is 40 in both cases
If ints are 4 bytes big (as you outlined above), then yes, that's right.
> for this purpose, too.. *assume* c arrays are linear
malloc returns a pointer to contiguous storage, if that's what you mean.
> (as i, myself, have
> seen this to be that case 100%, in borland, msvc & metrowerks beos c
> [thats gcc, isnt it?]..maybe unless theres some special build switch for
> it.. but i dont see why, because its MUCH easier & faster to caculate the
> data by; posofbaseindex+sizeof(variabletype)*indexnumber)
I think it's even easier to say base + index and let C's pointer
arithmetic rules take the strain.
> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer is
> a pointer, it will not be different depending on what type or variable
> it's pointing to),
That is very implementation-dependent. The C Standard certainly offers
you no such guarantee.
<snip>
>
> Am I still not making sense?
Not much.
>
> Kinda-OT; Learn assembly, it will give you a much better realization of
> how things work, especially pointers.
Kinda-T: Learn to write C programs that work unmodified on systems that
use 9- or 16- or 32- or some-other-number-other-than-eight-bit bytes, on
systems that use EBCDIC, on systems that have never heard of a directory
but still manage to organise their data sensibly, and so on.
It will broaden your outlook immeasurably.
Jack Klein
<bin...@eton.powernet.co.uk> wrote in comp.lang.c:
> EkriirkE wrote:
> >
> <snip>
> >
> > ive never seen a non 8-bit-byte.. even on lunix where it uses "7bit"
> > bytes.. its still 8 disreguarding b7
>
> "There are more things in heaven and earth, Horatio,
> Than are dreamt of in your philosophy."
> Hamlet I(v).
>
> <snip>
It's OK then, the Hamlet vI compiler (after applying service pace
VII.CVL) has 8 bit bytes...
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Zoran Cutura
> "Zoran Cutura" <Zoran....@daimlerchrysler.com> wrote in news:ap3fgv
> $jn7$1...@news.sns-felb.debis.de:
>
> anyway, all this is irrelevant to what im trying/failing to explain, or
> most of you actually dont know what pointers really are at all. i was
> just using for example 2 different kinds of variabes, in array, which
> happen to be of the same total size
It is not irrelevant. You are mixing up implementation specific
assumptions with what is guaranteed by the international C
standard. You really should care to read the standard befor you
actually try to confess about what is correct C and what is not.
>
> maybe if i speak C, you will understand
Oh, we're speaking C all the time. scanf and printf are C just as
anything else defined in the standard.
>
> for the purpose of this example int will be 32bits(4bytes), and chat an *
> 8-bit* single byte [aha! there! now you cant needlessly vent your anger
> on this point!]
Ahh... You're again putting constraints on your implementation.
If you want to write portable programs (and that is the reason
why there actually is a standard, otherwise we could simply
discuss C for Vaxen or C for PC's or else) you shouldn't assume
such things like int is 32Bit or such. int is allowed to be
anything in bit-size that is able to represent at least values
from -32767 to +32767.
>
> int *a=mallc(sizeof(int)*10);
>
> char *a=malloc(sizeof(char)*40);
>
>
> now by these 2 *seperate* examples (dont be lame and say something
> pointless like 'hey, you cant redifine a!, youre and idiot, go read the
> faq')
>
> the number passed to malloc, in this *example* is 40 in both cases
Yes if you only want your program to be running on systems with
exactly these byte-sizes.
>
> for this purpose, too.. *assume* c arrays are linear (as i,
myself, have
if linear means that C arrays are contiuously allocated, than I
don't have to assume this, but I can rely on it as the standard
guarantees it.
> seen this to be that case 100%, in borland, msvc & metrowerks
beos c
I think they are claiming to be conforming implementations.
> [thats gcc, isnt it?]..maybe unless theres some special build switch for
> it.. but i dont see why, because its MUCH easier & faster to caculate the
> data by; posofbaseindex+sizeof(variabletype)*indexnumber)
>
> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer is
> a pointer, it will not be different depending on what type or variable
> it's pointing to), you are in reality pushing a number, a locatin in
> memory of the variable data.
If I were to pass 'a' where? And yes, C only passes by value. But
if you go and read the standard you will find out that passing a
value thru a formal parameter is different from passing it to a
function without a prototype in scope or passing it thru an
ellipsis.
>
> now, saying that when you gave scanf the 'int *a', you were really just
> pushing the position in memory (or offset depending on build), and thats
> all scanf/printf care about for things like %s, its a location in memory
> where to put/read data.
I'ld say you're wrong. From ISO/IEC 9899:1999
6.5.2.2 Function calls
6 ... If the function is defined with a type that includes
a prototype, and either the prototype ends with an
ellipsis (, ...) or the types of the arguments after
promotion are not compatible with the types of the
parameters, the behavior is undefined.
So one must not pass values as arguments that are not of the type
expected by the variadic function. And when you pass a int* where
a char* is expected, the two are by no means compatible, even
though this appears to work for your current system.
Again, you must not conclude from your implementation of the C
language to the general rule.
>
> Am I still not making sense?
>
Not any more than befor.
>
>
> Kinda-OT; Learn assembly, it will give you a much better realization of
> how things work, especially pointers.
If you learn assembly you are bound to exactly one platform or
system. You cannot take to same assembly program to the very next
system and try to run it there.
You may want to learn more than only one assembler, thereby you
will probably also learn to see the diversity of systems.
I would say that howmuch soever (is this correct english?)
systems you get to know, be sure that there is a x*more different
systems actually existing in this little world out there.
CBFalconer
>
> On Tue, 22 Oct 2002 14:50:07 +0100, Richard Heathfield
> <bin...@eton.powernet.co.uk> wrote in comp.lang.c:
>
> > EkriirkE wrote:
> > >
> > <snip>
> > >
> > > ive never seen a non 8-bit-byte.. even on lunix where it uses "7bit"
> > > bytes.. its still 8 disreguarding b7
> >
> > "There are more things in heaven and earth, Horatio,
> > Than are dreamt of in your philosophy."
> > Hamlet I(v).
> >
> > <snip>
>
> It's OK then, the Hamlet vI compiler (after applying service pace
> VII.CVL) has 8 bit bytes...
That would 'pear to shake up the OP.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
EkriirkE
...
> It is not irrelevant. You are mixing up implementation specific
> assumptions with what is guaranteed by the international C
> standard. You really should care to read the standard befor you
> actually try to confess about what is correct C and what is not.
oh, but it is, they are nitpicking on variable size, which doesnt really
mean anything added up when it comed to buffer space, it was just an
example of why passing a non-char pointer to a char pointer-wanting
function doesnt care, and why it works
>
...
>
> Oh, we're speaking C all the time. scanf and printf are C just as
> anything else defined in the standard.
im being sarcastic :P
>>
>> for the purpose of this example int will be 32bits(4bytes), and chat
>> an * 8-bit* single byte [aha! there! now you cant needlessly vent
>> your anger on this point!]
>
> Ahh... You're again putting constraints on your implementation.
> If you want to write portable programs (and that is the reason
> why there actually is a standard, otherwise we could simply
> discuss C for Vaxen or C for PC's or else) you shouldn't assume
> such things like int is 32Bit or such. int is allowed to be
> anything in bit-size that is able to represent at least values
> from -32767 to +32767.
this has nothing to do with numeric values, once again, irrelevant, what im
talking about is purley the space the array (or malloc) takes up
>
...
>
> Yes if you only want your program to be running on systems with
> exactly these byte-sizes.
umm, its an example... an example. its just showing space taken by an
array
>
...
>
> if linear means that C arrays are contiuously allocated, than I
> don't have to assume this, but I can rely on it as the standard
> guarantees it.
ok, well some other guy said it didnt...
>
...
> I think they are claiming to be conforming implementations.
by experience and what you stated above, they are..on this topic
>
...
>
> If I were to pass 'a' where? And yes, C only passes by value. But
> if you go and read the standard you will find out that passing a
> value thru a formal parameter is different from passing it to a
> function without a prototype in scope or passing it thru an
> ellipsis.
i need my theasarus... ;)
>>
>> now, saying that when you gave scanf the 'int *a', you were really just
>> pushing the position in memory (or offset depending on build), and thats
>> all scanf/printf care about for things like %s, its a location in memory
>> where to put/read data.
> I'ld say you're wrong. From ISO/IEC 9899:1999
>
> 6.5.2.2 Function calls
>
> 6 ... If the function is defined with a type that includes
> a prototype, and either the prototype ends with an
> ellipsis (, ...) or the types of the arguments after
> promotion are not compatible with the types of the
> parameters, the behavior is undefined.
>
> So one must not pass values as arguments that are not of the type
> expected by the variadic function. And when you pass a int* where
> a char* is expected, the two are by no means compatible, even
> though this appears to work for your current system.
>
> Again, you must not conclude from your implementation of the C
> language to the general rule.
>
and the prototype being wild (the ...), accepting (almost) anything, and %s
is happy with just the space to read/write, bet it allocated for int, char,
struct, you name it; its there, it exists, and it can use it.
whether 'a' had been a char/int/struct pointer, it would have still pointed
the the same place in memory, and if enough space were allocated at this
position for %s to be happy with, thats all that matters.
>>
>> Am I still not making sense?
>>
>
> Not any more than befor.
heh
>
...
>
> You may want to learn more than only one assembler, thereby you
> will probably also learn to see the diversity of systems.
> I would say that howmuch soever (is this correct english?)
> systems you get to know, be sure that there is a x*more different
> systems actually existing in this little world out there.
>
with the original code:
void main()
{
int a[10];
printf("enter string ");
scanf("%s",a);
printf("%s",a);
}
now, once again, *assuming* just for *example* int is 32-bits, and char is
8, i can rewrite this as so
void main()
{
char a[40];
printf("enter string ");
scanf("%s",a);
printf("%s",a);
}
and compiled it ought to be identical to the last bit (excluding exec.
header), if not, for some reason, then functionally, it is
char a[40] and int a[10], in this *example* - with the *assumed* sizes, to
scanf's %s is just a 40 8-bit-byte buffer to place data in, and likewise
for printf's to read from
EkriirkE
dont you love it when ppl are beaten/dont understand, they lash out?
Richard Bos
> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer is
> a pointer, it will not be different depending on what type or variable
> it's pointing to),
And this is where you are really fundamentally wrong. All your other
errors, numerous though they may be, are merely assumptions about sizes,
unfamiliarity with guarantees that the Standard _does_ make, and so
forth. But this is a fundamental error.
A pointer is _not_ a pointer is not a pointer. A pointer to int may be a
different size to a pointer to char, or differently aligned, or
differently laid out.
It is even allowable for the compiler to pass int pointers in another
register than char pointers; if it does this, and you call
printf("%s", some_int_pointer);
then printf() may not even get to see a garbled int pointer, it may see
nothing at all but garbage.
Bottom line: you _cannot_ assume that pointers are randomly
interchangable.
Richard
Richard Heathfield
>
> "Zoran Cutura" <Zoran....@daimlerchrysler.com> wrote in
> news:ap5iea$fp2$1...@news.sns-felb.debis.de:
>
> ...
> > It is not irrelevant. You are mixing up implementation specific
> > assumptions with what is guaranteed by the international C
> > standard. You really should care to read the standard befor you
> > actually try to confess about what is correct C and what is not.
>
> oh, but it is, they are nitpicking on variable size, which doesnt really
> mean anything added up when it comed to buffer space, it was just an
> example of why passing a non-char pointer to a char pointer-wanting
> function doesnt care, and why it works
It "works" by chance at best (as far as the C language is concerned),
and you cannot guarantee it will "work" in the same way on all
platforms.
<snip>
> > if linear means that C arrays are contiuously allocated, than I
> > don't have to assume this, but I can rely on it as the standard
> > guarantees it.
>
> ok, well some other guy said it didnt...
What will you put your trust in? What some other guy said, or what the
International Standard for the language guarantees?
<snip>
> > If I were to pass 'a' where? And yes, C only passes by value. But
> > if you go and read the standard you will find out that passing a
> > value thru a formal parameter is different from passing it to a
> > function without a prototype in scope or passing it thru an
> > ellipsis.
>
> i need my theasarus... ;)
You would be better served by a copy of the ISO C Standard. Anyway, an
ellipsis is the ... symbol used in the prototypes of functions such as
printf, scanf, etc.
<snip>
> > Again, you must not conclude from your implementation of the C
> > language to the general rule.
> >
>
> and the prototype being wild (the ...), accepting (almost) anything,
What you can pass via ... is irrelevant. What matters is what the
calling function will process correctly.
> and %s
> is happy with just the space to read/write, bet it allocated for int, char,
> struct, you name it; its there, it exists, and it can use it.
Not in a portable and well-defined way.
>
> whether 'a' had been a char/int/struct pointer, it would have still pointed
> the the same place in memory, and if enough space were allocated at this
> position for %s to be happy with, thats all that matters.
Consider an implementation which uses registers to pass parameters, and
in which pointers to char are placed in different registers to pointers
to int. On such an implementation, this code:
int d;
scanf("%s", &d);
will not act as you claim it will act.
<snip>
> > You may want to learn more than only one assembler, thereby you
> > will probably also learn to see the diversity of systems.
> > I would say that howmuch soever (is this correct english?)
> > systems you get to know, be sure that there is a x*more different
> > systems actually existing in this little world out there.
> >
>
> with the original code:
>
> void main()
Undefined behaviour: main must return int.
> {
> int a[10];
> printf("enter string ");
Undefined behaviour: use of variadic function without a valid prototype
in scope.
> scanf("%s",a);
Undefined behaviour: passing a pointer to int instead of a pointer to an
array of char.
> printf("%s",a);
> }
>
> now, once again, *assuming* just for *example* int is 32-bits, and char is
> 8, i can rewrite this as so
>
> void main()
> {
> char a[40];
> printf("enter string ");
> scanf("%s",a);
> printf("%s",a);
> }
>
> and compiled it ought to be identical to the last bit (excluding exec.
> header),
Well, it has many of the same bugs as before, if that's what you mean.
> if not, for some reason, then functionally, it is
>
> char a[40] and int a[10], in this *example* - with the *assumed* sizes, to
> scanf's %s is just a 40 8-bit-byte buffer to place data in, and likewise
> for printf's to read from
You want to get out more - maybe take in a mainframe compiler or two, or
work on DSP chips for a bit.
Zoran Cutura
> now, once again, *assuming* just for *example* int is 32-bits, and char is
> 8, i can rewrite this as so
You are assuming to much. If we continue this discussion on this
assumptions we need to pass the whole thing to a system related
newsgroup, because we cannot assume this for all conforming C
implementations.
Once again, you must not assume anything about the size of
objects. You have some guarantees from the standard and the rest
should be handled as if everything was possible. So please,
please refrain from these assumptions/conclusions deriving from
your experience with exactly _one_ platform.
EkriirkE
EkriirkE
news:3db659b0....@news.nl.net:
> EkriirkE <m...@ss.hle> wrote:
>
>> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer
>> is a pointer, it will not be different depending on what type or
>> variable it's pointing to),
>
> And this is where you are really fundamentally wrong. All your other
> errors, numerous though they may be, are merely assumptions about
> sizes, unfamiliarity with guarantees that the Standard _does_ make,
> and so forth. But this is a fundamental error.
> A pointer is _not_ a pointer is not a pointer. A pointer to int may be
> a different size to a pointer to char, or differently aligned, or
> differently laid out.
wrong, type is irrelevant, a pointer is simply a number that is a
reference to a position in memory
> It is even allowable for the compiler to pass int pointers in another
> register than char pointers; if it does this, and you call
>
> printf("%s", some_int_pointer);
>
> then printf() may not even get to see a garbled int pointer, it may
> see nothing at all but garbage.
> Bottom line: you _cannot_ assume that pointers are randomly
> interchangable.
>
> Richard
some_int_pointer was already "defined" by scanf, it has a 100%
predictability
EkriirkE
> EkriirkE wrote:
...
>> oh, but it is, they are nitpicking on variable size, which doesnt
>> really mean anything added up when it comed to buffer space, it was
>> just an example of why passing a non-char pointer to a char
>> pointer-wanting function doesnt care, and why it works
>
> It "works" by chance at best (as far as the C language is concerned),
> and you cannot guarantee it will "work" in the same way on all
> platforms.
>
> <snip>
>
>> > if linear means that C arrays are contiuously allocated, than I
>> > don't have to assume this, but I can rely on it as the standard
>> > guarantees it.
>>
>> ok, well some other guy said it didnt...
>
> What will you put your trust in? What some other guy said, or what the
> International Standard for the language guarantees?
lol, just indirectly saying 'ha!' to him
> <snip>
...
>
>> > Again, you must not conclude from your implementation of the C
>> > language to the general rule.
>> >
>>
>> and the prototype being wild (the ...), accepting (almost) anything,
>
> What you can pass via ... is irrelevant. What matters is what the
> calling function will process correctly.
scanf places data there, its my memory space, i have permissions, i can put
what i want there, it will be correct
>
>> and %s
>> is happy with just the space to read/write, bet it allocated for int,
>> char, struct, you name it; its there, it exists, and it can use it.
>
> Not in a portable and well-defined way.
idunno..., i forgot to add MPW for the Mac to my experience list; it, too,
reacts as my other experiences do. and that there is a completley
different architecture
>
>>
>> whether 'a' had been a char/int/struct pointer, it would have still
>> pointed the the same place in memory, and if enough space were
>> allocated at this position for %s to be happy with, thats all that
>> matters.
>
> Consider an implementation which uses registers to pass parameters,
> and in which pointers to char are placed in different registers to
> pointers to int. On such an implementation, this code:
>
> int d;
> scanf("%s", &d);
>
> will not act as you claim it will act.
ah, but it will.. only you now are limited to entering sizeof(d) bytes...
as i was trying to explain in many previous posts.. as long as there is the
room for it, you can do it
if i entered "123" <enter>, making "123\0", and for this *example*,
*assuming* sizeof(int)=4 (making the maximum i can enter being 3 bytes, or
i will corrupt and/or crash something), i can recall it in printf
perfectly;
printf("%s", &d);
and, guess what? you get "123" :o
and, FYI, d would now be (in its 'native' [32bit] int form according to
specs stated above) 0x00333231(3355185) little-endian, 0x31323300
(825373440) big-endian. again, 100% predictable & reproducable
try it. life experience is worth much more than some book
>
> <snip>
>
>> > You may want to learn more than only one assembler, thereby you
>> > will probably also learn to see the diversity of systems.
>> > I would say that howmuch soever (is this correct english?)
>> > systems you get to know, be sure that there is a x*more different
>> > systems actually existing in this little world out there.
>> >
>>
>> with the original code:
>>
>> void main()
>
> Undefined behaviour: main must return int.
weve been thru this
>
>> {
>> int a[10];
>> printf("enter string ");
>
> Undefined behaviour: use of variadic function without a valid
> prototype in scope.
were going thru this
>
>> scanf("%s",a);
>
see above
> Undefined behaviour: passing a pointer to int instead of a pointer to
> an array of char.
>
>> printf("%s",a);
>> }
>>
>> now, once again, *assuming* just for *example* int is 32-bits, and
>> char is 8, i can rewrite this as so
>>
>> void main()
>> {
>> char a[40];
>> printf("enter string ");
>> scanf("%s",a);
>> printf("%s",a);
>> }
>>
>> and compiled it ought to be identical to the last bit (excluding
>> exec. header),
>
> Well, it has many of the same bugs as before, if that's what you mean.
>
lol, no...and yes, maybe
>
>> if not, for some reason, then functionally, it is
>>
>> char a[40] and int a[10], in this *example* - with the *assumed*
>> sizes, to scanf's %s is just a 40 8-bit-byte buffer to place data in,
>> and likewise for printf's to read from
>
> You want to get out more - maybe take in a mainframe compiler or two,
> or work on DSP chips for a bit.
>
But i'm still working on my monitor tan!
EkriirkE
time when i saw a sign of disagreement (i know im right, im just not
explaining it right)
altho hes disagreeing a whole lot,....
Ben Pfaff <b...@cs.stanford.edu> wrote in
news:87vg3ux...@pfaff.Stanford.EDU:
...lots of'snip'...
> [...] That said, it does guarantee that you can
> access any data type as an array of char, and so it would valid,
> if rather strange, to use an array of 10 int as an array of
> 10 * sizeof(int) bytes.
here its suggested he completley comprehends what going on here, and this
is what im trying&failing to explain to the rest of you, and its why the
original post's code works
Richard Bos
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
> news:3db659b0....@news.nl.net:
>
> > EkriirkE <m...@ss.hle> wrote:
> >
> >> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer
> >> is a pointer, it will not be different depending on what type or
> >> variable it's pointing to),
> >
> > And this is where you are really fundamentally wrong. All your other
> > errors, numerous though they may be, are merely assumptions about
> > sizes, unfamiliarity with guarantees that the Standard _does_ make,
> > and so forth. But this is a fundamental error.
> > A pointer is _not_ a pointer is not a pointer. A pointer to int may be
> > a different size to a pointer to char, or differently aligned, or
> > differently laid out.
>
> wrong, type is irrelevant, a pointer is simply a number that is a
> reference to a position in memory
You, sir, don't know what the *fuck* you are talking about.
A pointer is an object that addresses another object. It is legal for a
pointer to be implemented as a (segment, offset) pair. It is legal for a
pointer to be implemented (in an interpreter, for example) as a (name of
object, bytecount into object, size of object) triplet. It is legal for
pointers to long and larger to be four bytes large, and char pointers to
be five bytes large and consist of a long pointer plus a bytecount. It
is _also_ legal for all pointers to be simple numerical indices into
memory, but if you think this is required you need to stick your head
outside your woolly Windows world some day.
> > It is even allowable for the compiler to pass int pointers in another
> > register than char pointers; if it does this, and you call
> >
> > printf("%s", some_int_pointer);
>
> some_int_pointer was already "defined" by scanf,
I'm sorry, but that is so stupid a claim it defies serious refuting.
Richard
Zoran Cutura
>
>
> wrong, type is irrelevant, a pointer is simply a number that is a
> reference to a position in memory
Can you supply a reference that defines this? Here is what
"The Standard" has to say about pointers:
6.7.5.1 Pointer declarators Semantics
1 If, in the declaration "T D1", D1 has the form
* type-qualifier-list(opt) D
and the type specified for ident in the declaration
"T D" is "derived-declarator-type-list T", then the
type specified for ident is "derived-declarator-type-list
type-qualifier-list pointer to T". For each type
qualifier in the list, ident is a so-qualified pointer.
2 For two pointer types to be compatible, both shall be
identically qualified and both shall be pointers to
compatible types.
And we've been trying over and over to tell you this, but you
appear to not be listening.
What do you expect to be to output of the following little
program, and how would this support what you are saying?
#include <stdio.h>
int main(void)
{
int *p;
printf("%d\n", (int) (p+1-p));
printf("%d\n", (int) ((char*)(p+1) - (char *)p));
return 0;
}
Do you recognize that p+1 is depending on the pointers type?
Again as Richard said, a pointer is _not_ a pointer is not a
pointer.
--
Zoran Cutura
> look up the word "example"
As I said there is nothing that one example can prove.
Zoran Cutura
What Ben said, is that
#include <limits.h>
enum {CHAR_T, INT_T, P_CHAR_T, P_INT_T };
void foo(int type, ...)
{
va_list ap;
char *p;
int i=0;
va_start(ap, type);
switch(type) {
case P_CHAR_T: {
p = va_arg(ap, (char *));
break;
}
case P_INT_T: {
int *ip;
ip = va_arg(ap, (int *));
p = (char *) ip;
break;
}
}
while(i < sizeof(int))
p[i++] = 1;
va_end(ap);
}
void bar(void)
{
int x;
foo(P_INT_T, &x); /* does not invode UB */
foo(P_CHAR_T, (char *) &x); /* does not invode UB */
foo(P_CHAR_T, &x); /* does invode UB */
EkriirkE
$1...@news.sns-felb.debis.de:
> Once upon a while EkriirkE <m...@ss.hle> wrote:
>
>>
>>
>> wrong, type is irrelevant, a pointer is simply a number that is a
>> reference to a position in memory
>
> Can you supply a reference that defines this? Here is what
> "The Standard" has to say about pointers:
>
> 6.7.5.1 Pointer declarators Semantics
>
> 1 If, in the declaration "T D1", D1 has the form
> * type-qualifier-list(opt) D
> and the type specified for ident in the declaration
> "T D" is "derived-declarator-type-list T", then the
> type specified for ident is "derived-declarator-type-list
> type-qualifier-list pointer to T". For each type
> qualifier in the list, ident is a so-qualified pointer.
>
> 2 For two pointer types to be compatible, both shall be
> identically qualified and both shall be pointers to
> compatible types.
>
1) huh?
2) is just a sentance repeating itself: for something to be compatible, it
needs to be compatible
> And we've been trying over and over to tell you this, but you
> appear to not be listening.
>
you ppl need to understand what and where pointers do and go. you are all
going by your own interperetation of what this book or faq says
> What do you expect to be to output of the following little
> program, and how would this support what you are saying?
>
> #include <stdio.h>
> int main(void)
> {
> int *p;
> printf("%d\n", (int) (p+1-p));
> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
> return 0;
> }
>
> Do you recognize that p+1 is depending on the pointers type?
> Again as Richard said, a pointer is _not_ a pointer is not a
> pointer.
>
i predict:
1
4
reguardless whether or not p has been initialized, in your formula, p
cancels p out leaving 1, the next one, typecasting straight on the pointer
(no addition with it) has no effect whatsoever but to appease the compiler.
however where you have p+1, p being of int will multiply the adder by
sizeof(int) and add it to p, but if you typecast p pointer type first
(char *)p, you just made the multiplicand different, sizeof(char). that is
only affecting your offset/adder ratio, again on this example we are using
the base of the array as the reference, no matter how you cast it, it will
not change
EkriirkE
...
>
> You, sir, don't know what the *fuck* you are talking about.
whatever floats your boat
>
> A pointer is an object that addresses another object.
..and ive been saying...?
> It is legal for a
> pointer to be implemented as a (segment, offset) pair.
yes, ive been saying this, you are going a little in-depth for a certain
platform(s) segment:offset = position in memory
> It is legal for a pointer to be implemented (in an interpreter, for
> example) as a (name of object, bytecount into object, size of object)
> triplet.
what? where?
> It is legal for pointers to long and larger to be four bytes large,
> and char pointers to be five bytes large and consist of a long pointer
> plus a bytecount.
that is a pointer and something extra(len byte[s]), it in itself is not
a pointer
> It is _also_ legal for all pointers to be simple numerical indices into
> memory
uhh, that *IS* a pointer, and what ive been saying all along...
> but if you think this is required you need to stick your head
> outside your woolly Windows world some day.
>
what's required?
>> > It is even allowable for the compiler to pass int pointers in
>> > another register than char pointers; if it does this, and you call
>> >
>> > printf("%s", some_int_pointer);
>>
>> some_int_pointer was already "defined" by scanf,
>
> I'm sorry, but that is so stupid a claim it defies serious refuting.
did you even look at the original code? try it and be enlightened
EkriirkE
btw, whats this UB i see here alot?
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
> "Zoran Cutura" <Zoran....@daimlerchrysler.com> wrote in news:ap5tj8$jrg
> $1...@news.sns-felb.debis.de:
>
>> identically qualified and both shall be pointers to
>> compatible types.
>
> needs to be compatible
Erm, no, look a little more closely.
For qualified-Q1-pointer-to-T1 to be compatible with qualified-Q2-pointer-to-T2,
Q1 and Q2 must be the same and _T1 and T2_ must be compatible.
>> And we've been trying over and over to tell you this, but you
>> appear to not be listening.
>
> you ppl need to understand what and where pointers do and go.
We are not "ppl" (primary processor logic? partial procedure linkage?
potato peel leavings?).
Many of us do, in many contexts, ta very much.
> you are all
> going by your own interperetation of what this book or faq says
"this book or faq" is the Standard that *defines* C, and "our interpretation"
is informed by, amongts other things, comments from people who *wrote*
that Standard, implementors of C according to that Standard, and users of
machines other than the x86 family.
>> What do you expect to be to output of the following little
>> program, and how would this support what you are saying?
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int *p;
Oops: p is not initialised; any use of its value is UB. Let's pretend
that it is suitable initialised.
>> printf("%d\n", (int) (p+1-p));
1.
>> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
sizeof(int).
>> return 0;
>> }
>>
>> Do you recognize that p+1 is depending on the pointers type?
>> Again as Richard said, a pointer is _not_ a pointer is not a
>> pointer.
>
> i predict:
> 1
> 4
>
> reguardless whether or not p has been initialized,
No. If p is not initialised, evaluating p gets you undefined behaviour;
nothing is prohibited. Some machines will trap when the likely-illegal
non-value of p gets loaded into their address registers. Kaboom.
> in your formula, p cancels p out leaving 1,
This slapdash "cancellation" conceals the actual defined process.
> the next one, typecasting straight on the pointer
> (no addition with it) has no effect whatsoever but to appease the compiler.
No; the result of a pointer subtraction is of type ptrdiff_t, not int,
so the cast is necessary to ensure that the value is appropropriate
for feeding to %d. [Eg on a machine where sizeof(int)==2, but sizeof(*int)
==4, so sizeof(ptrdiff_t)==4 would be sensible.]
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
> news:3db6776f...@news.nl.net:
>>
>
> ..and ive been saying...?
Something about numerical addresses.
>> It is legal for a pointer to be implemented (in an interpreter, for
>> example) as a (name of object, bytecount into object, size of object)
>> triplet.
>
> what? where?
What part of "in an interpreter, for example" was opaque to you? The
C standard carefully allows implementations to be picky, so that it's
allowed for an implementation to represent an address in a way which
records the entire object pointed into, so that attempts to compute
an address right outside that object can be caught.
>> It is legal for pointers to long and larger to be four bytes large,
>> and char pointers to be five bytes large and consist of a long pointer
>> plus a bytecount.
>
> that is a pointer and something extra(len byte[s]), it in itself is not
> a pointer
No; it's a *C* pointer. On a word-based machine, implementing C
character pointers *requires* some way of encoding both the address of
the word containing the character *and* the position of the character
within that word. If word addresses consume all the bits in a word
pointer, you'll need some extra bits from somewhere.
>> It is _also_ legal for all pointers to be simple numerical indices into
>> memory
>
> uhh, that *IS* a pointer, and what ive been saying all along...
No, that's an *implementation* of a pointer.
>> but if you think this is required you need to stick your head
>> outside your woolly Windows world some day.
>
> what's required?
That pointers be implemented as integers is not required.
willem veenhoven
>
> btw, whats this UB i see here alot?
Unbelievable Behaviour :)
By the way: It may help you to download the Standard and read
it before continuing this rather pointless discussion you're
having with some of the clc regulars.
willem
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
>
> btw, whats this UB i see here alot?
"undefined behaviour", meaning behaviour on which the Standard places
no restrictions whatsoever: an implementation can do whatever it likes.
This includes returning a garbage result, throwing some kind of
exception, terminating your code, wiping the program's store, wiping
the machine's store, wiping the machine's disc, adding one to every
byte with a prime physical RAM address, sending email to the Prime
Minister purporting to come from Willow and Xander, emailing the
contents of your registry, if you have one, to a random selection
of software suppliers, setting fire to your processor chip, setting
fire to your screen, if you have one, setting fire to *you*, having
the Pope bless your pen, causing bowls of petunias to fall from space,
or anything else that your implementation is capable of. The Standard,
at that point, no longer cares.
Of course, *usually* it's something pretty tame: garbage somewhere
or a trap.
That sometimes it is about as tame as an Overlord of Delgon on
amphetamines carrying several axes with a grudge against you for
what you did to his brother, well, the local idiom says "demons
can fly out of your nose".
Incidentally, "undefined behaviour" is thought to be a Bad Thing.
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
> news:3DB65B16...@eton.powernet.co.uk:
>
> > EkriirkE wrote:
<snip>
> >> and the prototype being wild (the ...), accepting (almost) anything,
> >
> > What you can pass via ... is irrelevant. What matters is what the
> > calling function will process correctly.
>
> scanf places data there, its my memory space, i have permissions, i can put
> what i want there, it will be correct
...on your current version of your current compiler, on your current
platform, if you're lucky. That's no way to write portable programs.
> >> and %s
> >> is happy with just the space to read/write, bet it allocated for int,
> >> char, struct, you name it; its there, it exists, and it can use it.
> >
> > Not in a portable and well-defined way.
>
> idunno..., i forgot to add MPW for the Mac to my experience list; it, too,
> reacts as my other experiences do. and that there is a completley
> different architecture
(a) mucking about with pointers like that is just as incorrect on the
Mac as on the PC;
(b) two architectures constitute only a tiny fraction of the
architectures in existence.
> >> whether 'a' had been a char/int/struct pointer, it would have still
> >> pointed the the same place in memory, and if enough space were
> >> allocated at this position for %s to be happy with, thats all that
> >> matters.
> >
> > Consider an implementation which uses registers to pass parameters,
> > and in which pointers to char are placed in different registers to
> > pointers to int. On such an implementation, this code:
> >
> > int d;
> > scanf("%s", &d);
> >
> > will not act as you claim it will act.
>
> ah, but it will..
Ah, but it won't. You have completely failed to consider what I actually
said.
> only you now are limited to entering sizeof(d) bytes...
Nope. In such an implementation as I described, if you tell scanf to
expect a string (by using %s), it will go look in the register for char
*, not the register for int *. Your call will place the address of the
first element of the int array into the int * register, where it will be
ignored in favour of whatever random address lurks in the char *
register.
> as i was trying to explain in many previous posts.. as long as there is the
> room for it, you can do it
...provided you're willing to take the chance that it will not work at
all on some platforms, will give unexpected results on others, and won't
even *compile* on some, as I will now demonstrate:
$ cat > sb.c
#include <stdio.h>
int main(void)
{
int array[10];
scanf("%s", array);
printf("%d\n", array[0]);
return 0;
}
$ gcc -Werror -W -Wall -ansi -pedantic -O2 -o sb sb.c
cc1: warnings being treated as errors
sb.c: In function `main':
sb.c:5: warning: char format, different type arg (arg 2)
$ ls sb
ls: sb: No such file or directory
> if i entered "123" <enter>, making "123\0", and for this *example*,
> *assuming* sizeof(int)=4 (making the maximum i can enter being 3 bytes, or
> i will corrupt and/or crash something), i can recall it in printf
> perfectly;
>
> printf("%s", &d);
>
> and, guess what? you get "123" :o
No, you get undefined behaviour.
> and, FYI, d would now be (in its 'native' [32bit] int form according to
> specs stated above) 0x00333231(3355185) little-endian, 0x31323300
> (825373440) big-endian. again, 100% predictable & reproducable
Nope - it doesn't even compile on at least one of my implementations.
Thus, it is not 100% reproducible behaviour.
> try it. life experience is worth much more than some book
I don't think I'll bother trying it. Life is too short to spend it
repeating other people's mistakes.
<snip>
> >> with the original code:
> >>
> >> void main()
> >
> > Undefined behaviour: main must return int.
>
> weve been thru this
Indeed. It was broken before, and it's still broken now. Why not fix it?
<snip>
Dan Pop
>Incidentally, "undefined behaviour" is thought to be a Bad Thing.
Gratuitously invoked undefined behaviour is thought to be a Bad Thing.
In real world programming, most of us have to invoke it in order to get
some real work done (e.g. by including <unistd.h> or <windows.h>).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Kevin Easton
> Joona I Palaste <pal...@cc.helsinki.fi> wrote in
> news:ap3nob$gsg$1...@oravannahka.helsinki.fi:
>
>> A. Sinan Unur <as...@c-o-r-n-e-l-l.edu> scribbled the following:
>>> EkriirkE <m...@ss.hle> wrote in
>>> news:Xns92AF2B245...@216.148.227.77:
>>
>>> fix your typing.
>>
>> The universal definition of "foreigner" is "non-USA citizen".
>> Therefore, I am a foreigner in my own country.
>
> a-ha! :)
Yes, I suppose the members of A-Ha were foreigners by that definition.
But what about Foreigner - where did they hail from?
- Kevin.
Kevin Easton
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
> news:3db659b0....@news.nl.net:
>
>> EkriirkE <m...@ss.hle> wrote:
>>
>>> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer
>>> is a pointer, it will not be different depending on what type or
>>> variable it's pointing to),
>>
>> And this is where you are really fundamentally wrong. All your other
>> errors, numerous though they may be, are merely assumptions about
>> sizes, unfamiliarity with guarantees that the Standard _does_ make,
>> and so forth. But this is a fundamental error.
>> A pointer is _not_ a pointer is not a pointer. A pointer to int may be
>> a different size to a pointer to char, or differently aligned, or
>> differently laid out.
>
> wrong, type is irrelevant, a pointer is simply a number that is a
> reference to a position in memory
No, *you* are wrong. A pointer to int and a pointer to char are objects
of two different types, and can be of a totally different size. I'm
sure that Chris Torek or someone would be able to provide you with an
example of a machine where these two pointer types in particular are
different sizes, so it's not just a theoretical issue, it's a practical
one.
(At least some architectures are word-aligned, so that a "number that is
a reference to a position in memory" can only reference a WORD of
memory. On this type of architecture, void and char pointers must have
an additional offset into a word, so they're bigger than int pointers.)
The bottom line is this. If you want to use an int buffer in the scanf
situation that started this, you MUST cast it to (char *)!
- Kevin.
Zoran Cutura
> "Zoran Cutura" <Zoran....@daimlerchrysler.com> wrote in news:ap5tj8$jrg
> $1...@news.sns-felb.debis.de:
>
>> Once upon a while EkriirkE <m...@ss.hle> wrote:
>>
>>>
>>>
>>> wrong, type is irrelevant, a pointer is simply a number that is a
>>> reference to a position in memory
>>
>> Can you supply a reference that defines this? Here is what
>> "The Standard" has to say about pointers:
>>
>> 6.7.5.1 Pointer declarators Semantics
>>
>> 1 If, in the declaration "T D1", D1 has the form
>> * type-qualifier-list(opt) D
>> and the type specified for ident in the declaration
>> "T D" is "derived-declarator-type-list T", then the
>> type specified for ident is "derived-declarator-type-list
>> type-qualifier-list pointer to T". For each type
>> qualifier in the list, ident is a so-qualified pointer.
>>
>> 2 For two pointer types to be compatible, both shall be
>> identically qualified and both shall be pointers to
>> compatible types.
>>
>
> 1) huh?
>
> 2) is just a sentance repeating itself: for something to be compatible, it
> needs to be compatible
As it appears you don't only lack at typing but also at reading.
What you have up there is the text of the C standard and as a C
programmer you should be at least trying to understand what is
meant. If we forget about type-qualifiers in the first step,
vers 1 tells you that when you declare an identifier with a
preceding * that this identifier will be called a pointer to ...
Vers 2 OTOH tells you that two pointers are compatible if they
point to objects of compatible type. And that does not mean you
have to be compatible to be compatible in the first place.
>
>> And we've been trying over and over to tell you this, but you
>> appear to not be listening.
>>
>
> you ppl need to understand what and where pointers do and go. you are all
> going by your own interperetation of what this book or faq says
I think most of the people posting in this thread (probably
except me and of course you) have a rather good understanding of
pointers and how they are used correctly. You just seem to be
to ignorant to prove fails in any other way but by trying with an
example from your implementation.
>
>> What do you expect to be to output of the following little
>> program, and how would this support what you are saying?
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int *p;
Oops
int x, *p = &x;
>> printf("%d\n", (int) (p+1-p));
>> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
>> return 0;
>> }
>>
>> Do you recognize that p+1 is depending on the pointers type?
>> Again as Richard said, a pointer is _not_ a pointer is not a
>> pointer.
>>
>
> i predict:
> 1
1
> 4
sizeof(int)
But even if we *assume* that sizeof(int) equals 4, how does this
supply your claim that the type of a pointer is irrelevant, and
that a pointer is just a number?
>
>
> reguardless whether or not p has been initialized, in your formula, p
> cancels p out leaving 1,
You know, C is not math and cancalation are nothing the
programming language is supposed to do. Though optimization may
for sure do so. It doesn't matter, what matters is the result we
get and which must be formally correct.
> the next one, typecasting straight on the pointer
> (no addition with it) has no effect whatsoever but to appease
the compiler.
Again, for substracting teo pointers, both need to be pointing to
compatible object types. You must not substract a int-pointer
from a char-pointer or vice versa.
> however where you have p+1, p being of int will multiply the adder by
> sizeof(int) and add it to p, but if you typecast p pointer type first
> (char *)p, you just made the multiplicand different,
sizeof(char).
Which just disproves your claim that a pointer is a pointer is a
pointer.
> that is
> only affecting your offset/adder ratio, again on this example we are using
> the base of the array as the reference, no matter how you cast it, it will
> not change
On your system, it will probably not change, but it may well have
effects on other systems.
CBFalconer
Also, if you google for Willem's earliest posts on this group, you
will detect a similar intrangibility to yours. The difference is
that Willem did listen and absorb and know appears to know the
difference between portable and machine dependant.
UB refers to undefined behaviour. Anything may happen, and
probably will, given enough trials and machines.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
ke...@hplb.hpl.hp.com
Dan...@ifh.de (Dan Pop) writes:
> In <ap62co$mh3$3...@murdoch.hpl.hp.com> ke...@hplb.hpl.hp.com () writes:
>
>>Incidentally, "undefined behaviour" is thought to be a Bad Thing.
>
> Gratuitously invoked undefined behaviour is thought to be a Bad Thing.
>
> In real world programming, most of us have to invoke it in order to get
> some real work done (e.g. by including <unistd.h> or <windows.h>).
You're quite right, Dan, I was thinking too narrowly.
John Smith
> John Smith <us...@example.net> wrote in news:3DB5B941...@example.net:
>
>
>>>erm, i sometimes do things like this, it always works, look
>>
>><snip ungrammatical drivel>
>>
>>>ok, im done rambling
>>
>>Good, because you're not helping.
>>
>>
>>>-- I'm not a foreigner, honest! I just suck at typing...
>>
>>Look, even your sig's annoying me.
>>
>
>
> dont you love it when ppl are beaten/dont understand, they lash out?
If you mean I don't understand your "English", you're right, I don't.
That's probably because you're too lazy or dumb to form proper
sentences. If, however, you mean I don't understand your extraordinarily
"sophisticated" C, then you're suffering from severe delusions or something.
I take objection to you, twit, for barging in here and arrogantly
spewing utter crap, then having the gall to claim that the foremost
experts in the group are wrong or somehow incapable of grasping your
"brilliance"! Please get lost.
EkriirkE
> In article <Xns92B02B3C2...@204.127.202.16>,
> EkriirkE <m...@ss.hle> writes:
>> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
>> news:3db6776f...@news.nl.net:
>>>
>>> A pointer is an object that addresses another object.
>>
>> ..and ive been saying...?
>
> Something about numerical addresses.
mmhmm
>
>>> It is legal for a pointer to be implemented (in an interpreter, for
>>> example) as a (name of object, bytecount into object, size of object)
>>> triplet.
>>
>> what? where?
>
> What part of "in an interpreter, for example" was opaque to you? The
> C standard carefully allows implementations to be picky, so that it's
> allowed for an implementation to represent an address in a way which
> records the entire object pointed into, so that attempts to compute
> an address right outside that object can be caught.
>
>>> It is legal for pointers to long and larger to be four bytes large,
>>> and char pointers to be five bytes large and consist of a long
pointer
>>> plus a bytecount.
>>
>> that is a pointer and something extra(len byte[s]), it in itself is
not
>> a pointer
>
> No; it's a *C* pointer. On a word-based machine, implementing C
> character pointers *requires* some way of encoding both the address of
> the word containing the character *and* the position of the character
> within that word. If word addresses consume all the bits in a word
> pointer, you'll need some extra bits from somewhere.
>
well, then that is something much like segment:offset then
>>> It is _also_ legal for all pointers to be simple numerical indices
into
>>> memory
>>
>> uhh, that *IS* a pointer, and what ive been saying all along...
>
> No, that's an *implementation* of a pointer.
all these still are just pointing to a location in memory... i still dont
see the point in the original argument here
>
>>> but if you think this is required you need to stick your head
>>> outside your woolly Windows world some day.
>>
>> what's required?
>
> That pointers be implemented as integers is not required.
>
when did i say this? looks like someone else needs to look up "example"
EkriirkE
@yahoo.com:
> willem veenhoven wrote:
>> EkriirkE wrote:
>> >
>> > btw, whats this UB i see here alot?
>>
>> Unbelievable Behaviour :)
>>
>> By the way: It may help you to download the Standard and read
>> it before continuing this rather pointless discussion you're
>> having with some of the clc regulars.
>
> Also, if you google for Willem's earliest posts on this group, you
> will detect a similar intrangibility to yours. The difference is
> that Willem did listen and absorb and know appears to know the
> difference between portable and machine dependant.
>
> UB refers to undefined behaviour. Anything may happen, and
> probably will, given enough trials and machines.
>
ok, thanks (about UB), but untill someone gives me code that proves
otherwise instead of quoting some book... im right
EkriirkE
>
...
>> scanf places data there, its my memory space, i have permissions, i
>> can put what i want there, it will be correct
>
> ...on your current version of your current compiler, on your current
> platform, if you're lucky. That's no way to write portable programs.
i must be *very* lucky ;)
>> >> and %s
>> >> is happy with just the space to read/write, bet it allocated for
>> >> int, char, struct, you name it; its there, it exists, and it can
>> >> use it.
>> >
>> > Not in a portable and well-defined way.
>>
>> idunno..., i forgot to add MPW for the Mac to my experience list; it,
>> too, reacts as my other experiences do. and that there is a
>> completley different architecture
>
> (a) mucking about with pointers like that is just as incorrect on the
> Mac as on the PC;
> (b) two architectures constitute only a tiny fraction of the
> architectures in existence.
they are 2 of the majority, and it seems alot pf peole here like to refer
to long 'dead' architectures just to prove me wrong
>> >> whether 'a' had been a char/int/struct pointer, it would have
>> >> still pointed the the same place in memory, and if enough space
>> >> were allocated at this position for %s to be happy with, thats all
>> >> that matters.
>> >
>> > Consider an implementation which uses registers to pass parameters,
>> > and in which pointers to char are placed in different registers to
>> > pointers to int. On such an implementation, this code:
>> >
>> > int d;
>> > scanf("%s", &d);
>> >
>> > will not act as you claim it will act.
>>
>> ah, but it will..
>
> Ah, but it won't. You have completely failed to consider what I
> actually said.
i dont see why a compiler should do something like "char * is for R1, int *
is for R2, and strucht * for R3" etc...
and using registers to pass for things like scanf/printf is pretty bad,
becasue you have have multiple %'s, you arnt limited to 1, what then
>
>> only you now are limited to entering sizeof(d) bytes...
>
> Nope. In such an implementation as I described, if you tell scanf to
> expect a string (by using %s), it will go look in the register for
> char *, not the register for int *. Your call will place the address
> of the first element of the int array into the int * register, where
> it will be ignored in favour of whatever random address lurks in the
> char * register.
see above
>> as i was trying to explain in many previous posts.. as long as there
>> is the room for it, you can do it
>
> ...provided you're willing to take the chance that it will not work at
> all on some platforms, will give unexpected results on others, and
> won't even *compile* on some, as I will now demonstrate:
>
> $ cat > sb.c
> #include <stdio.h>
> int main(void)
> {
> int array[10];
> scanf("%s", array);
> printf("%d\n", array[0]);
> return 0;
> }
>
> $ gcc -Werror -W -Wall -ansi -pedantic -O2 -o sb sb.c
> cc1: warnings being treated as errors
> sb.c: In function `main':
> sb.c:5: warning: char format, different type arg (arg 2)
> $ ls sb
> ls: sb: No such file or directory
>
(looking up pedantic)... this is just a *compiler * warning* cause by
using pedantic (i think - enlighten me on that), it is not a run-time error
as the others keep insisting will/should happen
>> if i entered "123" <enter>, making "123\0", and for this *example*,
>> *assuming* sizeof(int)=4 (making the maximum i can enter being 3
>> bytes, or i will corrupt and/or crash something), i can recall it in
>> printf perfectly;
>>
>> printf("%s", &d);
>>
>> and, guess what? you get "123" :o
>
> No, you get undefined behaviour.
show me, with code somehow. untill i see otherwise, its right. you people
still have yet to *prove* me wrong
>> try it. life experience is worth much more than some book
>
> I don't think I'll bother trying it. Life is too short to spend it
> repeating other people's mistakes.
>
lol
> <snip>
>
>> >> with the original code:
>> >>
>> >> void main()
>> >
>> > Undefined behaviour: main must return int.
>>
>> weve been thru this
>
> Indeed. It was broken before, and it's still broken now. Why not fix
> it?
>
> <snip>
>
lol
Blah
> >> > btw, whats this UB i see here alot?
> >>
> >> Unbelievable Behaviour :)
> >>
> >> By the way: It may help you to download the Standard and read
> >> it before continuing this rather pointless discussion you're
> >> having with some of the clc regulars.
> >
> > Also, if you google for Willem's earliest posts on this group, you
> > will detect a similar intrangibility to yours. The difference is
> > that Willem did listen and absorb and know appears to know the
> > difference between portable and machine dependant.
> >
> > UB refers to undefined behaviour. Anything may happen, and
> > probably will, given enough trials and machines.
> >
>
> ok, thanks (about UB), but untill someone gives me code that proves
> otherwise instead of quoting some book... im right
You sit down with the Pope to talk about Jesus and you mention that
Jesus invented the Sewing Machine.
The Pope, astonished, asks "Can you show me where it says this in the
Bible?"
You respond "What is this Bible, a book? Just show me that he didn't
invent the Sewing Machine and quit quoting some book."
The Pope, shockingly, is not impressed with your knowledge of the life
of Jesus.
-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----
http://www.newsfeed.com - The #1 Newsgroup Service in the World!
-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----
EkriirkE
> For qualified-Q1-pointer-to-T1 to be compatible with
> qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and T2_
> must be compatible.
>
still dont understand, speak C ;)
>
...
>> you are all
>> going by your own interperetation of what this book or faq says
>
> "this book or faq" is the Standard that *defines* C, and "our
> interpretation" is informed by, amongts other things, comments from
> people who *wrote* that Standard, implementors of C according to that
> Standard, and users of machines other than the x86 family.
ok... but im my examples before, as just stated, they are just examples,
many are being childish, or lack mental capacity to see the *minor* changes
needed to getit to be just as i was explaining on their different platform
>
...
>
> Oops: p is not initialised; any use of its value is UB. Let's pretend
> that it is suitable initialised.
>
it doesnt matter, it is only uninitialized once, having a 'random'/unknown
value thruout the program untill it is changed. it does not change itself
every clock cycle of the cpu
>>> printf("%d\n", (int) (p+1-p));
>
> 1.
..yes
>
>>> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
>
> sizeof(int).
..yes, and as i said, on my system it happens to be 4
>
...
>
> No. If p is not initialised, evaluating p gets you undefined
> behaviour; nothing is prohibited. Some machines will trap when the
> likely-illegal non-value of p gets loaded into their address
> registers. Kaboom.
see above
>
>> in your formula, p cancels p out leaving 1,
>
> This slapdash "cancellation" conceals the actual defined process.
i dont see how, math is math, 1+1 is 2. seeing it in a different light wont
give you 666
>
>> the next one, typecasting straight on the pointer
>> (no addition with it) has no effect whatsoever but to appease the
>> compiler.
>
> No; the result of a pointer subtraction is of type ptrdiff_t, not int,
> so the cast is necessary to ensure that the value is appropropriate
> for feeding to %d. [Eg on a machine where sizeof(int)==2, but
> sizeof(*int) ==4, so sizeof(ptrdiff_t)==4 would be sensible.]
>
p is already as int, and as i said in this buid it happens to be 4, sizeof
(int) works dandy.. and i dont see the reason in throwing ptrdiff_t in
EkriirkE
A. Sinan Unur
204.127.68.17:
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
> news:3db659b0....@news.nl.net:
>
>> EkriirkE <m...@ss.hle> wrote:
>>
>>> if you were to pass 'a', a being a *pointer* ( a pointer is a pointer
>>> is a pointer, it will not be different depending on what type or
>>> variable it's pointing to),
>>
>> And this is where you are really fundamentally wrong.
agreed.
> wrong, type is irrelevant, a pointer is simply a number that is a
> reference to a position in memory
no. a pointer is an abstraction of that concept. that allows you to use
the same addressing abstraction on any platform. the platform specific
details of addressing objects are hidden from you. for this abstraction
to continue to work on a variety of platforms, you have to stick with the
contract specified by the standard.
by the way, you may want to take a look at
http://www.delorie.com/djgpp/doc/dpmi/ch4.1.html
and notice the mention of 48-bit pointers on an Intel platform.
Sinan.
--
A. Sinan Unur
as...@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:u...@ftc.gov
EkriirkE
now that i know what UB is:
>
...
>
> What Ben said, is that
>
> #include <limits.h>
>
> enum {CHAR_T, INT_T, P_CHAR_T, P_INT_T };
>
> void foo(int type, ...)
> {
> va_list ap;
> char *p;
> int i=0;
>
> va_start(ap, type);
>
> switch(type) {
> case P_CHAR_T: {
> p = va_arg(ap, (char *));
> break;
> }
> case P_INT_T: {
> int *ip;
> ip = va_arg(ap, (int *));
> p = (char *) ip;
> break;
chould be shortened to p=(char *)va_arg(ap, (int *)); or then to (as to
think to be UB) p=va_arg(ap, (char *));
which could be traced as p=(char *)(int *)&x;
again, a pointer is a pointer is a pointer
> }
> }
>
> while(i < sizeof(int))
> p[i++] = 1;
>
> va_end(ap);
> }
>
>
> void bar(void)
> {
> int x;
>
> foo(P_INT_T, &x); /* does not invode UB */
right
> foo(P_CHAR_T, (char *) &x); /* does not invode UB */
right
> foo(P_CHAR_T, &x); /* does invode UB */
au contraire (sp)
p == &x in foo. and the while loop would make x=0x01010101 (if sizeof
(int)==4)
and if you were to be trying to use the value at the memory (printf("%d",
*p)), the value would be the 1st byte of x
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
> news:3DB6888A...@eton.powernet.co.uk:
> >
> ...
> >> scanf places data there, its my memory space, i have permissions, i
> >> can put what i want there, it will be correct
> >
> > ...on your current version of your current compiler, on your current
> > platform, if you're lucky. That's no way to write portable programs.
>
> i must be *very* lucky ;)
Lucky to be so ignorant of portable programming? If (as appears to be
the case) you're not interested in C itself, as opposed to "the way some
implementors implement C compilers on my platform", why are you reading
comp.lang.c?
> >> >> and %s
> >> >> is happy with just the space to read/write, bet it allocated for
> >> >> int, char, struct, you name it; its there, it exists, and it can
> >> >> use it.
> >> >
> >> > Not in a portable and well-defined way.
> >>
> >> idunno..., i forgot to add MPW for the Mac to my experience list; it,
> >> too, reacts as my other experiences do. and that there is a
> >> completley different architecture
> >
> > (a) mucking about with pointers like that is just as incorrect on the
> > Mac as on the PC;
> > (b) two architectures constitute only a tiny fraction of the
> > architectures in existence.
>
> they are 2 of the majority,
Really? Try this little experiment. Itemise *all* the computers in your
home. Include your Macs, your PCs, your palmtops, and your games
computers, obviously, but don't forget to include your pocket
calculators, digital watches, microwave ovens, car engine management
systems, dishwashers, washing machines, and all the other embedded
systems you have lurking in your home. And hey, guess what? Much, maybe
even most, of that kit is programmed in C. Fortunately, the people who
do that kind of stuff tend to have a better grasp than you of what
portable C programming really means.
> and it seems alot pf peole here like to refer
> to long 'dead' architectures just to prove me wrong
No, we're not trying to prove you wrong. We *know* you're wrong. We're
just trying to help you to *understand* that you're wrong.
<snip>
>
> i dont see why a compiler should do something like "char * is for R1, int *
> is for R2, and strucht * for R3" etc...
Can you show me the part of the ISO C Standard which forbids such an
implementation?
> and using registers to pass for things like scanf/printf is pretty bad,
> becasue you have have multiple %'s, you arnt limited to 1, what then
<shrug> You use more registers. Some machines have rather more registers
than the PC, you see. Think big iron, for example.
<snip>
> > $ gcc -Werror -W -Wall -ansi -pedantic -O2 -o sb sb.c
> > cc1: warnings being treated as errors
> > sb.c: In function `main':
> > sb.c:5: warning: char format, different type arg (arg 2)
> > $ ls sb
> > ls: sb: No such file or directory
> >
>
> (looking up pedantic)... this is just a *compiler * warning*
It's a diagnostic. Note that no binary was produced.
> cause by
> using pedantic (i think - enlighten me on that), it is not a run-time error
> as the others keep insisting will/should happen
How can you have a runtime error if the compiler reckons the code is so
broken that it refuses to produce a binary?
> >> if i entered "123" <enter>, making "123\0", and for this *example*,
> >> *assuming* sizeof(int)=4 (making the maximum i can enter being 3
> >> bytes, or i will corrupt and/or crash something), i can recall it in
> >> printf perfectly;
> >>
> >> printf("%s", &d);
> >>
> >> and, guess what? you get "123" :o
> >
> > No, you get undefined behaviour.
>
> show me, with code somehow. untill i see otherwise, its right.
Nope. Your misconceptions of the C language do not define a program's
behaviour. The ISO C Standard does, or does not, depending on the
program's correctness.
> you people
> still have yet to *prove* me wrong
Oh well, if you insist:
7.19.6.2(10) of ISO/IEC 9899:1999 says "Unless assignment suppression
was indicated by a *, the result of the conversion is placed in the
object pointed to by the first argument following the format argument
that has not already received a conversion result. If this object does
not have an appropriate type, or if the result of the conversion cannot
be represented in the object, the behavior is undefined."
Therefore you are wrong. QED.
Richard Heathfield
>
> > For qualified-Q1-pointer-to-T1 to be compatible with
> > qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and T2_
> > must be compatible.
> >
>
> still dont understand, speak C ;)
He is.
> ...
> >> you are all
> >> going by your own interperetation of what this book or faq says
> >
> > "this book or faq" is the Standard that *defines* C, and "our
> > interpretation" is informed by, amongts other things, comments from
> > people who *wrote* that Standard, implementors of C according to that
> > Standard, and users of machines other than the x86 family.
>
> ok... but im my examples before, as just stated, they are just examples,
> many are being childish, or lack mental capacity to see the *minor* changes
> needed to getit to be just as i was explaining on their different platform
The only changes needed to get it to work on *every* platform are those
changes that will bring it into line with the definition of the
language.
> ...
> >
> > Oops: p is not initialised; any use of its value is UB. Let's pretend
> > that it is suitable initialised.
> >
>
> it doesnt matter, it is only uninitialized once, having a 'random'/unknown
> value thruout the program untill it is changed.
It does matter. Using an indeterminate value invokes UB.
> it does not change itself
> every clock cycle of the cpu
Chapter and verse from the Standard to support that claim, please.
<snip>
> >
> > No. If p is not initialised, evaluating p gets you undefined
> > behaviour; nothing is prohibited. Some machines will trap when the
> > likely-illegal non-value of p gets loaded into their address
> > registers. Kaboom.
>
> see above
6.7.8(10) of the Standard says: "If an object that has automatic storage
duration is not initialized explicitly, its value is indeterminate."
Using an indeterminate value invokes UB.
> >> in your formula, p cancels p out leaving 1,
> >
> > This slapdash "cancellation" conceals the actual defined process.
>
> i dont see how, math is math,
C isn't math, though.
> 1+1 is 2. seeing it in a different light wont
> give you 666
Please predict the output of this program (in terms of the *relative*
values of p and q). Then compile and run it.
#include <stdio.h>
int main(void)
{
int i[2] = {6, 42};
int *p = i;
int *q = p + 1;
printf("%p: %d\n", (void *)p, *p);
printf("%p: %d\n", (void *)q, *q);
return 0;
}
Pointer arithmetic shows that adding 1 doesn't always mean quite what
one intuitively expects it to mean.
> >> the next one, typecasting straight on the pointer
> >> (no addition with it) has no effect whatsoever but to appease the
> >> compiler.
> >
> > No; the result of a pointer subtraction is of type ptrdiff_t, not int,
> > so the cast is necessary to ensure that the value is appropropriate
> > for feeding to %d. [Eg on a machine where sizeof(int)==2, but
> > sizeof(*int) ==4, so sizeof(ptrdiff_t)==4 would be sensible.]
> >
>
> p is already as int, and as i said in this buid it happens to be 4, sizeof
> (int) works dandy.. and i dont see the reason in throwing ptrdiff_t in
You don't? But he just explained it to you! Try reading his explanation
again.
EkriirkE
> EkriirkE wrote:
>>
>> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
>> news:3DB6888A...@eton.powernet.co.uk:
>> >
>> ...
>> >> scanf places data there, its my memory space, i have permissions,
>> >> i can put what i want there, it will be correct
>> >
>> > ...on your current version of your current compiler, on your
>> > current platform, if you're lucky. That's no way to write portable
>> > programs.
>>
>> i must be *very* lucky ;)
>
> Lucky to be so ignorant of portable programming? If (as appears to be
> the case) you're not interested in C itself, as opposed to "the way
> some implementors implement C compilers on my platform", why are you
> reading comp.lang.c?
>
"my implementation of C" is still C
>
>> >> >> and %s
>> >> >> is happy with just the space to read/write, bet it allocated
>> >> >> for int, char, struct, you name it; its there, it exists, and
>> >> >> it can use it.
>> >> >
>> >> > Not in a portable and well-defined way.
>> >>
>> >> idunno..., i forgot to add MPW for the Mac to my experience list;
>> >> it, too, reacts as my other experiences do. and that there is a
>> >> completley different architecture
>> >
>> > (a) mucking about with pointers like that is just as incorrect on
>> > the Mac as on the PC;
>> > (b) two architectures constitute only a tiny fraction of the
>> > architectures in existence.
>>
>> they are 2 of the majority,
>
> Really? Try this little experiment. Itemise *all* the computers in
> your home. Include your Macs, your PCs, your palmtops, and your games
> computers, obviously, but don't forget to include your pocket
> calculators, digital watches, microwave ovens, car engine management
> systems, dishwashers, washing machines, and all the other embedded
> systems you have lurking in your home. And hey, guess what? Much,
> maybe even most, of that kit is programmed in C. Fortunately, the
> people who do that kind of stuff tend to have a better grasp than you
> of what portable C programming really means.
>
i said OF THE majority, not THE majority
>
>> and it seems alot pf peole here like to refer
>> to long 'dead' architectures just to prove me wrong
>
> No, we're not trying to prove you wrong. We *know* you're wrong. We're
> just trying to help you to *understand* that you're wrong.
>
and yet you are failing just as im failing
>
> <snip>
>>
>> i dont see why a compiler should do something like "char * is for R1,
>> int * is for R2, and strucht * for R3" etc...
>
> Can you show me the part of the ISO C Standard which forbids such an
> implementation?
>
nope, i have never and dont care to read it, besides i was just stating
that that seemed a strange/unfamilliar method
>
>> and using registers to pass for things like scanf/printf is pretty
>> bad, becasue you have have multiple %'s, you arnt limited to 1, what
>> then
>
> <shrug> You use more registers. Some machines have rather more
> registers than the PC, you see. Think big iron, for example.
>
yes, but they are still limited (i dont know big iron), and the pc is not
my only platform. designating certain registers for certain types of
parameters is just too constraining, becasue then you would be limited the
number of parameters by the platform... and that isnt very portable
>
> <snip>
>
>> > $ gcc -Werror -W -Wall -ansi -pedantic -O2 -o sb sb.c
>> > cc1: warnings being treated as errors
>> > sb.c: In function `main':
>> > sb.c:5: warning: char format, different type arg (arg 2)
>> > $ ls sb
>> > ls: sb: No such file or directory
>> >
>>
>> (looking up pedantic)... this is just a *compiler * warning*
>
> It's a diagnostic. Note that no binary was produced.
note -Werror
>
>> cause by
>> using pedantic (i think - enlighten me on that), it is not a run-time
>> error as the others keep insisting will/should happen
>
> How can you have a runtime error if the compiler reckons the code is
> so broken that it refuses to produce a binary?
see above
>
...
>>> No, you get undefined behaviour.
>>
>> show me, with code somehow. untill i see otherwise, its right.
>
> Nope. Your misconceptions of the C language do not define a program's
> behaviour. The ISO C Standard does, or does not, depending on the
> program's correctness.
that doesnt make any sense to what i replied
>
>> you people
>> still have yet to *prove* me wrong
>
> Oh well, if you insist:
>
> 7.19.6.2(10) of ISO/IEC 9899:1999 says "Unless assignment suppression
> was indicated by a *, the result of the conversion is placed in the
> object pointed to by the first argument following the format argument
> that has not already received a conversion result. If this object does
> not have an appropriate type, or if the result of the conversion
> cannot be represented in the object, the behavior is undefined."
>
> Therefore you are wrong. QED.
>
> <snip>
>
again with the quoting.. no one is giving me real life examples. is it
because you are getting the results i expect and dont wish to come to the
truth?
Richard Heathfield
>
<snip>
>
> "my implementation of C" is still C
No, it's not. C is a language. Your implementation of it is *not* a
language, but an implementation of that language. It does not define the
language wrt the rest of the world.
<snip>
> >> >> idunno..., i forgot to add MPW for the Mac to my experience list;
> >> >> it, too, reacts as my other experiences do. and that there is a
> >> >> completley different architecture
> >> >
> >> > (a) mucking about with pointers like that is just as incorrect on
> >> > the Mac as on the PC;
> >> > (b) two architectures constitute only a tiny fraction of the
> >> > architectures in existence.
> >>
> >> they are 2 of the majority,
> >
> > Really? Try this little experiment. Itemise *all* the computers in
> > your home. Include your Macs, your PCs, your palmtops, and your games
> > computers, obviously, but don't forget to include your pocket
> > calculators, digital watches, microwave ovens, car engine management
> > systems, dishwashers, washing machines, and all the other embedded
> > systems you have lurking in your home. And hey, guess what? Much,
> > maybe even most, of that kit is programmed in C. Fortunately, the
> > people who do that kind of stuff tend to have a better grasp than you
> > of what portable C programming really means.
> >
>
> i said OF THE majority, not THE majority
That's like saying Wednesday is "of the majority" of weekdays. It's a
meaningless claim.
> >> and it seems alot pf peole here like to refer
> >> to long 'dead' architectures just to prove me wrong
> >
> > No, we're not trying to prove you wrong. We *know* you're wrong. We're
> > just trying to help you to *understand* that you're wrong.
> >
>
> and yet you are failing just as im failing
Alas, it does indeed appear that you are determined not to understand.
>
> >
> > <snip>
> >>
> >> i dont see why a compiler should do something like "char * is for R1,
> >> int * is for R2, and strucht * for R3" etc...
> >
> > Can you show me the part of the ISO C Standard which forbids such an
> > implementation?
>
> nope, i have never and dont care to read it,
If you can't even be bothered to read the C language definition, why
should we pay any attention to your views on what is valid and invalid
in that language?
> besides i was just stating
> that that seemed a strange/unfamilliar method
You ain't seen nuffin' yet.
> >> and using registers to pass for things like scanf/printf is pretty
> >> bad, becasue you have have multiple %'s, you arnt limited to 1, what
> >> then
> >
> > <shrug> You use more registers. Some machines have rather more
> > registers than the PC, you see. Think big iron, for example.
> >
>
> yes, but they are still limited (i dont know big iron),
Why limited? If you run out of registers (unlikely, that, on a
mainframe), you can always spill over into a parameter block area of
some kind.
> and the pc is not
> my only platform. designating certain registers for certain types of
> parameters is just too constraining, becasue then you would be limited the
> number of parameters by the platform...
Why?
> and that isnt very portable
As long as the implementation works and conforms to the Standard, it is
a suitable place for portable programs to roost.
> > <snip>
> >
> >> > $ gcc -Werror -W -Wall -ansi -pedantic -O2 -o sb sb.c
> >> > cc1: warnings being treated as errors
> >> > sb.c: In function `main':
> >> > sb.c:5: warning: char format, different type arg (arg 2)
> >> > $ ls sb
> >> > ls: sb: No such file or directory
> >> >
> >>
> >> (looking up pedantic)... this is just a *compiler * warning*
> >
> > It's a diagnostic. Note that no binary was produced.
>
> note -Werror
Sure. That's *part* of the C compiler. It's one of the switches on the
front - a switch I chose to use. My case stands.
>
> >
> >> cause by
> >> using pedantic (i think - enlighten me on that), it is not a run-time
> >> error as the others keep insisting will/should happen
> >
> > How can you have a runtime error if the compiler reckons the code is
> > so broken that it refuses to produce a binary?
>
> see above
There exists a conforming compiler which refuses to compile your code.
Your code is broken. It is not merely pining for the fjords.
> ...
> >>> No, you get undefined behaviour.
> >>
> >> show me, with code somehow. untill i see otherwise, its right.
> >
> > Nope. Your misconceptions of the C language do not define a program's
> > behaviour. The ISO C Standard does, or does not, depending on the
> > program's correctness.
>
> that doesnt make any sense to what i replied
Yes, it does. Your position is that you're right until proven wrong, but
that position is untenable. The Standard is right *by definition*.
>
> >
> >> you people
> >> still have yet to *prove* me wrong
> >
> > Oh well, if you insist:
> >
> > 7.19.6.2(10) of ISO/IEC 9899:1999 says "Unless assignment suppression
> > was indicated by a *, the result of the conversion is placed in the
> > object pointed to by the first argument following the format argument
> > that has not already received a conversion result. If this object does
> > not have an appropriate type, or if the result of the conversion
> > cannot be represented in the object, the behavior is undefined."
> >
> > Therefore you are wrong. QED.
> >
> > <snip>
> >
>
> again with the quoting.. no one is giving me real life examples.
I don't need to. The language definition defines the language. Duh.
> is it
> because you are getting the results i expect and dont wish to come to the
> truth?
I'm showing you the truth. Whether you choose to realise the fact is
entirely up to you.
Mark McIntyre
<m...@ss.hle> wrote:
>scanf places data there, its my memory space, i have permissions, i can put
>what i want there, it will be correct
you allocated memory for a particular type of object. The pointer for
that object may have a certain alignment. Putting some other type
there may simply not work because its wrongly aligned. The OS may
raise an exception.
You've been lucky so far. All the H/W you've worked on has been easy
about alignment. Don't push that luck
By hte way, you ought to leave CLC. you clearly have No interest in
learning C, only in learning how to use your specific hardware. So why
not go to a specific hardware group? You;re only going to get roasted
here for continuing to spout crap and rubbish.
>>> and %s
>>> is happy with just the space to read/write, bet it allocated for int,
>>> char, struct, you name it; its there, it exists, and it can use it.
>>
>> Not in a portable and well-defined way.
>
>idunno..., i forgot to add MPW for the Mac to my experience list; it, too,
>reacts as my other experiences do. and that there is a completley
>different architecture
Irrelevant. You could try it on every Os you know, and that would
still not be relevant. The C standard says that you cannot passthe
wrong type of object to a function. Thats all there is to it.
>> Consider an implementation which uses registers to pass parameters,
>> and in which pointers to char are placed in different registers to
>> pointers to int. On such an implementation, this code:
>>
>> int d;
>> scanf("%s", &d);
>>
>> will not act as you claim it will act.
>
>ah, but it will.. only you now are limited to entering sizeof(d) bytes...
No it won't. Because to d is stored in one register, but scanf,
expecting a char*, will look in another one. Blam
>if i entered "123" <enter>, making "123\0", and for this *example*,
>*assuming* sizeof(int)=4 (making the maximum i can enter being 3 bytes, or
>i will corrupt and/or crash something), i can recall it in printf
>perfectly;
Nope. You just wrote to memory that does not belong to you.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Mark McIntyre
<m...@ss.hle> wrote:
>look up the word "example"
look up the words "portable" and "standard". And while you're at it
"topical" and "stubborn idiot".
Any more of this and you're going to be plonked by many people. Do
your self a favour, and LISTEN to those with more knowledge than you
have.
Mark McIntyre
<m...@ss.hle> wrote:
>r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
>news:3db659b0....@news.nl.net:
>
>>
>> And this is where you are really fundamentally wrong. All your other
>> errors, numerous though they may be, are merely assumptions about
>> sizes, unfamiliarity with guarantees that the Standard _does_ make,
>> and so forth. But this is a fundamental error.
>> A pointer is _not_ a pointer is not a pointer. A pointer to int may be
>> a different size to a pointer to char, or differently aligned, or
>> differently laid out.
>
>wrong, type is irrelevant, a pointer is simply a number that is a
>reference to a position in memory
You are so incredibly wrong, its laughable.
Stop it now. You are making a complete and utter fool of yourself.
>some_int_pointer was already "defined" by scanf, it has a 100%
>predictability
Its clear that this entire debate is totally over your head. Go away,
learn more, come back when you've gained some knowledge instead of
nonsense.
Mark McIntyre
<m...@ss.hle> wrote:
>ke...@hplb.hpl.hp.com () wrote in news:ap61pg$mh3$2...@murdoch.hpl.hp.com:
>
>> No; it's a *C* pointer. On a word-based machine, implementing C
>> character pointers *requires* some way of encoding both the address of
>> the word containing the character *and* the position of the character
>> within that word. If word addresses consume all the bits in a word
>> pointer, you'll need some extra bits from somewhere.
>>
>
>well, then that is something much like segment:offset then
possibly. And is it an integer value as you claim? No.
>>>> It is _also_ legal for all pointers to be simple numerical indices
>into
>>>> memory
>>>
>>> uhh, that *IS* a pointer, and what ive been saying all along...
>> No, that's an *implementation* of a pointer.
>
>all these still are just pointing to a location in memory... i still dont
>see the point in the original argument here
The point is, you're a fuckwit with no knowledge at all. Its pointless
trying to educate you because you have no interest in learning.
If you _want_ to learn, try reading what people say. Let me say it
again
A pointer is merely a way of finding an object.
That could be a simple numerical offset into hte entire memory of hte
machine.
Or it could be a pair of values eg the ID of hte virtual machine, and
the offset into its virtual memory,
Or it could be something totally different.
If you think that windows has a flat integer pointer memory model then
you know f*ck all about windows memory management by the way.
>> That pointers be implemented as integers is not required.
>>
>when did i say this? looks like someone else needs to look up "example"
EkriirkE <m...@ss.hle> wrote:
> wrong, type is irrelevant, a pointer is simply a number that is a
> reference to a position in memory
Someone needs to look up "idiot"
EkriirkE
>
...
>> i said OF THE majority, not THE majority
>
> That's like saying Wednesday is "of the majority" of weekdays. It's a
> meaningless claim.
>
what? how? 1/7 is not a mojority
>
>> and yet you are failing just as im failing
>
> Alas, it does indeed appear that you are determined not to understand.
"Alas, it does indeed appear that you are determined not to understand."
>
...
>> besides i was just stating
>> that that seemed a strange/unfamilliar method
>
> You ain't seen nuffin' yet.
>
heh
>
> Why limited? If you run out of registers (unlikely, that, on a
> mainframe), you can always spill over into a parameter block area of
> some kind.
you mean... a stack?
>
>> and the pc is not
>> my only platform. designating certain registers for certain types of
>> parameters is just too constraining, becasue then you would be
>> limited the number of parameters by the platform...
>
> Why?
uhh if you have, say, only 10 registers diesignated for char *, you are
limited to 10 %s
>
>> and that isnt very portable
>
> As long as the implementation works and conforms to the Standard, it
> is a suitable place for portable programs to roost.
>
>
...
>> note -Werror
>
> Sure. That's *part* of the C compiler. It's one of the switches on the
> front - a switch I chose to use. My case stands.
and im stubborn? :P
>
...
>> > How can you have a runtime error if the compiler reckons the code
>> > is so broken that it refuses to produce a binary?
>>
>> see above
>
> There exists a conforming compiler which refuses to compile your code.
> Your code is broken. It is not merely pining for the fjords.
>
then dont use that compiler, its still may be portable on that platform,
but not with that particular compiler (see bottom code for the 'bypass')
>
...
>> again with the quoting.. no one is giving me real life examples.
>
> I don't need to. The language definition defines the language. Duh.
>
>
>> is it
>> because you are getting the results i expect and dont wish to come to
>> the truth?
>
> I'm showing you the truth. Whether you choose to realise the fact is
> entirely up to you.
>
sigh.. just try it and see the light. try this to appease the compiler
$ cat > sb.c
#include <stdio.h>
int main(void)
{
int array[10];
scanf("%s", (char *)array);
printf("%d\n", array[0]);
return 0;
}
and input
123 <enter>
causing (if array were char) array to contain "123\0" and the rest
undefined/uninitialized
and if sizeof(int)==4 it will print "3355185" on little-endian machines and
825373440 on big-endian.
if sizeof(int)==2, it will display "12849" LE, "12594" BE
if sizeof(int)==1, it will display "49"
etc. 100% defined, predictable, reproducable
Mark McIntyre
<m...@ss.hle> wrote:
don't snip attributions, its rude
>chris the hedgehog said:
>> "this book or faq" is the Standard that *defines* C, and "our
>> interpretation" is informed by, amongts other things, comments from
>> people who *wrote* that Standard, implementors of C according to that
>> Standard, and users of machines other than the x86 family.
>
>ok... but im my examples before, as just stated, they are just examples,
>many are being childish, or lack mental capacity to see the *minor* changes
>needed to getit to be just as i was explaining on their different platform
You arrogant prat. The people being "childish" or "lacking mental
capacity" are bloody experts in C. You are such a total idiot.
>> Oops: p is not initialised; any use of its value is UB. Let's pretend
>> that it is suitable initialised.
>
>it doesnt matter,
What? Please shut the fuck up and go read the bloody standard.
Accessing an uninitialised variable is not permitted.
>it is only uninitialized once, having a 'random'/unknown
>value thruout the program untill it is changed. it does not change itself
>every clock cycle of the cpu
Do you know that? how? Does the C standard say so? And even if it were
true, so what?
>> No. If p is not initialised, evaluating p gets you undefined
>> behaviour; nothing is prohibited. Some machines will trap when the
>> likely-illegal non-value of p gets loaded into their address
>> registers. Kaboom.
>
>see above
See above. Idiot.
>>> the next one, typecasting straight on the pointer
>>> (no addition with it) has no effect whatsoever but to appease the
>>> compiler.
>>
>> No; the result of a pointer subtraction is of type ptrdiff_t, not int,
>> so the cast is necessary to ensure that the value is appropropriate
>> for feeding to %d. [Eg on a machine where sizeof(int)==2, but
>> sizeof(*int) ==4, so sizeof(ptrdiff_t)==4 would be sensible.]
>>
>
>p is already as int, and as i said in this buid it happens to be 4, sizeof
>(int) works dandy.. and i dont see the reason in throwing ptrdiff_t in
because you're REQUIRED TO. The difference between pointers has type
ptrdiff_t. Not int.
For cripes sakes. What is this, elementary understanding for idiots? .
Mark McIntyre
<m...@ss.hle> wrote:
>see post yours is in reply to
Fuckwit.
Mark McIntyre
<m...@ss.hle> wrote:
>ok, thanks (about UB), but untill someone gives me code that proves
>otherwise instead of quoting some book... im right
What a fatuous remark. The language is defined by a standard. Code
samples don't define it, nor does your broken comprehension.
You're wrong. Be adult enough to admit it.
Ben Pfaff
> sigh.. just try it and see the light. try this to appease the compiler
>
> $ cat > sb.c
> #include <stdio.h>
> int main(void)
> {
> int array[10];
> scanf("%s", (char *)array);
> printf("%d\n", array[0]);
> return 0;
> }
>
>
> and input
> 123 <enter>
This invokes undefined behavior because `int' is allowed to have
"trap representations" which, when accessed, cause the program to
stop running, etc.
> causing (if array were char) array to contain "123\0" and the rest
> undefined/uninitialized
Yes.
> and if sizeof(int)==4 it will print "3355185" on little-endian machines and
> 825373440 on big-endian.
You're making a lot of assumptions here. First, that the machine
has 8-bit bytes and uses the ASCII character set or similar.
Second, that your input doesn't produce a trap representation.
Third, that the machine is in fact little-endian or big-endian
(the Standard doesn't require it; what if you're running on a
Vax?). And so on...
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless
Chris Torek
"EkriirkE" is passing the address of some memory as "int *" instead of
"char *", e.g.:
#include <stdio.h>
#include <stdlib.h>
void f(void) {
int *p = malloc(100); /* bug: should be "char *p" */
if (scanf("%99s", p) == 1)
printf("got %s\n", p);
/* note memory leak: we never free(p) */
}
which actually works on some implementations.
In article <Xns92B0167B3...@204.127.68.17>
EkriirkE <m...@ss.hle> writes:
>type is irrelevant, a pointer is simply a number that is a
>reference to a position in memory
Unfortuantely for you, in C, a pointer is *not* just "the number
of some location in memory", and if you take the example code
above for f() -- which works on Intel machines -- and try it on
a Data General Eclipse, it will in fact fail. It will compile,
but when you try to run it, you will get a runtime exception.
The Data General is a "word-addressed" machine, meaning that its
native pointer format *cannot* point to the individual bytes making
up a (16-bit) word. (It inherits this characteristic from the Data
General Nova, a rather interesting machine that also apparently
used only half the opcodes from a 74LS2XX or 74LS3XX ALU chip that
was available in the early 1980s. I never used a Nova myself, but
worked with people who did.) The designers of the Eclipse did
*want* to be able to access individual 8-bit-bytes with ordinary
machine instructions, though, so they added a new non-Nova pointer
format, the "byte pointer". They chose to make both pointers 32
bits wide.
The format of word pointers was based on that of the Nova, and
looked something like this:
IAAAAAAAWWWWWWWWWWWWWWWWWWWWWWWW
The "I" bit is an "indirection" bit, not used by the C compiler.
The "A" bits have to do with access control and are actually split
into ring and segment numbers; I have forgotten the details, and
in any case they do not matter in this case. The remaining bits,
labeled "W" above, provide the address of the 16-bit memory word
holding the value (or the lowest address of multiple words holding
a 32- or 64-bit value).
Notice that there is *no way* to specify which 8-bit byte you want,
if you have only a "word pointer"; it points to an entire 16-bit
word. Hence the need for a new byte-pointer format, which they
chose to do as follows:
IAAAAAAAWWWWWWWWWWWWWWWWWWWWWWWW [word pointer]
AAAAAAAWWWWWWWWWWWWWWWWWWWWWWWWB [byte pointer]
Note that the byte pointer discards the "I" bit entirely -- it was
not being used by the C compiler anyway -- and shifts all the other
bits left one, then adds a new bit "B" at the bottom. If B=0, the
byte pointer points to the left-hand byte (I think -- maybe it was
the right-hand byte; it has been at least 15 years), otherwise it
points to the other byte.
On the Data General, then, there is an actual machine instruction
used to convert from "byte pointer" to "word pointer": "shift right
one bit, discarding the B bit and introducing a 0 in the I bit".
Likewise, an actual machine instruction converts from "word pointer"
to "byte pointer": "shift left one bit, discarding the I bit and
introducing a 0 in the B bit."
Since malloc() returns a "char *" -- a byte pointer -- it must
always make sure to return one in which bit B is 0, because malloc()'s
return value can be assigned to an "int *" -- a word pointer --
which will discard the B bit. A later call to free() will convert
the word pointer back to a byte pointer, with B=0, but since malloc()
makes sure to produce pointers with B=0, this is OK.
Let us take a look at function f() again, then, and consider the
machine code produced on a system very much like the Data General
(but using IA32-like mnemonics and so on):
void f(void) {
int *p = malloc(100); /* bug: should be "char *p" */
if (scanf("%99s", p) == 1)
printf("got %s\n", p);
}
This might become:
# strings
.rodata
.L1: .asciz "%99s"
.L2: .asciz "got %s\n"
.wordalign
.text
f:
sub $4,%sp # make room for local variable "p"
# p = malloc(100)
push $100
call malloc # malloc(100)
lshr $1,r0 # convert byte pointer in r0 to word pointer
mov r0,(%sp) # set p = result
# scanf("%99s", p)
push r0 # arg 2 to scanf
leab $.L1,r0 # arg 1 to scanf: load eff. address of byte
push r0
call scanf
# if (... == 1)
cmp r0,$1
bne .L3
# printf("got %s\n", p)
mov (%sp),r0 # retrieve p
push r0 # arg 2 to printf
leab $.L2,r0 # arg 1 to printf
push r0
call printf
.L3: add $4,%sp
ret
The problem is that "lshr" -- logical shift right -- of r0. This
converted the byte pointer malloc() returned to a word pointer to
store in "p", and the rest of the calls (to scanf and printf) passed
on that shifted value. But printf and scanf, on seeing a "%s",
expect to retrieve a byte pointer. They will NOT do the corresponding
"shl" to convert the word pointer back to a byte pointer.
We had code like this[%] running on our VAX and Pyramid and Sun
machines when we got the Data General. We compiled it there and
it broke. The reason it broke is that our code was wrong. When
we fixed our code, it still worked on our VAXes and Pyramid and
Suns, but now it worked on the Eclipse too.
In other words, I am speaking from experience. This code DOES NOT
WORK on some systems, and the C standards *say* it does not *have*
to work -- but if you make two small changes, it *does* have to work:
void f(void) {
int *p = malloc(100);
if (scanf("%99s", (char *)p) == 1)
printf("got %s\n", (char *)p);
}
and indeed, this code (as silly as it is) DOES work on the Eclipse,
because the two "shr" instructions missing from the first version
show up in the second.
[% Nothing quite this silly, but code that passed "int *"s where
"char *"s were needed, and vice versa. The thing that bit us worst
involved qsort().]
Of course, it works even better to just use "char *p", which avoids
both the one shl and two shr instructions entirely. It is not only
easier to read, it also runs faster. (Assuming no optimization
anyway.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA Domain: to...@bsdi.com
http://67.40.109.61/torek/ (for the moment)
(you probably cannot email me -- spam has effectively killed email)
Mark McIntyre
<m...@ss.hle> wrote:
>Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
>news:3DB71ECD...@eton.powernet.co.uk:
>
>>
>...
>>> i said OF THE majority, not THE majority
>>
>> That's like saying Wednesday is "of the majority" of weekdays. It's a
>> meaningless claim.
>>
>
>what? how? 1/7 is not a mojority
he said OF THE majority, not THE majority.
For goodness' sake.
>>> and yet you are failing just as im failing
>>
>> Alas, it does indeed appear that you are determined not to understand.
>
>
>"Alas, it does indeed appear that you are determined not to understand."
And you can echo too. Golly.
>>> besides i was just stating
>>> that that seemed a strange/unfamilliar method
>>
>> You ain't seen nuffin' yet.
>
>heh
Gark?
>> Why limited? If you run out of registers (unlikely, that, on a
>> mainframe), you can always spill over into a parameter block area of
>> some kind.
>
>you mean... a stack?
no, a parameter block area.
>>> and the pc is not
>>> my only platform. designating certain registers for certain types of
>>> parameters is just too constraining, becasue then you would be
>>> limited the number of parameters by the platform...
>>
>> Why?
>
>uhh if you have, say, only 10 registers diesignated for char *, you are
>limited to 10 %s
after which you put any more into the parameter block.
For crying out loud, _I've_ used hardware that did this. ISTR that
some intel H/W does it, some Sparc hardware, possibly some other RISC
chips.
>>> note -Werror
>>
>> Sure. That's *part* of the C compiler. It's one of the switches on the
>> front - a switch I chose to use. My case stands.
>
>and im stubborn? :P
there's stubborn, and there's "too stubborn to realise when you're
wrong"
>>> > How can you have a runtime error if the compiler reckons the code
>>> > is so broken that it refuses to produce a binary?
>>>
>>> see above
>>
>> There exists a conforming compiler which refuses to compile your code.
>> Your code is broken. It is not merely pining for the fjords.
>>
>
>then dont use that compiler, its still may be portable on that platform,
>but not with that particular compiler (see bottom code for the 'bypass')
If a compiler conforms, and won't compile your code, you suggest using
a different one that will.
You ask someone to shoot a nun, and he won't. So you go find another
person and ask them. Does this make it ok?
>sigh.. just try it and see the light.
Why don't you take your own advice?
>try this to appease the compiler
ben has commented on your example.
CBFalconer
>
... snip ...
>
> p is already as int, and as i said in this buid it happens to be 4, sizeof
> (int) works dandy.. and i dont see the reason in throwing ptrdiff_t in
>
> --
> I'm not a foreigner, honest! I just suck at typing...
Either you are a total idiot, or you are a troll. In either case
PLONK
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
EkriirkE
news:87adl4i...@pfaff.Stanford.EDU:
> EkriirkE <m...@ss.hle> writes:
>
>> sigh.. just try it and see the light. try this to appease the
>> compiler
>>
>> $ cat > sb.c
>> #include <stdio.h>
>> int main(void)
>> {
>> int array[10];
>> scanf("%s", (char *)array);
>> printf("%d\n", array[0]);
>> return 0;
>> }
>>
>>
>> and input
>> 123 <enter>
>
> This invokes undefined behavior because `int' is allowed to have
> "trap representations" which, when accessed, cause the program to
> stop running, etc.
well, if it stops the prgram when you try to read/write it (ex pretected
memory)... dont use it because its most likely not yours to work with. duh
>
>> causing (if array were char) array to contain "123\0" and the rest
>> undefined/uninitialized
>
> Yes.
>
>> and if sizeof(int)==4 it will print "3355185" on little-endian
>> machines and 825373440 on big-endian.
>
> You're making a lot of assumptions here. First, that the machine
> has 8-bit bytes and uses the ASCII character set or similar.
> Second, that your input doesn't produce a trap representation.
> Third, that the machine is in fact little-endian or big-endian
> (the Standard doesn't require it; what if you're running on a
> Vax?). And so on...
please, stop being childish, you can do the math for this for any platform.
i cannot beleive you guys beleive you have an understanding of memory, and
values thereof
if i were to enter "123", assuming same character mappings (if not, change
accordingly, STOP the ignorance!) in 7bit i would get
hex
31 32 33 00
decimal
47 48 49 0
binary
0110001 0110010 0110011 0000000
the above binary is BE order, and caluclate them together as
011000101100100110011000000
for LE, reverse these 7bit sequence as 0000000011001101100100110001
per byte..and if i were to read this as a...(7*4) 28bit int, you would get
103586176 BE
842033 LE
now lets try 16 (number is hex this time
hex
0031 0032 0033 0000
dec
47 48 49 0
binary
0000000000110001 0000000000110010 0000000000110011 0000000000000000
resulting in
13792488610529280 BE
219046608945 LE
i dont think you looked up the word 'example', for a stanford attendee,
youd think youd know what it means. here let me help via dictionary.com
ex戢m搆le Pronunciation Key (ig-zam'pel)
n.
1. One that is representative of a group as a whole: the squirrel,
an example of a rodent; introduced each new word with examples of its
use.
2. One serving as a pattern of a specific kind: set a good example
by arriving on time.
3. A similar case that constitutes a model or precedent: a unique
episode, without example in maritime history.
4. a) A punishment given as a warning or deterrent.
b) One that has been given such a punishment: made an
example of the offender.
5. A problem or exercise used to illustrate a principle or method.
take special note of #5, thanks
EkriirkE
news:7jberuoq20nrcmpr1...@4ax.com:
>
...
> And you can echo too. Golly.
>
;)
>>>> besides i was just stating
>>>> that that seemed a strange/unfamilliar method
>>>
>>> You ain't seen nuffin' yet.
>>
>>heh
>
> Gark?
huh? :)
>
>>> Why limited? If you run out of registers (unlikely, that, on a
>>> mainframe), you can always spill over into a parameter block area of
>>> some kind.
>>
>>you mean... a stack?
>
> no, a parameter block area.
hrm, sounds very similar
>
>>>> and the pc is not
>>>> my only platform. designating certain registers for certain types
of
>>>> parameters is just too constraining, becasue then you would be
>>>> limited the number of parameters by the platform...
>>>
>>> Why?
>>
>>uhh if you have, say, only 10 registers diesignated for char *, you
are
>>limited to 10 %s
>
hrm, thats weird. anyway, that is still irrelevant to this thread (its
about memory at a pointer - not parameter pushing) ;)
>
...
>>and im stubborn? :P
>
> there's stubborn, and there's "too stubborn to realise when you're
> wrong"
i know what you mean ;)
>
>>>> > How can you have a runtime error if the compiler reckons the code
>>>> > is so broken that it refuses to produce a binary?
>>>>
>>>> see above
>>>
>>> There exists a conforming compiler which refuses to compile your
code.
>>> Your code is broken. It is not merely pining for the fjords.
>>>
>>
>>then dont use that compiler, its still may be portable on that
platform,
>>but not with that particular compiler (see bottom code for the
'bypass')
>
> If a compiler conforms, and won't compile your code, you suggest using
> a different one that will.
i also offered a slight modification to allow such compilers with or
without those special switches at the bottom, so that gives you 2 options
of working around that
>
> You ask someone to shoot a nun, and he won't. So you go find another
> person and ask them. Does this make it ok?
>
>>sigh.. just try it and see the light.
>
> Why don't you take your own advice?
i do, and quoted text does nothing for me.. i need example, EXAMPLES. i
beg of you, prove me wrong, please!
>
>>try this to appease the compiler
>
> ben has commented on your example.
>
>
and i replied as always :D
EkriirkE
>
...
> possibly. And is it an integer value as you claim? No.
>
when did i claim all pointers were integer? if you mean the int *a
thing, its an EXAMPLE, it could be a struct, float, bool, you name it.
>>>>> It is _also_ legal for all pointers to be simple numerical indices
>>into
>>>>> memory
>>>>
>>>> uhh, that *IS* a pointer, and what ive been saying all along...
>
>>> No, that's an *implementation* of a pointer.
>>
>>all these still are just pointing to a location in memory... i still
>>dont see the point in the original argument here
>
> The point is, you're a fuckwit with no knowledge at all. Its pointless
> trying to educate you because you have no interest in learning.
>
> If you _want_ to learn, try reading what people say. Let me say it
> again
>
i do read them, and no one knwos what they are talking about, or they
dont understand me, and they/we are fighting a different argument
> A pointer is merely a way of finding an object.
> That could be a simple numerical offset into hte entire memory of hte
> machine.
> Or it could be a pair of values eg the ID of hte virtual machine, and
> the offset into its virtual memory,
> Or it could be something totally different.
>
> If you think that windows has a flat integer pointer memory model then
> you know f*ck all about windows memory management by the way.
>
whatever the numerical data of the actual pointer is, my argument is, if
it were "finding" an int, struct, char or whatever, it would not be
different based on the type of data at teh end of the pointer
i never once said that all pointers were flat memory references, but i
did use it as an EXAMPLE, look it up, by the way
>>> That pointers be implemented as integers is not required.
>>>
>>when did i say this? looks like someone else needs to look up
>>"example"
>
hmm, you said, not too far up, that i said this, too.. where did i say
that?
> EkriirkE <m...@ss.hle> wrote:
>> wrong, type is irrelevant, a pointer is simply a number that is a
>> reference to a position in memory
>
> Someone needs to look up "idiot"
>
i got "comp.lang.c:string to integer"
EkriirkE
> EkriirkE wrote:
>>
>> > For qualified-Q1-pointer-to-T1 to be compatible with
>> > qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and
>> > T2_ must be compatible.
>> >
>>
>> still dont understand, speak C ;)
>
> He is.
its technical, long-winded english. i am self taught, and dont know all
the terminology - its useless to know.. unless you're here ;)
>
>> ...
>> >> you are all
>> >> going by your own interperetation of what this book or faq says
>> >
>> > "this book or faq" is the Standard that *defines* C, and "our
>> > interpretation" is informed by, amongts other things, comments from
>> > people who *wrote* that Standard, implementors of C according to
>> > that Standard, and users of machines other than the x86 family.
>>
>> ok... but im my examples before, as just stated, they are just
>> examples, many are being childish, or lack mental capacity to see the
>> *minor* changes needed to getit to be just as i was explaining on
>> their different platform
>
> The only changes needed to get it to work on *every* platform are
> those changes that will bring it into line with the definition of the
> language.
>
>> ...
>> >
>> > Oops: p is not initialised; any use of its value is UB. Let's
>> > pretend that it is suitable initialised.
>> >
>>
>> it doesnt matter, it is only uninitialized once, having a
>> 'random'/unknown value thruout the program untill it is changed.
>
> It does matter. Using an indeterminate value invokes UB.
take Math-A, it may help you
by that logic:
int a;
printf("%d",a-a);
will (almost)never show 0? i think not. try it, see the light
>
>> it does not change itself
>> every clock cycle of the cpu
>
> Chapter and verse from the Standard to support that claim, please.
tell me where the standard you 'understand'is and i'll search and give it
to you, and..
the initial value of p is random, it does not change from its initial
unknown value unless you change it yourself. it will not change itself,
otherwise C is the crappiest language in existence
>
...
>
> 6.7.8(10) of the Standard says: "If an object that has automatic
> storage duration is not initialized explicitly, its value is
> indeterminate."
>
and what did i say?
>
> C isn't math, though.
>
but the above is
>> 1+1 is 2. seeing it in a different light wont
>> give you 666
>
> Please predict the output of this program (in terms of the *relative*
> values of p and q). Then compile and run it.
>
> #include <stdio.h>
> int main(void)
> {
> int i[2] = {6, 42};
> int *p = i;
> int *q = p + 1;
> printf("%p: %d\n", (void *)p, *p);
> printf("%p: %d\n", (void *)q, *q);
> return 0;
> }
>
> Pointer arithmetic shows that adding 1 doesn't always mean quite what
> one intuitively expects it to mean.
this is completely different from the previous code
in this code you are using data the pointer(s) refer to, the other did not
p = &i, pointer to i
q = &i[1], pointer to i + sizeof(int)
printed results are
undef'd: 6
previous undef'd + sizeof(int): 42
predictable upto the pointer values
>
.
>> p is already as int, and as i said in this buid it happens to be 4,
>> sizeof (int) works dandy.. and i dont see the reason in throwing
>> ptrdiff_t in
>
> You don't? But he just explained it to you! Try reading his
> explanation again.
>
i never used ptrdiff_t, and from what ive looked up, its just an (correct
me) intermediary.. another variable.. just slows down the prog (a few
cyles)
EkriirkE
>
> don't snip attributions, its rude
what?
>
>>chris the hedgehog said:
>>> "this book or faq" is the Standard that *defines* C, and "our
>>> interpretation" is informed by, amongts other things, comments from
>>> people who *wrote* that Standard, implementors of C according to
>>> that Standard, and users of machines other than the x86 family.
>>
>>ok... but im my examples before, as just stated, they are just
>>examples, many are being childish, or lack mental capacity to see the
>>*minor* changes needed to getit to be just as i was explaining on
>>their different platform
>
> You arrogant prat. The people being "childish" or "lacking mental
> capacity" are bloody experts in C. You are such a total idiot.
i love you, too
>>> Oops: p is not initialised; any use of its value is UB. Let's
>>> pretend that it is suitable initialised.
>>
>>it doesnt matter,
>
> What? Please shut the fuck up and go read the bloody standard.
> Accessing an uninitialised variable is not permitted.
see reply to previous message
>
>>it is only uninitialized once, having a 'random'/unknown
>>value thruout the program untill it is changed. it does not change
>>itself every clock cycle of the cpu
>
> Do you know that? how? Does the C standard say so? And even if it were
> true, so what?
int a;
a is uninitialized ATM, it can be anything; blah is code executing, not
using a
blah; //a is still the same value from start
blah; //same
blah; //same
a=0; //a is now 0
blah; //a is still 0
blah; //same
how is that any different, aside from the now initialized a than
int a=5;
blah; //a is still the same value from start
blah; //same
blah; //same
a=0; //a is now 0
blah; //a is still 0
blah; //same
now why would C change your variables for no reason, mid code just because
it wasnt set a specific value?
that would mean C, internally, has to do something along the lines of (%
lines being code the CRT, or compiler would insert/do)
void func() {
int a;
% bool a_inited=false
blah;
% if (!a_inited) a=rand()*whatever;
blah
% if (!a_inited) a=rand()*whatever;
blah
% if (!a_inited) a=rand()*whatever;
a=0;
% a_inited=true;
blah;
% if (!a_inited) a=rand()*whatever;
blah;
% if (!a_inited) a=rand()*whatever;
}
vs
void func() {
int a=0;
% bool a_inited=true
blah;
% if (!a_inited) a=rand()*whatever;
...
}
that is utterley rediculous
>
>>> No. If p is not initialised, evaluating p gets you undefined
>>> behaviour; nothing is prohibited. Some machines will trap when the
>>> likely-illegal non-value of p gets loaded into their address
>>> registers. Kaboom.
>>
>>see above
>
> See above. Idiot.
>
see above
>>>> the next one, typecasting straight on the pointer
>>>> (no addition with it) has no effect whatsoever but to appease the
>>>> compiler.
>>>
>>> No; the result of a pointer subtraction is of type ptrdiff_t, not
>>> int, so the cast is necessary to ensure that the value is
>>> appropropriate for feeding to %d. [Eg on a machine where
>>> sizeof(int)==2, but sizeof(*int) ==4, so sizeof(ptrdiff_t)==4 would
>>> be sensible.]
>>>
>>
>>p is already as int, and as i said in this buid it happens to be 4,
>>sizeof (int) works dandy.. and i dont see the reason in throwing
>>ptrdiff_t in
>
> because you're REQUIRED TO. The difference between pointers has type
> ptrdiff_t. Not int.
>
> For cripes sakes. What is this, elementary understanding for idiots? .
>
erm... i still see no point in using it, using a variable whos sizeof() ==
sizeof(p) will do fine, but we arnt using a variable, were using the result
directly in printf
EkriirkE
>
> As it appears you don't only lack at typing but also at reading.
yeah, probably
> What you have up there is the text of the C standard and as a C
> programmer you should be at least trying to understand what is
> meant. If we forget about type-qualifiers in the first step,
> vers 1 tells you that when you declare an identifier with a
> preceding * that this identifier will be called a pointer to ...
> Vers 2 OTOH tells you that two pointers are compatible if they
> point to objects of compatible type. And that does not mean you
> have to be compatible to be compatible in the first place.
is this talking about something like
int a;
char b;
int *c;
c=&a;
b=*(char *)c;
then yes, thats true, but in teh case of...
int a;
char *b;
int *c;
c=&a;
b=(char *)c;
then c==b==&a
>
> I think most of the people posting in this thread (probably
> except me and of course you)
lol
> have a rather good understanding of
> pointers and how they are used correctly. You just seem to be
> to ignorant to prove fails in any other way but by trying with an
> example from your implementation.
>
my pointer methods on my 3 or 4 different os & platform experiences have
always worked fine, and i suspect most of the people here are on any one of
those, see my code(s) work and will not acknowlege it. You already tried,
and tried to find an error in the ways, but i set it straight. As did
Richard H, and im waiting for his stance on my reply now...
>>
>>> What do you expect to be to output of the following little
>>> program, and how would this support what you are saying?
>>>
>>> #include <stdio.h>
>>> int main(void)
>>> {
>>> int *p;
>
> Oops
>
> int x, *p = &x;
that does not affect the outcome whatsoever, the value of p has no
implications in the *math* below
>
>>> printf("%d\n", (int) (p+1-p));
>>> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
>>> return 0;
>>> }
>>>
>>> Do you recognize that p+1 is depending on the pointers type?
>>> Again as Richard said, a pointer is _not_ a pointer is not a
>>> pointer.
>>>
>>
>> i predict:
>> 1
>
> 1
yes
>
>> 4
>
> sizeof(int)
> But even if we *assume* that sizeof(int) equals 4, how does this
> supply your claim that the type of a pointer is irrelevant, and
> that a pointer is just a number?
if a pointer is non numerical, what is it? alpha?
int a;
int *b;
b=&a;
so in that case, b's data would be along the lines of "int a" or
"variable1"(oh, wait, that has a number) ??
if so, then C would have to scan some kind of pointer-data table to match
up with its corresponding variable
>
>>
>>
>> reguardless whether or not p has been initialized, in your formula, p
>> cancels p out leaving 1,
>
> You know, C is not math and cancalation are nothing the
> programming language is supposed to do. Though optimization may
> for sure do so. It doesn't matter, what matters is the result we
> get and which must be formally correct.
so, p+1-p is not math? how strange, then i suppose
int a=1234;
a=a+5-a+2;
does not equal 7?
if it did(and it does), how did it come to this without using math?
>
>> the next one, typecasting straight on the pointer
>> (no addition with it) has no effect whatsoever but to appease
> the compiler.
>
> Again, for substracting teo pointers, both need to be pointing to
> compatible object types.
uhh, no... and isnt subtracting math? i thought it was, damn the school
system!
> You must not substract a int-pointer
> from a char-pointer or vice versa.
in the case of
int a;
char b;
int *c=&a;
char *d=&b;
printf("%d",c-d); //if it warns, be "clever" and type cast to make your
compiler happy
this, assuming that in memory, a's data precedes b's...
the result = sizeof(b)
of b precedes a, its sizeof(a)
of course this wont work if a and b are not next to each other, i dont know
what 'the standard' says about variable space in a function...anyway
in the case of
int a=1234;//for you that beleive i need a to be bleived here for math
where this will cancel itself out
char *b;
int *c;
c=&a; //obviously valid, no?
b=(char *)c; //this, too is valid
now c==b==&a, i can do
c=(int *)b;
and c is unchanged. a pointer is a pointer is a pointer
>
>> however where you have p+1, p being of int will multiply the adder by
>> sizeof(int) and add it to p, but if you typecast p pointer type first
>> (char *)p, you just made the multiplicand different,
> sizeof(char).
>
> Which just disproves your claim that a pointer is a pointer is a
> pointer.
i kinda stumbled on my words there, i'll redo this..
int example[123];
int *p=example;
if you were doing something like (p+1), this is is the same result as
&example[1], and (p+2) to &example[2].... now each index is sizeof(int)
bytes past the previous index, makign so that if i subtracted one index's
pointer from the previous', i would get sizeof(int), now i only inited p to
clarify, for the math involved in the code in question, the layout of
memory, and pointer's "type" effect on adding/subtracting to/from the base
(&example) of the array or to-from each other
as part of the same code, you threw in a (char *) cast, now ASSUMING for
this EXAMPLE a char is 1 byte (sizeof(char)==1) if you "re-typed" p as
char, 1 byte, if would in effect make 'example' looke like an array of (123
*sizeof(int)) chars, so ((char *)p+0) is the 1st byte of example, ((char *)
p+1) is the 2nd, etc
>
>> that is
>> only affecting your offset/adder ratio, again on this example we are
>> using the base of the array as the reference, no matter how you cast
>> it, it will not change
>
> On your system, it will probably not change, but it may well have
> effects on other systems.
>
id like to see that (no sarcasm) :D
EkriirkE
were off topic, which leads me to beleive no one understands memory, and
pointers to it
EkriirkE
@elf.eng.bsdi.com:
an antique, but it is dissapproving of my 'pointers just a number', thank
you, really. You are the first to enlighten me on that topic (note to
other readers, this admission is reguarding pointer data, not data where
the pointer points, and the use of the data at that location)
>
> The format of word pointers was based on that of the Nova, and
> looked something like this:
>
> IAAAAAAAWWWWWWWWWWWWWWWWWWWWWWWW
>
> The "I" bit is an "indirection" bit, not used by the C compiler.
> The "A" bits have to do with access control and are actually split
> into ring and segment numbers; I have forgotten the details, and
> in any case they do not matter in this case. The remaining bits,
> labeled "W" above, provide the address of the 16-bit memory word
> holding the value (or the lowest address of multiple words holding
> a 32- or 64-bit value).
>
> Notice that there is *no way* to specify which 8-bit byte you want,
> if you have only a "word pointer"; it points to an entire 16-bit
> word. Hence the need for a new byte-pointer format, which they
> chose to do as follows:
>
> IAAAAAAAWWWWWWWWWWWWWWWWWWWWWWWW [word pointer]
> AAAAAAAWWWWWWWWWWWWWWWWWWWWWWWWB [byte pointer]
>
> Note that the byte pointer discards the "I" bit entirely -- it was
> not being used by the C compiler anyway -- and shifts all the other
> bits left one, then adds a new bit "B" at the bottom. If B=0, the
> byte pointer points to the left-hand byte (I think -- maybe it was
> the right-hand byte; it has been at least 15 years), otherwise it
> points to the other byte.
>
you still have this machine? (i google'd it, its quite a bulk ;) ) cool
ok, so... this could adress upto 64k w/o banking? or since its acessing in
blocks of 16bits, is it 128k..? (just trying to clarify my understanding of
this system for an even more portable proof of the truth)
but i dont understand is how it recognises word from byte pointers, because
the bit shifted in could look very well like part of the adress number...
> On the Data General, then, there is an actual machine instruction
> used to convert from "byte pointer" to "word pointer": "shift right
> one bit, discarding the B bit and introducing a 0 in the I bit".
> Likewise, an actual machine instruction converts from "word pointer"
> to "byte pointer": "shift left one bit, discarding the I bit and
> introducing a 0 in the B bit."
interesting
>
> Since malloc() returns a "char *" -- a byte pointer -- it must
> always make sure to return one in which bit B is 0
ok, wait.. so if the last bit is 0 its a byte pointer, if set its a word?
then that would make that bit the byte flag...right?
and if C ignored I, and C can use words and bytes, how does I come into
play with B? see
WORD ptr
I AAAAAAA WWWWWWWWWWWWWWWWWWWWWWWW
0 0101010 001100110011001100110011
BYTE ptr
AAAAAAA WWWWWWWWWWWWWWWWWWWWWWWW B
0101010 001100110011001100110011 0
is it illegal for a word ptr to be somethign like (see last bit)
I AAAAAAA WWWWWWWWWWWWWWWWWWWWWWWW
0 0101010 001100110011001100110010
making (to me) the 2 indistinguishable
IAAAAAAAWWWWWWWWWWWWWWWWWWWWWWWW
AAAAAAAWWWWWWWWWWWWWWWWWWWWWWWWB
00101010001100110011001100110010
01010100011001100110011001100110
unless AAAAAAA has a specific pattern in the first few bits....
> because malloc()'s
> return value can be assigned to an "int *" -- a word pointer --
> which will discard the B bit. A later call to free() will convert
> the word pointer back to a byte pointer, with B=0, but since malloc()
> makes sure to produce pointers with B=0, this is OK.
>
> Let us take a look at function f() again, then, and consider the
> machine code produced on a system very much like the Data General
> (but using IA32-like mnemonics and so on):
>
> void f(void) {
> int *p = malloc(100); /* bug: should be "char *p" */
>
> if (scanf("%99s", p) == 1)
> printf("got %s\n", p);
> }
ok, based on the memory module, i can see why int and char would
cool, the syntax is very similar to the x86
> The problem is that "lshr" -- logical shift right -- of r0. This
> converted the byte pointer malloc() returned to a word pointer to
> store in "p", and the rest of the calls (to scanf and printf) passed
> on that shifted value. But printf and scanf, on seeing a "%s",
> expect to retrieve a byte pointer. They will NOT do the corresponding
> "shl" to convert the word pointer back to a byte pointer.
>
> We had code like this[%] running on our VAX and Pyramid and Sun
> machines when we got the Data General. We compiled it there and
> it broke. The reason it broke is that our code was wrong. When
> we fixed our code, it still worked on our VAXes and Pyramid and
> Suns, but now it worked on the Eclipse too.
>
> In other words, I am speaking from experience. This code DOES NOT
> WORK on some systems, and the C standards *say* it does not *have*
> to work -- but if you make two small changes, it *does* have to work:
>
> void f(void) {
> int *p = malloc(100);
>
> if (scanf("%99s", (char *)p) == 1)
> printf("got %s\n", (char *)p);
> }
ah!, looks like i dont need to write a more portable code after all.. i
already make this modification for someone else above.. so, is it safe to
say you agree with me (somewhat)?
oh, and it seems my typecasting pointers theory is dead on this one... but
this machine presumably is no longer in use today(?).... whould anyone
else like to add more proof to the list?
>
> and indeed, this code (as silly as it is) DOES work on the Eclipse,
> because the two "shr" instructions missing from the first version
> show up in the second.
its not silly :P
ive been trying to explain to the others how and why this works, and its
been branching into a few different topics.... sigh
>
> [% Nothing quite this silly, but code that passed "int *"s where
> "char *"s were needed, and vice versa. The thing that bit us worst
> involved qsort().]
>
> Of course, it works even better to just use "char *p", which avoids
> both the one shl and two shr instructions entirely. It is not only
> easier to read, it also runs faster. (Assuming no optimization
> anyway.)
finally a response from someone who knows how pointers work
again, thank you
EkriirkE
Ben Pfaff
> Ben Pfaff <b...@cs.stanford.edu> wrote in
> news:87adl4i...@pfaff.Stanford.EDU:
>
> > EkriirkE <m...@ss.hle> writes:
> >
> >> sigh.. just try it and see the light. try this to appease the
> >> compiler
> >>
> >> $ cat > sb.c
> >> #include <stdio.h>
> >> int main(void)
> >> {
> >> int array[10];
> >> scanf("%s", (char *)array);
> >> printf("%d\n", array[0]);
> >> return 0;
> >> }
> >>
> >> and input
> >> 123 <enter>
> >
> > This invokes undefined behavior because `int' is allowed to have
> > "trap representations" which, when accessed, cause the program to
> > stop running, etc.
>
> well, if it stops the prgram when you try to read/write it (ex pretected
> memory)... dont use it because its most likely not yours to work with. duh
You seem to be missing the fact that it's your program above that
has this problem. In particular, the reference to array[0] in
the printf() call can have this problem.
> >> causing (if array were char) array to contain "123\0" and the rest
> >> undefined/uninitialized
> >
> > Yes.
> >
> >> and if sizeof(int)==4 it will print "3355185" on little-endian
> >> machines and 825373440 on big-endian.
> >
> > You're making a lot of assumptions here. First, that the machine
> > has 8-bit bytes and uses the ASCII character set or similar.
> > Second, that your input doesn't produce a trap representation.
> > Third, that the machine is in fact little-endian or big-endian
> > (the Standard doesn't require it; what if you're running on a
> > Vax?). And so on...
>
> please, stop being childish, you can do the math for this for any platform.
The point is that you cannot. If entering "123" yields trap
representation, then all bets are off. The program may not print
a number at all, or it may print a different number on each run,
or something even stranger may happen.
> i cannot beleive you guys beleive you have an understanding of memory, and
> values thereof
On the other hand, I get the impression that you have a good
mental model of the way your computer works, and the inability or
unwillingness to imagine that there may be other computers that
work in very different ways. Not every computer is like yours,
and the C standard has been implemented on computers that are
very different.
> i dont think you looked up the word 'example', for a stanford attendee,
> youd think youd know what it means. here let me help via dictionary.com
An example should be illustrative. It should demonstrate the
point you're trying to make. So far, your examples have only
demonstrated your ignorance.
--
"I should killfile you where you stand, worthless human." --Kaz
Ben Pfaff
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
> news:3DB71759...@eton.powernet.co.uk:
>
> > EkriirkE wrote:
> >>
> >> > For qualified-Q1-pointer-to-T1 to be compatible with
> >> > qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and
> >> > T2_ must be compatible.
> >>
> >> still dont understand, speak C ;)
> >
> > He is.
>
> its technical, long-winded english. i am self taught, and dont know all
> the terminology - its useless to know.. unless you're here ;)
It's only useless if you have no need to use it. Since you're
here discussing issues on which vocabulary has a bearing, you
have a use for it.
In case you're only uninformed, not stupid, I'll try to explain.
A pointer can be "qualified" with one or more "qualifiers". In
C90, the available qualifiers are `const' and `volatile', and C99
adds `restrict'. So the above is a precise way to say that in
order for two pointer types to be compatible, they must have the
same qualifiers and the types that they point to must in turn be
compatible as well.
> > It does matter. Using an indeterminate value invokes UB.
>
> take Math-A, it may help you
>
> by that logic:
> int a;
> printf("%d",a-a);
>
> will (almost)never show 0? i think not. try it, see the light
Again, we need to introduce the idea of a "trap representation".
Suppose that uninitialized variable `a' receives a trap
representation. Then the expression `a-a' will halt the
program's execution.
Integer overflow is another possible problem. If `a' happens to
take a large negative value, then the subtraction could overflow,
which can result in an implementation-defined signal being
asserted, possibly halting the program.
> >> it does not change itself
> >> every clock cycle of the cpu
> >
> > Chapter and verse from the Standard to support that claim, please.
>
> tell me where the standard you 'understand'is and i'll search and give it
> to you, and..
The standard is not freely distributable, but a late draft of C99
is available from
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
> the initial value of p is random, it does not change from its initial
> unknown value unless you change it yourself. it will not change itself,
> otherwise C is the crappiest language in existence
It will not necessarily change itself, but C doesn't require it
to retain its value.
> > 6.7.8(10) of the Standard says: "If an object that has automatic
> > storage duration is not initialized explicitly, its value is
> > indeterminate."
> >
>
> and what did i say?
An indeterminate value may be a trap representation, which would
produce undefined behavior. From C99 6.2.6.1#5:
5 Certain object representations need not represent a value of
the object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does
not have character type, the behavior is undefined. [...]
Such a representation is called a trap representation.
> > C isn't math, though.
>
> but the above is
No, it's C. You can't interpret C expressions exactly the same
way you'd interpret mathematical formulas.
> [more of the same snipped]
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery
EkriirkE
platforms, a pointers isnt simply just a position in memory.. but no matter
what (so far) it still *contains* the memory position.
keep trying folks!
and as for the pointer casting, this, so far, is the only exception to my
theory.. and a strange one at that!
Richard Bos
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
> news:3DB71759...@eton.powernet.co.uk:
>
> > EkriirkE wrote:
> >>
> >> > For qualified-Q1-pointer-to-T1 to be compatible with
> >> > qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and
> >> > T2_ must be compatible.
> >>
> >> still dont understand, speak C ;)
> >
> > He is.
>
> its technical, long-winded english. i am self taught,
You obviously had a very stupid teacher if you cannot understand that
the above is a quote from the very document that defines the ISO
Standard C language.
As for your teacher of English, he should hang his head in shame.
Richard
Joona I Palaste
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
> news:3DB71ECD...@eton.powernet.co.uk:
> ...
>>> i said OF THE majority, not THE majority
>>
>> That's like saying Wednesday is "of the majority" of weekdays. It's a
>> meaningless claim.
>>
> what? how? 1/7 is not a mojority
Richard said OF THE majority, not THE majority. Are you falling into
your own traps here?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley
Ben Pfaff
> oh, i should note, that was proof (the only proof thus far) that on all
> platforms, a pointers isnt simply just a position in memory.. but no matter
> what (so far) it still *contains* the memory position.
You seem to think that we need to come up with examples to prove
our points. This is an odd attitude, seeing as we have a
standards document and all you have is a bunch of bald assertions
backed by arrogance.
I'm beginning to think there's no point in trying to convince a
guy who has an asshole for an email address of anything.
> keep trying folks!
You're well along the way to a plonking. Keep trying!
EkriirkE
its not possible? sure they can quote a book, but not a one can write
code?
very interesting
Joona I Palaste
> its not possible? sure they can quote a book, but not a one can write
> code?
> very interesting
You still don't seem to understand that it's the ISO C standard, not C
implementations, which define C. Even if implementations which handled
pointers to different types differently did not exist, there would be
nothing saying they *could not* exist.
You are certainly a classic example of an ignorant moron. Welcome to my
killfile.
*PLONK*
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It's not survival of the fattest, it's survival of the fittest."
- Ludvig von Drake
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
> ke...@hplb.hpl.hp.com () wrote in news:ap61pg$mh3$2...@murdoch.hpl.hp.com:
>
>> In article <Xns92B02B3C2...@204.127.202.16>,
>> EkriirkE <m...@ss.hle> writes:
>>> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in
>>> news:3db6776f...@news.nl.net:
>>>>
>>>> A pointer is an object that addresses another object.
>>>
>>> ..and ive been saying...?
>>
>> Something about numerical addresses.
>
> mmhmm
Yes, that too.
>> No; it's a *C* pointer. On a word-based machine, implementing C
>> character pointers *requires* some way of encoding both the address of
>> the word containing the character *and* the position of the character
>> within that word. If word addresses consume all the bits in a word
>> pointer, you'll need some extra bits from somewhere.
>
> well, then that is something much like segment:offset then
Not very; segments are more powerful and more complex. The word pointer
with bye offset values are are C pointers, even though they're not
machine addresses.
>>>> It is _also_ legal for all pointers to be simple numerical indices
> into
>>>> memory
>>>
>>> uhh, that *IS* a pointer, and what ive been saying all along...
>>
>> No, that's an *implementation* of a pointer.
>
> all these still are just pointing to a location in memory... i still dont
> see the point in the original argument here
You appeared to be claiming that a pointer was a simple numerical
address and nothing else. That's just a particular *implementation*
of the notion of pointer, which includes not only a reference to
a location, but can include its type and dynamic size as well.
>>>> but if you think this is required you need to stick your head
>>>> outside your woolly Windows world some day.
>>>
>>> what's required?
>>
>> That pointers be implemented as integers is not required.
>
> when did i say this?
Dunno. Do you mean to say to accept that pointers and machine addresses
or integers are not the same thing? Because, you know, you haven't
made that clear.
> looks like someone else needs to look up "example"
No, thank you; as far as I know its meaning hasn't changed significantly
in the past seventeen years.
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
EkriirkE
> EkriirkE <m...@ss.hle> writes:
>
>> oh, i should note, that was proof (the only proof thus far) that on
>> all platforms, a pointers isnt simply just a position in memory.. but
>> no matter what (so far) it still *contains* the memory position.
>
> You seem to think that we need to come up with examples to prove
> our points. This is an odd attitude, seeing as we have a
> standards document and all you have is a bunch of bald assertions
> backed by arrogance.
arrogant, maybe
but thus far out of all of you, only 1 has been able to produce code. what
does this say?
>
> I'm beginning to think there's no point in trying to convince a
> guy who has an asshole for an email address of anything.
>
its called anti spam, and judging by the attitudes of many here, its a good
thing... and it's my ass hole :P
>> keep trying folks!
>
> You're well along the way to a plonking. Keep trying!
>
and the final thing, no one, it seems, but 2 others and myself here, has a
grasp of why the original post works
all the other arguing is related to, but had no implications on the
answer...so far
ke...@hplb.hpl.hp.com
r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
> EkriirkE <m...@ss.hle> wrote:
>
>> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in
>> news:3DB71759...@eton.powernet.co.uk:
>>
>> > EkriirkE wrote:
>> >>
>> >> > For qualified-Q1-pointer-to-T1 to be compatible with
>> >> > qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and
>> >> > T2_ must be compatible.
>> >>
>> >> still dont understand, speak C ;)
>> >
>> > He is.
>>
>> its technical, long-winded english. i am self taught,
>
> You obviously had a very stupid teacher if you cannot understand that
> the above is a quote from the very document that defines the ISO
> Standard C language.
I'd like to point out that I wasn't quoting from the Standard but
paraphrasing what Zoran had quoted, in the (apparently vain) hope
of clarifying that quotation.
> As for your teacher of English, he should hang his head in shame.
I don't think we need to go there; there are quite enough heated
words around already.
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
>
>> For qualified-Q1-pointer-to-T1 to be compatible with
>> qualified-Q2-pointer-to-T2, Q1 and Q2 must be the same and _T1 and T2_
>> must be compatible.
>
> still dont understand, speak C ;)
Smilies don't work like that.
Ignoring the qualifiers for the moment, consider
Spoo *s;
Flarn *f;
where Spoo and Flarn are some [complete] types are other. Then s and
f have compatible types if Spoo and Flarn are compatible types.
> ...
>>
>> Oops: p is not initialised; any use of its value is UB. Let's pretend
>> that it is suitable initialised.
>
> it doesnt matter, it is only uninitialized once, having a 'random'/unknown
> value thruout the program untill it is changed. it does not change itself
> every clock cycle of the cpu
Doesn't matter as far as C is concerned. Any use of an uninitialised
location gets you undefined behaviour from that point on; the rules of
C don't help you any more.
>>>> printf("%d\n", (int) (p+1-p));
>>
>> 1.
>
> ..yes
>
>>
>>>> printf("%d\n", (int) ((char*)(p+1) - (char *)p));
>>
>> sizeof(int).
>
> ..yes, and as i said, on my system it happens to be 4
No; as I recall, you said "4", with no reference to your local sizeofs.
>> No. If p is not initialised, evaluating p gets you undefined
>> behaviour; nothing is prohibited. Some machines will trap when the
>> likely-illegal non-value of p gets loaded into their address
>> registers. Kaboom.
>
> see above
Which helps how, exactly?
>>> in your formula, p cancels p out leaving 1,
>>
>> This slapdash "cancellation" conceals the actual defined process.
>
> i dont see how, math is math, 1+1 is 2. seeing it in a different light wont
> give you 666
You claim that in `p + 1 - p` that the `p`s "cancel". They only "cancel"
if the result is defined. The expression `p + 1 - p` means `(p + 1) - p`;
that's how the grammar works. This is defined only if `p` and `p + 1`
are defined. If either of them isn't defined, *neither is the result of
the expression*.
The "cancellation" relies on the well-definedness of the expressions;
since as given `p` wasn't defined, the cancellation isn't a legal
simplification.
>>> the next one, typecasting straight on the pointer
>>> (no addition with it) has no effect whatsoever but to appease the
>>> compiler.
>>
>> No; the result of a pointer subtraction is of type ptrdiff_t, not int,
>> so the cast is necessary to ensure that the value is appropropriate
>> for feeding to %d. [Eg on a machine where sizeof(int)==2, but
>> sizeof(*int) ==4, so sizeof(ptrdiff_t)==4 would be sensible.]
>
> p is already as int, and as i said in this buid it happens to be 4, sizeof
> (int) works dandy.. and i dont see the reason in throwing ptrdiff_t in
Because subtraction of pointers is *defined* to yield results of type
ptrdiff_t, that's why.
Incidentally, p is not an int, it's a pointer to int.
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
> lol, this is too funny
One.
And two.
--
Chris "hasty? I don't think so." Dollin
ke...@hplb.hpl.hp.com
EkriirkE <m...@ss.hle> writes:
> Mark McIntyre <markmc...@spamcop.net> wrote in
> news:529erusqd0tgl1svr...@4ax.com:
>
>> don't snip attributions, its rude
>
> what?
Rude. Offensive. Impolite. Tending to cause others to avoid or
ignore you.
> int a;
> a is uninitialized ATM, it can be anything; blah is code executing, not
> using a
>
> blah; //a is still the same value from start
There's no way to know that in legal C.
> blah; //same
> blah; //same
> a=0; //a is now 0
That's true. Now `a` has a defined value.
> blah; //a is still 0
> blah; //same
>
> how is that any different, aside from the now initialized a than
Because `a` is initialised.
> int a=5;
>
> blah; //a is still the same value from start
And you can now legally *tell* that it has the same value.
> blah; //same
> blah; //same
> a=0; //a is now 0
> blah; //a is still 0
> blah; //same
>
> now why would C change your variables for no reason, mid code just because
> it wasnt set a specific value?
No-one said it did. What they *did* say is that accessing the variable
has an undefined effect, ie, one outside the scope of the Standard.
> that would mean C, internally, has to do something along the lines of (%
> lines being code the CRT, or compiler would insert/do)
No, it doesn't. It *could*, but it doesn't need to.
(deletions)
> that is utterley rediculous
But something similar isn't; associate with every variable a boolean
flag, initially false, set true when the variable is assigned to.
Whenever a variable is accessed, if its associated boolean is false,
abort the program with a diagnostic message.
Useful for debugging, and legal by the Standard, and now
int a;
fprintf( stderr, "Is %d zero?\n", a - a );
won't print "Is 0 zero?" or indeed anything (except the diagnostic,
of course).
> erm... i still see no point in using it, using a variable whos sizeof() ==
> sizeof(p) will do fine, but we arnt using a variable, were using the result
> directly in printf
Yes, and that result is of type ptrdiff_t, and that type need not be
the same type as int, so printing it with %d gets you UB. Kaboom.
--
Chris "electric hedgehog" Dollin
Richard Heathfield
>
<snip>
> >>
> >>uhh if you have, say, only 10 registers diesignated for char *, you
> are
> >>limited to 10 %s
> >
>
> hrm, thats weird. anyway, that is still irrelevant to this thread (its
> about memory at a pointer - not parameter pushing) ;)
It's about correctness and incorrectness. I just showed you one or two
"examples" to illustrate why your code could break when moved outside
the sandbox of your own cosy little environment. Look up "example" in
the dictionary when you have time.
> >>> There exists a conforming compiler which refuses to compile your
> code.
> >>> Your code is broken. It is not merely pining for the fjords.
> >>>
> >>
> >>then dont use that compiler,
Don't be ridiculous. If I am hammering a nail into a piece of wood and
the nail bends, I reach for a new nail, not a new hammer.
> its still may be portable on that
> platform,
No, it clearly isn't portable, otherwise the compiler wouldn't have
rejected it. Duh.
<snip>
> >>sigh.. just try it and see the light.
> >
> > Why don't you take your own advice?
>
> i do, and quoted text does nothing for me.. i need example, EXAMPLES. i
> beg of you, prove me wrong, please!
You have been proved wrong on several occasions now. I checked. So what
are you waiting for? An example that will break on *your* architecture?
But your fallacious beliefs about C are *based* on the behaviour of your
architecture. Your wait will be a long one. (Unless you're prepared to
go out and buy a Vax cluster.)
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton