pemo said:
Sorry, I'm a terrible poster, and I'll look at QuoteFix.
I would not class you as a terrible poster. The terrible posters are
those who make no effort or deliberately go against convention. You may
make mistakes, but you are attempting to do it correctly. That puts you
on the good side rather than the bad. To make it clear, I have reason to
suspect that OE sometimes does the wrong thing even when users have done
their best to configure it correctly, but I've heard from people I
respect that QuoteFix helps to make OE behave nicely.
printf("%p\n", (void *)"boo");
will output some value that's not 0, and very unlikely to be 1, e.g.,
0040300
It will output some implementation-specific sequence of printing
characters. The sequence may or may not look like a number.
Can you explain this comment too? Is it an allusion to some obscure
minutiae in the std, like "In reality, an implementation is free to
encode an address such that it is displayed in egyptian hieroglyphics"?
One very common format of output is something like "1234:5678", another
is something like "0x12345678". <snip>
Ah, so it was as I expected - an allusion to some obscure minutiae [well,
it
You think x86 based machines are obscure minutiae?
No, not that! [see also below], rather that the comment I thought
uneccesary, *was* (IMHO)
That is not the way your comment that I was making "an allusion to some
obscure minutiae" reads to me. said:
It was essentially 'pulling me up' for stating that the output *might* be
0040300 [or 0123456, or 123, or 34234234234234234] - and that I didn't add
some, 'oh, and it might just be in output in hieroglyphics on your
implementation'!
No, it was not you picking a number, but your wording read to me as
implying it would be a simple number.
Maybe the point was made so that some 'knumb nuts' didn't get the wrong end
of the stick, or maybe it was made just to remind someone [who I don't know]
that the output might actually be different from the example - maybe it was
just made to personally annoy me - I dunno, but it pissed me off anyway!
It wasn't made to annoy you, or to show you up, or anything like that.
is isn't it - letter-of-the-law-correct-or-not] that seems picky and
generally non-constructive. The two examples you gave look like numbers
to me. And I would hazard a guess that most every compiler outputs
something
Numbers do not have colons in the middle, at least not in any
representation I've come across and "(null)" is definitely *not* a number
which was another example I gave but you snipped.
Yes, my phd wasn't wasted - and I've noticed that numbers don't have numbers
in the middle **using standard notation [see below]** - but they *can* have
camels in the middle if *you* want them to - and if you want to use such
notation personally - as some legal characterisation of some abstract scalar
view of the world.
If you put a camel in the middle it won't look like a number to most
people, it will look like 2 numbers separated by a camel. Just as two
numbers seperated by a colon looks like two numbers separated by a colon
to most people.
> Which comes back to a problem with this ... if the
output can be anything, well, we ought to always include standard
disclaimers about *any* claim we make here regarding *any* output.
Ridiculus - so, lets point it out when it's properly pertinent, and not just
when we just feel the urge to bump our gums, and add some white noise into
the system?
For most things the output cannot be anything, but letting people who
don't know any better think that pointers are basically the same as
numeric types is dangerous.
Actually, that's rubbish, as I used them for many years with segmented
architectures - such numbers then meant as much to me - as in they had an
intuitive meaning for me (as 123 does now/then). This last bit is a little
like the 'pulling up' I had
Show a "number" with a colon in the middle to a mathematician and they
won't think of it as a number. Explain to them that 0010:0000 is the
same as 0000:0010 because you multiply the number before the colon by 16
and add it to the other and they will probably consider it to be two
numbers separated by an operator. Most of the people I've talked to
about x86 systems would also consider it to be two numbers, a segment
and an offset, not as one number, and as an ex-assembly language
programmer there have been times when the distinction has been very
important.
'Actually the output of pemo's mathematics will be a pemo
implementation-specific sequence of printing
characters [maybe]. The sequence may or may not look like any number you're
used to'
Well, your explicit statement that the value would not be 0 is not
necessarily correct and so should not have been stated as fact, and I
know of systems where it is very easy to end up with a pointer to
address 1 (and possibly 0 as well, but I can't be certain of that since
I can't remember what was used for a null pointer) since it is normal
memory at that address. Had you not said what values it would not be I
might not have bothered commenting, but that combined with the rest of
what you were saying looked to me like it would read to the naive as if
pointers where just integers.
You