473,326 Members | 2,680 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

size of a sizeof(pointer)

what is the size of a pointer?

suppose i am writing,
datatype *ptr;
sizeof(ptr);
now what does this sizeof(ptr) will give? will it give the size of the
data the pointer is pointing to?

if no, can you give an counter example?

basically , i want to know what is the meaning of size of a ponter.

as you know

sizeof(int)=4;

sizeof(char)= 2;

but what does sizeof(ptr) means??

can anybody explain?
Nov 14 '05
79 125091
(This is getting pretty far off topic and perhaps should move to
comp.programming or even the moderated group, comp.compilers...)
In article <c0**********@newsg3.svr.pol.co.uk>
Malcolm <ma*****@55bank.freeserve.co.uk> writes:
Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?
Chris Torek wrote:
Generally, I *would* call it a compiler (provided it produced an
executable image in the process, perhaps by later invoking the
"assembler" that translates the C++ to machine code).

In article <news:c0**********@sparta.btinternet.com>
Richard Heathfield <bi****@eton.powernet.co.uk> writes:Well, it's obviously your prerogative to use words as you choose, but your
proviso here flies in the face of Aho, Sethi and Ullman's definition: "a
compiler is a program that reads a program written in one language - the
source language - and translates it to an equivalent program in another
language - the target language" - no mention there of executable images.
Source: Dragon Book (Chapter 1, page 1!)


As nrk points out in a followup, there is at least some disagreement
over precisely what a "compiler" is. I am happy to work with the
Dragon Book definition (which, to be honest, I had actually forgotten
-- it has, after all, been 20 years! :-) ) as well. In this case,
a translator much like the original "cfront" is also a compiler
even if it never produces an executable.

Given that we have the word "translator", however, I personally
would tend to use that word for a system in which the "produce
something useful" step requires outside assistance, such as a
C++-to-C step that not only does not come with a C compiler, but
is provided for a computer for which no C compiler is even available.
It is probably also worth pointing out that there are a number% of
compilers that have produced C as their "assembly code", but in
all cases of which I am aware, that C code was not portable at all
-- you had to tell the XYZ-to-C step "this implementation has 32-bit
int, is big-endian, widens all floats to double, uses a stack for
variable arguments", and all sorts of other things tied to the
specific implementation. Thus, calling the C output an "equivalent
program" is perhaps stretching the truth: it is only "equivalent"
for one specific machine or group of machines, not for all systems
on which C runs.

Finally, let me note that this sort of thing is why it sometimes
pays to step back and define one's terms. People can argue forever
fruitlessly over nitpicky details, never reaching any agreement,
simply because they started with different definitions. This, in
fact, is why we have C standards: without a common definition of
what it is to "be" a C program, it may be impossible for two people
-- or even one person and a compiler -- to reach agreement as to
what the source-language program *means*.

[%footnote: when I say "a number" I do mean "more than one". While
cfront is perhaps the best-known example, I believe Xerox PARC had
C back-ends for some of their compilers, for the language that was
a followon to Mesa -- I have forgotten its name -- and for Modula-3,
for instance.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #51

In article <c0**********@newsg3.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Chris Torek" <no****@torek.net> wrote in message

Would you also claim that any machine on which the machine's
"opcodes" are interpreted by microcode has no compilers?
Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?
I posted a perfectly workable definition of "compiler" which easily
deals with this sort of case. A compiler is a software tool which
processes translation units (files, in many implementations - though
not in OS/400, for one) in their entirety (that's the "compilation"
process), converting them into a form more amenable for execution.
The compiler's output need not be directly executable by the OS - and
indeed in many cases is not - it just needs to be further along the
process.

If, for some reason, you have an implementation which supplies only
a C++ compiler, then a C-to-C++ translator would be a C compiler for
that system. It would serve to move C source translation units
further along the path to executable form.
Microcode creates a grey area.
Not if you have a sensible, consistent definition of "compiler".
I would say that the difference is between an
intermediate bytecode that is designed for arbitrary hardware, and a program
which is hardware-specific, although it relies on some microcode to support
that hardware.
The difference between what and what else?
Ultimately it's just a question of definition
Yes, that's what determines what a word, such as "compiler", means.
- how far can we extend the
term "compiler" until we're talking about two totally different things?
I'm afraid I don't see what "two totally different things" are under
discussion here. I might guess you mean, on the one hand, one of the
OS/400 C implementations, and on the other some C implementation more
familiar to you, but those strike me as two things which are not very
different at all.
The
AS/400 almost certainly contains a substantial amount of C code which is
compiled to native machine code and runs the OS.
How did you come by this information? The internals of OS/400 are for
the most part a closely guarded secret. Could it be that you are making
a wild, unsubstantiated guess?

(In point of fact, what I've heard informally from IBM insiders is that
the majority of the original OS/400 implementation was written in PL/I.
Rumor has it was substantially rewritten for the RISC implementation.
That's the LIC - Licensed Internal Code - which is the equivalent of the
kernel in OS/400 and is said to be the only part of the OS which is
native code. The bulk of the OS, including the shell and utilities, is
in theory compiled to MI. Again, this may have only been true in the
early implementations, with more pieces migrated to native code as the
OS evolved.)
How are we to distiguish
this compiler from the "compiler" shipped to customers?


Most obviously, in that it's not available to customers. And, of
course, it has a different target. What exactly is your point?

--
Michael Wojcik mi************@microfocus.com

We are subdued to what we work in. (E M Forster)
Nov 14 '05 #52

In article <c0**********@news6.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"The exception proves the rule" is a famous proverb. "Prove" means "tests",
not "demonstrates the point".
Yes, "prove" does sometimes mean "test". However, the phrase "the
exception proves the rule" does not use "prove" in this sense. See the
link I provided in my first reply. You are victim of a folk etymology.
Now I claimed that not a single compiler, to my knowledge, implemented safe
pointers. An exception was raised.
Well, that's what safe pointers are for, after all...
However on examination we see that the
"compiler" isn't really a compiler at all, if we define "compiler" as
"something that translates source code to machine code".
And if we define "compiler" as "person who assembles documents out
of individual pages", gcc isn't a compiler either.
So the exception actually demonstrates that the point is valid.


What it demonstrated was that your claim was wrong, and your definition
of "compiler" is overly restrictive and opportunistic, introduced solely
in an attempt to save a bogus argument.
--
Michael Wojcik mi************@microfocus.com

This book uses the modern technology to explain the phenomemon in the world
of Japanese animation. If you love anime so much, you'd better read this.
After you read it, you may agree that is destroying the dream of the child.
Needs Chinese viewing system. -- The Goodboy Scientific
Nov 14 '05 #53

In article <cv********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:
On 13 Feb 2004 20:49:18 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) wrote:

That's not what that idiom means. "The exception proves the rule"
is a partial vernacular translation of a Latin legal principle


possibly. Its probably more likely that the saying uses the alternate
meaning of "prove" which is "test". As in the "proof of the pudding is in
the eating".


"more likely" according to whom? The consensus I've seen (in
alt.usage.english and elsewhere) appears to be that that's a folk
etymology, albeit one popular with armchair pedants. The OED agrees
with the derivation from "exceptio probat regulam...", though it
admits that the phrase is "commonly" used with "the [substantive]
being interpreted in sense 2". But even this does not imply use
of "prove" as "test": the OED's "sense 2" for "exception" is simply
"a particular case which comes under the terms of a rule, but to
which the rule is not applicable". The OED's examples of this
usage do not use "prove" for "test", but rather are all cases of
just the sort of handwaving normally seen with casual use of the
phrase - a suggestion that the existence of an exception or two
just makes the rule "stronger" or more persuasive.[1]
1. _Oxford English Dictionary_, 2nd ed. See under "exception".

--
Michael Wojcik mi************@microfocus.com

I would never understand our engineer. But is there anything in this world
that *isn't* made out of words? -- Tawada Yoko (trans. Margaret Mitsutani)
Nov 14 '05 #54

In article <c0**********@newsg2.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Michael Wojcik" <mw*****@newsguy.com> wrote in message
This really is the exception that proves the point.
That's not what that idiom means.


Etymology isn't meaning. The proverb is not used in that way.


It is by some of us. And I'm well aware of how language works,
thanks. I was simply hoping to point out that you were employing a
bogus argument through an unfortunately popular turn of phrase,
apparently under the misapprehension that its common misuse made it
logically valid. Now it appears that you are simply unable to
understand that it's a bogus argument.
(By the way the etymology itself is dodgy)
http://www.icsi.berkeley.edu/~nchang...exception.html
Few things are crystal-clear in English etymology. The fact that
Nancy Chang happened upon one philologist who happened to think that
the phrase originally employed "prove" in the sense of "test" does
little to contradict the evaluations of more authoritive sources,
which agree with Bergen rather than Breen. And, frankly, I don't
see much validity to Breen's argument; derivation from German rather
than Latin does nothing to demonstrate that "prove" should be used
in the sense of "test".
It's not something in formal logic, but a rule of thumb.
Ah, my favorite form of argument. "It's not logical, just something
that's often kinda sorta right."
To see if a rule
applies, look at cases that appear to be exceptions.
That process falls quite nicely under logic. It's called "trying
to prove the thesis by negation of the converse". Unfortunately
for your argument, what it proves is that the converse is false.

Your examples don't demonstrate anything except the difference
between a universal rule and a general one. I fail to see how that's
germane to the argument, which is whether the various C implementa-
tions for the AS/400 are a counterexample to the thesis that "no C
implementations provide safe pointers". At least one exception
exists; the thesis is phrased as a universal rule and so is disproven.

Now, apparently, you want to convert this thesis into a general rule
("few C implementations provide safe pointers"), but since this is
an unremarkable statement, you hope to salvage its force by relegating
its exceptions to some second-class status. It's barely a step beyond
argument-by-sticking-one's-fingers-in-one's-ears.
Really. Care to expand upon this rather bizarre thesis? In what
way do the characteristics of the AS/400 1) make C any less "ideal"
there than on any other platform, or 2) require automatic memory
management?


Because C sacrifices safety in memory access for efficiency.


Chapter and verse, please. (Oh, I realize this is standard C lore.
But the language does not *depend* on this trade-off, and it has
many admirable qualities which have nothing to do with it.)
Since the
platform won't allow this, the safety has to be put in at an inappropriate
level. So I would guess that when writing a function to iterate over a
string, the pointer is checked for out-of-bounds at every increment.
Your guess would be wrong, in the general case.
Certainly passing a pointer, if it contains validity information, will be
very slow.
Pointers in the various AS/400 C implementations are 16 bytes long.
Why should passing such an object be "very slow"?
There ceases to be a point in using C on the AS/400, except that C is a very
popular language, and there is always a point in supporting a standard.
The presence of (at least) three commercial C implementations for the
AS/400, and AS/400 software developed using them, suggests that a
significant number of people disagree with this claim as well.
A
bit like driving a sports car over a traffic-calmed road - it can't go very
fast and a hatchback would make more sense, but if you own a sports car
already then you might want to do it.


So your contention is that C is a sensible language to use only on
platforms where it can be used in a dangerous mannner? Perhaps we
should take a little c.l.c poll. How many people here use C because
it lets you do unsafe things?

--
Michael Wojcik mi************@microfocus.com

Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".
Nov 14 '05 #55

In article <c0**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Could the distinction between a compiler and an interpreter be that when
they encounter program code, compilers translate it into another
language, while interpreters execute it? In other words, more or less,
compilers store away code for later execution while interpreters execute
it when they see it?


I'd call that a usable definition as well. We just recently had this
discussion in alt.folklore.computers, actually, with much debate about
where "tokenizing" BASIC implementations fit, for example.

I think this definition is largely parallel to the one I offered. An
interpreter could process an entire program as a unit, but it doesn't
need to; it's job, put simply, is "what do I do next?". A compiler
does something very different: it transforms some unit of source that
is in some way (as defined by the language) sufficiently syntactically
complete into a target form. What makes a compiler a compiler is not
that it targets any particular form, but that transforms a unit of
source data into a unit of target data (and since a compiler is not
an interpreter - though there are combined compiler-interpreters -
it probably stores the result for later use).

(In practice this definition would also have to note that by
convention "compiler" refers specifically to a tool in a software
build chain, so transformation tools for non-program data wouldn't
be included.)
--
Michael Wojcik mi************@microfocus.com

Do not "test" parts, as this may compromise sensitive joinery. Those who
suffer difficulty should abandon the enterprise immediately. -- Chris Ware
Nov 14 '05 #56
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
nrk <ra*********@devnull.verizon.net> writes:
[...]
From "Advanced Compiler Design and Implementation" by Steven S. Muchnik:

<quote>
Strictly speaking, compilers are software systems that translate programs
written in higher-level languages into equivalent programs in object code
or machine language for execution on a computer.
...
The definition can be widened to include systems that translate from one
higher-level language to an indermediate-level form, etc.
</quote>

One might argue that an author/book cannot serve as an authoritative
definition of a term, but considering the widespread use and popularity of
the book, I would tend to take this to be an appropriate definition.


Doesn't IEEE have an official dictionary of computer terms? Can
someone who has a copy look up "compiler"?


I don't have access to their dictionary. But I think that most people
would agree that the compilation process consists in the translation from
a higher level language to a lower level language. I.e. if someone ever
manages to write a translator from binary executables to meaningful C
source code, no one would call this translator a compiler. Not even Aho
and his buddies ;-)

FWIW, the Dictionary of Computing edited by Oxford Science Publications
gives the following definition:

Compiler: a program that translates high-level language into absolute
code, or sometimes into assembly language. The input to the compiler
(the source code) is a description of an algorithm or program in
a problem-oriented language; its output (the object code) is an
equivalent description of the algorithm in a machine-oriented language.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #57
Malcolm wrote:

.... snip ...

Well every system I know uses fixed-size pointers. There is one
main exception to the rule that the size of the pointer represents
the size of the address space, and that's quite an important one,
old x86 compilers with their segmented architecture.


No exception at all. Such systems either restricted the size of
the data area to 64k (which is adequately handled by a 16 bit
pointer) or used a 32 bit pointer.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #58
Malcolm wrote:
"Michael Wojcik" <mw*****@newsguy.com> wrote in message

C programmers working on the AS/400 will find that expectation
[that pointer dereferences compile to single machine
instructions] is incorrect. In C on the AS/400, *nothing*
compiles to machine instructions, single or otherwise. It
compiles to a pseudoassembly language called "MI".

This really is the exception that proves the point. A platform
that disallows native machine langauge programs cannot really be
said to have a compiler. Nor is C the ideal language for such an
environment - you need something which does memory management for
you.


Nonsense. There are various environments that do precisely that.
Ones known to me include:

UCSD p-code system
My own pcd system
Verifone terminals
Java Bytecode machines

all of which port binary executable modules across widely
differing machine architectures. Only the Verifone system was
specifically designed to accommodate C.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #59

"Michael Wojcik" <mw*****@newsguy.com> wrote in message

In article <c0**********@newsg2.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Michael Wojcick
Etymology isn't meaning. The proverb is not used in that way.


It is by some of us. And I'm well aware of how language works,
thanks.

Ho ho. So you understand how language works do you?
I was simply hoping to point out that you were employing a
bogus argument through an unfortunately popular turn of phrase,
apparently under the misapprehension that its common misuse made it
logically valid. Now it appears that you are simply unable to
understand that it's a bogus argument.
The exception proves (tests) the rule. The exception to the rule that C
compilers don't provide bounds checking is not really a compiler (we can
argue about exactly how to define "compiler", the AS/400 is in the penumbra
of meaning, but as someone who understands how language works thank you you
will have appreciated that). The exception is an oddball, the rule holds.
See "mammals are viviparous" for another example.
Because C sacrifices safety in memory access for efficiency.
Chapter and verse, please. (Oh, I realize this is standard C lore.
But the language does not *depend* on this trade-off, and it has
many admirable qualities which have nothing to do with it.)

See the other threads on bounds checking. There is no point using C if it
does not compile to efficient code, just as there is no point having a
sports car if you are driving it down a traffic-calmed street. However if
you already own a sports car you might not buy a hatchback for just one
journey.
Pointers in the various AS/400 C implementations are 16 bytes
long. Why should passing such an object be "very slow"?

Because registers are probably 32 bits, and there are probably not too many
of them, so you will thrash memory.
So your contention is that C is a sensible language to use only on
platforms where it can be used in a dangerous mannner? Perhaps we
should take a little c.l.c poll. How many people here use C because
it lets you do unsafe things?

How many people use C because it compiles to efficient machine code, and
tolerate the lack of safety because putting in bounds checking would
compromise speed?

Nov 14 '05 #60

"CBFalconer" <cb********@yahoo.com> wrote in message
This really is the exception that proves the point. A platform
that disallows native machine langauge programs cannot really be
said to have a compiler. Nor is C the ideal language for such an
environment - you need something which does memory
management for you.


Nonsense. There are various environments that do precisely that.
Ones known to me include:

UCSD p-code system
My own pcd system
Verifone terminals
Java Bytecode machines

all of which port binary executable modules across widely
differing machine architectures. Only the Verifone system was
specifically designed to accommodate C.

Well let's say we have a c interpreter. Someone decides to make the system a
bit more efficient, and strip out comments before passing the source to the
interpreter. Is the comment stripper a "compiler?".
Someone decides to speed things up a little bit more and tokenize the C
keywords (i.e. we use non-ASCII characters to represent "if" and "for" etc).
Is the tokenizer a compiler?
See where this is leading? At some point we will arrive at a "binary
executable module" and you will say "this is a compiler". But extension of
the word to marginal cases is arbitrary.
Of the examples you give only one supports C, suggesting that C isn't a good
langauge for interpreted bytecodes.
Why is memory management a good idea in these environments? Consider a
linked list. In C the user sets up the pointers himself. This means that
every time you traverse the list it is necessary to check each pointer for
validity. You also have problems because the addresses of the pointers
themselves are taken, so you need some system to prevent the pointers being
corrupted. This adds up to quite a lot of overhead.
In a language that manages memory for you, linked lists can be provided as
built in strutures. The user has no way of accessing the pointers, so
internally they can be represented as raw addresses with perfect safety.
Nov 14 '05 #61
Malcolm <ma*****@55bank.freeserve.co.uk> scribbled the following:
"CBFalconer" <cb********@yahoo.com> wrote in message
> This really is the exception that proves the point. A platform
> that disallows native machine langauge programs cannot really be
> said to have a compiler. Nor is C the ideal language for such an
> environment - you need something which does memory
> management for you.
Nonsense. There are various environments that do precisely that.
Ones known to me include:

UCSD p-code system
My own pcd system
Verifone terminals
Java Bytecode machines

all of which port binary executable modules across widely
differing machine architectures. Only the Verifone system was
specifically designed to accommodate C.

Well let's say we have a c interpreter. Someone decides to make the system a
bit more efficient, and strip out comments before passing the source to the
interpreter. Is the comment stripper a "compiler?".


Well, as much a compiler as the C preprocessor is. The resulting code
is also valid C source.
Someone decides to speed things up a little bit more and tokenize the C
keywords (i.e. we use non-ASCII characters to represent "if" and "for" etc).
Is the tokenizer a compiler?
Only a bit more than the comment stripper was.
See where this is leading? At some point we will arrive at a "binary
executable module" and you will say "this is a compiler". But extension of
the word to marginal cases is arbitrary.


I still think of javac (translating Java source code into bytecode) as
a compiler, even though you can't directly execute bytecode.
Look at it another way - isn't the distinction "only a translator that
outputs natively executable code can be called a compiler" also
arbitrary? Why single out natively executable code? The C compiling
process distinguishes between compiling and linking. Is the pure
compiler not a compiler, because unlinked object files aren't natively
executable?

(BTW, you forgot to ask if UNIX cat was a compiler. After all, it takes
in source code and outputs source code.)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Nov 14 '05 #62
Malcolm wrote:
At some point we will arrive at a "binary
executable module" and you will say "this is a compiler".


It has to be compiler before that point.
You can compile C files, which are not complete programs,
and the output is not executable.

--
pete
Nov 14 '05 #63
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
[...]
Pointers in the various AS/400 C implementations are 16 bytes
long. Why should passing such an object be "very slow"?

Because registers are probably 32 bits, and there are probably not too many
of them, so you will thrash memory.

[...]

I know very little about the AS/400. I've never used one. But (and
this is just a wild guess), if a system has 16-byte pointers, perhaps
it would be designed so it can deal with them efficiently, either by
having 16-byte registers, or by having a large number of registers and
the ability to use several of them together, or by designing it so
that thrashing memory isn't a problem, or by doing some other very
clever thing that I haven't thought of, or by having a user community
that doesn't care that much about blazing speed.

Malcolm, unless you're much more familiar with the AS/400 than I am
(and more familiar with it than you've let on so far in this thread),
you might consider refraining from detailed speculation about it.
Discussions of AS/400 architecture are marginally topical here,
because they can illuminate the range of systems on which C can be
implemented and the assumptions (like word-sized pointers) that may
not be universally valid. But I suggest such discussions should be
based on actual knowledge of the architecture.

As for exceptions proving rules, the actual origin of the saying isn't
particularly relevant. One common use of it is that an exception
actually strengthens a rule -- for example, that finding a black swan
makes the statement that "all swans are white" more valid. This is,
of course, nonsense. When you used a variant of the saying upthread,
you gave the impression, probably unintentionally, that you were using
it in that common nonsensical way. I suggest we drop the discussion
of the origin of the saying (or take it to alt.usage.english) and
instead talk about what you actually meant.

What I think you actually meant is that because the C translation
system on the AS/400 doesn't generate machine code it's not a true
compiler. The issue is the meaning of the word "compiler". The C99
standard doesn't define the word compiler (it only uses it briefly in
one footnote), and I think the C90 standard is similar. Most of the
participants in this thread seem to think that a translator that
generates something other than machine code can legitimately be called
a compiler. There's a quote from Aho, Sethi, and Ullman that agrees
with that point of view. It might be time for you to drop the
argument unless you can actually prove that you're right and the rest
of us are wrong. This might also be a better topic for
alt.usage.english.

As far as the standard is concerned, the C translation system on the
AS/400, whatever we call it, is part of the implementation, along with
the library, the OS, and whatever else is needed to make C programs
run.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #64
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Malcolm wrote:

... snip ...
>

Well every system I know uses fixed-size pointers. There is one
main exception to the rule that the size of the pointer represents ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the size of the address space, and that's quite an important one, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ old x86 compilers with their segmented architecture.


No exception at all. Such systems either restricted the size of
the data area to 64k (which is adequately handled by a 16 bit
pointer) or used a 32 bit pointer.


Engage your brain, Chuck! The 8086 machines have a 20-bit address space
and their pointers have either 16 or 32 bits. In neither case, the
pointer size reflects the size of the address space.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #65
On Mon, 16 Feb 2004 22:35:31 -0000
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message
This really is the exception that proves the point. A platform
that disallows native machine langauge programs cannot really be
said to have a compiler. Nor is C the ideal language for such an
environment - you need something which does memory
management for you.
Nonsense. There are various environments that do precisely that.
Ones known to me include:

UCSD p-code system
My own pcd system
Verifone terminals
Java Bytecode machines

all of which port binary executable modules across widely
differing machine architectures. Only the Verifone system was
specifically designed to accommodate C.

Well let's say we have a c interpreter. Someone decides to make the
system a bit more efficient, and strip out comments before passing the
source to the interpreter. Is the comment stripper a "compiler?".
Someone decides to speed things up a little bit more and tokenize the
C keywords (i.e. we use non-ASCII characters to represent "if" and
"for" etc). Is the tokenizer a compiler?
See where this is leading? At some point we will arrive at a "binary
executable module" and you will say "this is a compiler". But
extension of the word to marginal cases is arbitrary.


I would suggest that a C compiler is a program that performs a
translation on the source code producing such diagnostics as required
by the standard such that if it was a valid source file when linked to
produce something the C standard says should be executable it can be
executed by the target environment. If the code is byte code, assembler
or anything else that is irrelevant.
Of the examples you give only one supports C, suggesting that C isn't
a good langauge for interpreted bytecodes.
Pascal is a compiled language and I've used a UCSD Pascal system.
Why is memory management a good idea in these environments? Consider a
linked list. In C the user sets up the pointers himself. This means
that every time you traverse the list it is necessary to check each
pointer for validity.
If you are talking about the byte code interpreter (or whatever) then
you are wrong. The C standard allows your environment to crash or do
anything else it happens to do if you use an invalid pointer.
You also have problems because the addresses of
the pointers themselves are taken, so you need some system to prevent
the pointers being corrupted. This adds up to quite a lot of overhead.
The byte code interpreter (or whatever) does NOT have to do that. It can
crash if your executable gets it wrong.
In a language that manages memory for you, linked lists can be
provided as built in strutures. The user has no way of accessing the
pointers, so internally they can be represented as raw addresses with
perfect safety.


For perfect safety it still has to do array bounds checking etc
otherwise you might have run off the end of an array and corrupted your
pointer, and if you don't then check your pointer who knows what will
happen?

A C implementation that uses some form of interpreter can do as little
checking as a C implementation that compiles to native machine code and
still be no less safe. However, systems like UCSD can provide the
ability to distribute binaries without knowing anything about the target
environment apart from it having a suitable interpreter.

Also, a lot of modern processors run microcode programs that interpret
the machine code, so even if you compile to machine code you could well
still have your program running under an interpreter.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.
Nov 14 '05 #66
Joona I Palaste <pa*****@cc.helsinki.fi> scribbled the following:
Malcolm <ma*****@55bank.freeserve.co.uk> scribbled the following:
Well let's say we have a c interpreter. Someone decides to make the system a
bit more efficient, and strip out comments before passing the source to the
interpreter. Is the comment stripper a "compiler?".
Well, as much a compiler as the C preprocessor is. The resulting code
is also valid C source. Someone decides to speed things up a little bit more and tokenize the C
keywords (i.e. we use non-ASCII characters to represent "if" and "for" etc).
Is the tokenizer a compiler? Only a bit more than the comment stripper was. See where this is leading? At some point we will arrive at a "binary
executable module" and you will say "this is a compiler". But extension of
the word to marginal cases is arbitrary.

I still think of javac (translating Java source code into bytecode) as
a compiler, even though you can't directly execute bytecode.
Look at it another way - isn't the distinction "only a translator that
outputs natively executable code can be called a compiler" also
arbitrary? Why single out natively executable code? The C compiling
process distinguishes between compiling and linking. Is the pure
compiler not a compiler, because unlinked object files aren't natively
executable? (BTW, you forgot to ask if UNIX cat was a compiler. After all, it takes
in source code and outputs source code.)


Actually, a good definition for a compiler might be a translator for
translating a higher-level program into a lower-level one. If the
languages are of the same level it's a (pre)processor. If their levels
are the other way around it's a decompiler.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The large yellow ships hung in the sky in exactly the same way that bricks
don't."
- Douglas Adams
Nov 14 '05 #67

"Keith Thompson" <ks***@mib.org> wrote in message
I know very little about the AS/400. I've never used one. But (and
this is just a wild guess), if a system has 16-byte pointers, perhaps
it would be designed so it can deal with them efficiently, either by
having 16-byte registers, or by having a large number of registers and
the ability to use several of them together, or by designing it so
that thrashing memory isn't a problem, or by doing some other very
clever thing that I haven't thought of, or by having a user community
that doesn't care that much about blazing speed.
Obviously I don't know exactly how the AS/400 works, but I do know that if
pointers are 16 bytes then they will be slow. Since the pointer contains
bounds information as well as a validity bit then you need at least three
registers to process it (address, bounds, validity) even if the registers
are 128 bits wide. Unless of course the various pieces of information can be
combined in one instruction, but then the bytecode is supposed to be
platform independent, sp using something that can only be implemeted
efficiently on special hardware is cheating.
As for exceptions proving rules, the actual origin of the saying isn't
particularly relevant. One common use of it is that an exception
actually strengthens a rule -- for example, that finding a black swan
makes the statement that "all swans are white" more valid. This is,
of course, nonsense. When you used a variant of the saying
upthread,you gave the impression, probably unintentionally, that you
were using it in that common nonsensical way. I suggest we drop the
discussion of the origin of the saying (or take it to alt.usage.english)
and instead talk about what you actually meant.
I'd agree. The problem is that some people's grasp of proverbs is so bad
that you've got to explain everything. The AS/400 is an exception to the
rule that no implementation stores bounds information with pointers, but it
is such an oddball, not even compiling to machine code, that it doesn't
really invalidate the point that I was trying to make.

[ "compiler" ]
If you look at the literature you'll find "compiler" defined as something
that outputs machine code, or as something that translates a language into
another representation. You can use the latter definition if you wish, but
be aware that you are moving from the core definition of the term.
Nov 14 '05 #68

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
The byte code interpreter (or whatever) does NOT have to do that. > It can crash if your executable gets it wrong.

If a release program crashes on any input whatsoever then it is bugged. This
includes interpreters, decompressors, video games, or whatever.
Nov 14 '05 #69
>> The byte code interpreter (or whatever) does NOT have to do that. > It can
crash if your executable gets it wrong.

If a release program crashes on any input whatsoever then it is bugged. This
includes interpreters, decompressors, video games, or whatever.


Some released programs are *SUPPOSED* to crash under appropriate
circumstances (like when you explicitly ask it to). The main reason
for this is apparently to permit sending this info back to the
maintainer so he can fix it. Yes, these features ARE sometimes left
in production and relased code.

For example, C has the abort() function.
GDB (the GNU debugger) has the "maintenance dump-me" command.
UNIX permits sending SIGQUIT to programs (unless the programs specifically
catch that signal) to cause a core dump, using a keystroke.

I do recall hearing some discussion about emulators for certain CPUs being
written so carefully that they emulated bugs in the actual hardware that
they were emulating precisely, if you asked it to emulate that particular
model of CPU. Anyone for emulating the Pentium math bug on a non-buggy
Pentium? Some of them also emulated lockups (which sounds to me like a
crash, as the only way out was RESET or power-cycle) just like the real thing.

Gordon l. Burditt
Nov 14 '05 #70
On Tue, 17 Feb 2004 23:03:00 -0000
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
The byte code interpreter (or whatever) does NOT have to do that. It
can crash if your executable gets it wrong.

If a release program crashes on any input whatsoever then it is
bugged. This includes interpreters, decompressors, video games, or
whatever.


Not always. As far as the C standard is concerned there is nothing wrong
with an implementation containing an interpreter that crashes when a
program invokes Undefined Behaviour.

IMHO if that interpreter is something like a Virtual Machine that gets
invoked specifically to run a program and terminates when that program
terminates, then there is nothing wrong with it crashing on Undefined
Behaviour of the program being run, and this is no worse than the
program crashing if it was not running under a VM.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.
Nov 14 '05 #71


Flash Gordon wrote:
On Tue, 17 Feb 2004 23:03:00 -0000
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
The byte code interpreter (or whatever) does NOT have to do that. It
can crash if your executable gets it wrong.


If a release program crashes on any input whatsoever then it is
bugged. This includes interpreters, decompressors, video games, or
whatever.



Not always. As far as the C standard is concerned there is nothing wrong
with an implementation containing an interpreter that crashes when a
program invokes Undefined Behaviour.

IMHO if that interpreter is something like a Virtual Machine that gets
invoked specifically to run a program and terminates when that program
terminates, then there is nothing wrong with it crashing on Undefined
Behaviour of the program being run, and this is no worse than the
program crashing if it was not running under a VM.


While the standard is (rightly) unconcerned, as a possible
user of the VM which crashes, I am very concerned.
It has nothing to do with the language, per se, but
is a QOI issue. Given two VM's, one which crashed,
and another which issued a diagnostic, which would
you choose?

--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

Nov 14 '05 #72
On Wed, 18 Feb 2004 17:55:35 GMT
Nick Landsberg <hu*****@att.net> wrote:
Flash Gordon wrote:


<snip C VM crashing on undefined behaviour in application>
IMHO if that interpreter is something like a Virtual Machine that
gets invoked specifically to run a program and terminates when that
program terminates, then there is nothing wrong with it crashing on
Undefined Behaviour of the program being run, and this is no worse
than the program crashing if it was not running under a VM.


While the standard is (rightly) unconcerned, as a possible
user of the VM which crashes, I am very concerned.
It has nothing to do with the language, per se, but
is a QOI issue. Given two VM's, one which crashed,
and another which issued a diagnostic, which would
you choose?


That depends on the situation and the other aspects of the VMs. If the
one that crashed on Undefined Behaviour was significantly less resource
hungry then, having eliminated UB from the code, I might use it in
situations where no one would see the the messages produced by the other
one. If it also allowed me to hook in to things like segmentation
violations but the other did not let be trap any instances of Undefined
Behaviour, then I would be even more likely to use it.

In short, it depends.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.
Nov 14 '05 #73

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
That depends on the situation and the other aspects of the VMs. If
the one that crashed on Undefined Behaviour was significantly less
resource hungry then, having eliminated UB from the code, I might
use it in situations where no one would see the the messages
produced by the other one.
It depends why you are using a VM. If the reason is portability of the
binary, then you might accept crashing. However if the reason is safety,
then undefined behaviour introduces potential security risks.
If it also allowed me to hook in to things like segmentation
violations but the other did not let be trap any instances of Undefined
Behaviour, then I would be even more likely to use it.

The problem is that the interpreter is the program that crashes. So if you
look at the core dump, or whatever a crashed program produces on your
system, you see where the interpreter failed to check for a out of bounds
array access, for example, but not where that array was in the bytecode.
Of course a decent interpreter would produce a better diagnostic than an
unspecified "illegal memory access".
Nov 14 '05 #74


Right. I've been tied up with work and have not had time to return to
this squabble, which is OT for c.l.c and fairly pointless anyway. I'll
respond to some specific points in this message if I feel I need to do
so, but on the whole I'd like to propose the following:

1. Most C implementations do not check pointer validity.
2. Some, however, do; the three I named for the AS/400 are examples.
3. I feel that (2) is a significant exception to (1).
4. You do not.
5. The origin and preferred usage of the phrase "the exception that
proves the rule" is disputed.
6. However, some people - including myself and some other c.l.c
readers - feel that when that phrase is used to mean "an
exception to a general rule demonstrates the validity of that
rule in other cases", it's somewhat lacking in rhetorical power.
Other people, of course, may feel differently.

Fair enough?

In article <c0**********@news6.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Michael Wojcik" <mw*****@newsguy.com> wrote in message

In article <c0**********@newsg2.svr.pol.co.uk>, "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
It is by some of us. And I'm well aware of how language works,
thanks.

Ho ho. So you understand how language works do you?


Well enough. I'm ABD in critical theory (and twentieth century
Anglophone prose). I've studied structural linguistics, socio-
linguistics, pragmatics, speech act theory, and poststructuralist
linguistics (as well as various fields that are arguably cognate).
I've read a good bit of philology. My fiance is a professor of
rhetoric in one of the top rhetoric departments in the US, so I spend
quite a lot of time discussing language with other folks familiar
with the subject. I don't need J. Random Poster to tell me that
etymology doesn't determine current use.
See the other threads on bounds checking. There is no point using C if it
does not compile to efficient code, just as there is no point having a
sports car if you are driving it down a traffic-calmed street.


I disagree that the only justification for using C is efficiency of
the resulting code. In my work, for example, I generally have to
produce code which can be ported to various other platforms by other
developers; I am limited in the demands I can put on them, and they
currently deal with C and COBOL. Given that choice, I'll take C.

And since portability is a huge concern in my work - a portation
problem in one component can stall the build "pipeline" for everyone
- the C matters that c.l.c deals with are the ones that I care about
the most.

An example: Chris Torek corrected my use of vsnprintf some months
back, which let me fix a nasty memory-corruption bug in Linux/390.
My error was not "restarting" va-processing with va_end and va_start
between calls to vsnprintf. That's a harmless error in many
implementations, but in some implementations va_arg is destructive
and trying to iterate through the argument list again invokes nasal
demons. That's why the standard forbids it - a point I missed in
my original code.
Pointers in the various AS/400 C implementations are 16 bytes
long. Why should passing such an object be "very slow"?

Because registers are probably 32 bits, and there are probably not too many
of them, so you will thrash memory.


You miss my point. Making *any* guess about how the AS/400 C
implementations work under the covers is taking a stab in the dark,
and likely to mislead you. It doesn't matter how large CPU registers
are in AS/400 C, because (at least in "classic" EPM C) function calls
didn't use them anyway. They weren't accessible to the implementation.
So C's use of 128-bit pointers (ie "native" MI pointers) didn't have
any noticeable adverse effect on performance for any normal program.
--
Michael Wojcik mi************@microfocus.com

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage
Nov 14 '05 #75

"Michael Wojcik" <mw*****@newsguy.com> wrote in message

1. Most C implementations do not check pointer validity. True. 2. Some, however, do; the three I named for the AS/400 are
examples. True. 3. I feel that (2) is a significant exception to (1). Fair enough. 4. You do not.
I feel it is a special case, because the C does not compile to machine code. 5. The origin and preferred usage of the phrase "the exception that
proves the rule" is disputed.
The origin may be the legal principle, but etymology isn't meaning. The
proverb is used in two ways, ignorantly to mean that "if a rule has an
exception then that proves the rule must be valid" and correctly "by looking
at seeming exceptions we tell if the rule is valid or not".
6. However, some people - including myself and some other c.l.c
readers - feel that when that phrase is used to mean "an
exception to a general rule demonstrates the validity of that
rule in other cases", it's somewhat lacking in rhetorical power.
Other people, of course, may feel differently.

It's the difference between the rule "all mammals are viviparous" and "no
mammals are eusocial". Both have exceptions. When we look at oviparous
mammals, the monotremes, we see that they belong to a tiny group that split
off very early and is only included in "mammals" by definiton. We can use
the rule to predict that we won't find an oviparous cat. However when we
look at the eusocial mammals - naked mole rats and, partially, wolves - we
see that there does not appear to be anything special about them. There
doesn't seem to be anything about being a mammal that precludes eusociality,
and if we found a new species of cat we can't be sure it won't be eusocial.


Nov 14 '05 #76
On 15 Feb 2004 18:55:20 GMT, Chris Torek <no****@torek.net> wrote:
<snip>
Given that we have the word "translator", however, I personally
would tend to use that word for a system in which the "produce
something useful" step requires outside assistance, such as a
C++-to-C step that not only does not come with a C compiler, but
is provided for a computer for which no C compiler is even available.
It is probably also worth pointing out that there are a number% of
compilers that have produced C as their "assembly code", but in
all cases of which I am aware, that C code was not portable at all
-- you had to tell the XYZ-to-C step [implementation specifics] [%footnote: when I say "a number" I do mean "more than one". While
cfront is perhaps the best-known example, I believe Xerox PARC had
C back-ends for some of their compilers, for the language that was
a followon to Mesa -- I have forgotten its name -- and for Modula-3,
for instance.]


"most" Eiffels. At least one Ada which I believe is still sold. f2c,
and I think p2c. I believe all Objective C's, and Comeau C++.

And of course any number (well, not *any* <G>) of tools which produce
C code from some other kind of program decription or specification,
like UML or flowcharts or logic diagrams etc. etc., although we (IME)
usually call those generators rather than translators or compilers.

- David.Thompson1 at worldnet.att.net
Nov 14 '05 #77
On Tue, 10 Feb 2004 02:54:58 GMT, pete <pf*****@mindspring.com> wrote:
<snip>
You can't implement the whole standard library,
if sizeof(int) is one.

putchar(EOF) has to be able to return EOF
converted to an unsigned char value,
converted back to a nonnegative int.

http://groups.google.com/groups?selm...andrew.cmu.edu


No, it needs to return any unsigned char value (which need not and
normally does not include EOF) *or* EOF as a signed int. It apparently
was intended, and certainly is traditional, that these are distinct,
i.e. (int)UCHAR_MAX != EOF, but the standard doesn't require it, and
if not, programs using stdio have to be a lot more careful.

AFAWK implementations on which sizeof(int)==1 are all freestanding
ones on platforms where stdio isn't useful, or feasible, or both, so
the issue doesn't arise in practice. And since so few programs (and
programmers) are careful in this way, even if such a hosted (full)
implementation were created it wouldn't be popular unless it had some
huge other benefit(s).

- David.Thompson1 at worldnet.att.net
Nov 14 '05 #78
Dave Thompson wrote:

On Tue, 10 Feb 2004 02:54:58 GMT, pete <pf*****@mindspring.com> wrote:
<snip>
You can't implement the whole standard library,
if sizeof(int) is one.
No


That's what they said on comp.std.c too.
I won't be making hosted sizeof(int) claim again.

--
pete
Nov 14 '05 #79
In article <ed********************************@4ax.com>,
Dave Thompson <da*************@worldnet.att.net> wrote:
On 15 Feb 2004 18:55:20 GMT, Chris Torek <no****@torek.net> wrote:
<snip>
Given that we have the word "translator", however, I personally
would tend to use that word for a system in which the "produce
something useful" step requires outside assistance, such as a
C++-to-C step that not only does not come with a C compiler, but
is provided for a computer for which no C compiler is even available.
It is probably also worth pointing out that there are a number% of
compilers that have produced C as their "assembly code", but in
all cases of which I am aware, that C code was not portable at all
-- you had to tell the XYZ-to-C step [implementation specifics]

[%footnote: when I say "a number" I do mean "more than one". While
cfront is perhaps the best-known example, I believe Xerox PARC had
C back-ends for some of their compilers, for the language that was
a followon to Mesa -- I have forgotten its name -- and for Modula-3,
for instance.]


"most" Eiffels. At least one Ada which I believe is still sold. f2c,
and I think p2c. I believe all Objective C's, and Comeau C++.

And of course any number (well, not *any* <G>) of tools which produce
C code from some other kind of program decription or specification,
like UML or flowcharts or logic diagrams etc. etc., although we (IME)
usually call those generators rather than translators or compilers.


Indeed there are many. Another is CCsh, a Bourne Shell compiler
that Comeau also sells. Actually, the C code it produces is
extraordinarily portable, however, it depends, heavily, upon a
platform specific library to go along with it, so in the end there
is no escaping it :)
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Nov 14 '05 #80

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: Ellarco | last post by:
``Opaque-pointer representing the ID of an object. struct _objID; typedef struct _objID * objectID;'' Hi again. Im using an api that defines an objectID type. The above represents the extent...
9
by: dati_remo | last post by:
Hi, is it possible to find the dimension of an array using a pointer? main() { int a; f(a); return; }
19
by: junky_fellow | last post by:
Can the size of pointer variables of different type may be different on a particular architecture. For eg. Can the sizeof (char *) be different from sizeof(int *) or sizeof (void *) ? What...
33
by: siliconwafer | last post by:
What is size of pointer in C on DOS? is it sizeof(int ) or size of (long int)? If this ans is present in FAQ pls direct me to tht ouestion
16
by: Alex Vinokur | last post by:
Does it have to be? : sizeof (size_t) >= sizeof (pointer) Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.