Why I like only C++?

[Paul]

[...]
.data and .text are both directives to the assembler.
Which assembler? Most of the assemblers I've used didn't have
such directives.

Most of the assemblers I have used do have such directives:
GNU Assembler, .section .text

The directive here is .section. The .text is simply a symbol; you
can,
at least in principle, use anything you want (and a really good
compiler
will use more than just .text and .data).

NASM, SECTION .text

Ditto. The directive is SECTION; the .text is just a user defined
symbol.

MASM, .CODE
TASM, CODESEG
Worked what way? You generally want to put data into the data segment
and code into the text aka. code segment. These directives allow the
programmer to do this, what's the problem?

The directives allow the programmer to divide the program up into one
or
more segments. Other directives tell the linker where to put these
segments. There may be defaults for some symbols, but they're
certainly
not universal, and they don't mean that you cannot use other segments,
or other names.

I can write assembler compiler that can compile this:

"jesus .text", that doesn't prove anything. A text segment is
generally where the assembler puts code. A fact. Come on, what are you
smoking?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

If you mean by "generally" that this is most often the case then I would
agree. Because, in general, the term TEXT segment as we use it today is a
PC program format, also this represents the memory layout.
But it is not true to say that this is the *only* type of memory model. A
true flat model(not wintel .flat model) has one segment of memory it doesn't
need to have any segment name, ofc you can name it anything_you_want but it
doesn't do anything. It's no more a text segment than it's an
anything_you_want segment.

 

[James Kanze]

[...]

Obviously, you didn't read what you are responding to, or you didn't
understand it.

Yes I read what you wrote re:
"Any modern linker will understand segments, in order to give you more
control of where things are placed in memory. This has nothing to do with
how the hardware addresses things"

And I disagree with you ,

It's not really a question of opinion.

it is related to how the hardware addresses in
most modern PC's.

First, it has nothing to do with PC's, modern or otherwise.
Only one architecture is used on PC's, at least as far as I
know. Where as all of the linkers understand segments. See
http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf,
for example. (Sun has recently changed its assembler to use
section, rather than segment; the assembler still supports the

When a program is loaded the registers are set up to mirror
the program segments, on a windows implementation I know, I am
not saying this is the case on every implementation.

On the Windows implementations I use (and the Linux ones as
well), the Intel segment registers are all loaded with the same
value; the hardware segmentation is *not* used, and page mapping
is used to implement the logical segments in the executable
files. In other words, both Windows and Linux treat the Intel
architecture as if it had flat addressing.

A segment is *not* a hardware addressing mode, or 'hardware
implementation' as you put it.

You're the one who has been claiming a relationship to hardware,
not me. Just a few lines above, in fact: "it is related to how
the hardware addresses in most modern PC's."

A segment is a portion , a piece , a section, find a
dinosaurus. A memory segment is therefore a piece of memory,
and this is what we are talknig about/ The memory segments we
are talking about are text, code , data etc. There is no need
to confuse this with CPU addressing modes.

So why do you say "it is related to how the hardware addresses
in most modern PC's"? You can't have it both ways. (Actually
you can. All you have to do is realize that the word "segment"
has two distinct technical meanings here.)

Having said that
the CPU addressing mode is related to memory segments, in many cases, even
on some flat models as I explained with the wintel example. Windows uses
segment registers in application programs of 16,32 and 64-bit addressing
modes. The registers are initialised by the program loader to point to their
respective segments as defined in the program header.

All segment registers are initialized to point to the same thing
in an application program under Windows, at least in the usual
modes of operation. Windows does *not* use hardware segment
registers in any way related to segments defined in the .exe.

You can suggest you were talking about a segment of pizza from last night ,
but the discussion here wasn't about that.

The hardware won't work without the OS and vice-versa, the two are
interelated.

The hardware works very well without the OS. It's just a lot
more work to program, at least for a lot of common uses. (I've
written code for a lot of embedded processors that didn't use an
OS. Once you've got a disk and a terminal, however, it's much
simpler to use the pre-existing code in an OS than to program
the hardware directly.)

Yes here is one I use today:
.NOLIST
#INCLUDE "ti83plus.inc"
#DEFINE ProgStart $9D95
.LIST
.ORG ProgStart - 2
.DB t2ByteTok, tAsmCmp
b_call(_ClrLCDFull)
LD HL, 0
LD (PenCol), HL
LD HL, msg
b_call(_PutS)
b_call(_NewLine)
RET
msg:
.DB "Output text", 0
.END
.END

There are no segments its a flat memory model,

It's possible to implement an assembler/linker without segments.
It's just not very convenient. The last one I saw which didn't
support segments was for the Perkin-Elmer 8-32. The
assembler/linker for the 8080, for example, supported segments,
which allowed putting different parts of the assembled code in
ROM, RAM, EEPROM, or whatever other types of memory you might
have.

 

[James Kanze]

[...]
I can write assembler compiler that can compile this:

"jesus .text", that doesn't prove anything. A text segment is
generally where the assembler puts code.

Any good assembler will support arbitrarily names segments. The
"predefined" names I know include .fini, .init, .rodata and
..text for read-only memory (.fini, .init and .text are
executable code). Most linkers will support more, and there are
good reasons why a compiler might use them. (Traditionally,
there's also a .data, a .bss and a .stack, which will be
relocated to read-write memory.)

A fact.

Not according to the Sparc assembly manual, nor the official
specification of the ELF loader format.

Come on, what are you smoking?

I don't smoke anything. I do read the manuals, and the official
specifications.

 

[hanukas]

On Mar 10, 11:10 pm, James Kanze <[email protected]> wrote:

    [...]

I can write assembler compiler that can compile this:
"jesus .text", that doesn't prove anything. A text segment is
generally where the assembler puts code.

Any good assembler will support arbitrarily names segments.  The
"predefined" names I know include .fini, .init, .rodata and
.text for read-only memory (.fini, .init and .text are
executable code).  Most linkers will support more, and there are
good reasons why a compiler might use them.  (Traditionally,
there's also a .data, a .bss and a .stack, which will be
relocated to read-write memory.)

A fact.

Not according to the Sparc assembly manual, nor the official
specification of the ELF loader format.

Come on, what are you smoking?

I don't smoke anything.  I do read the manuals, and the official
specifications.

No, what you do is you provide more information, which does not, by-
the-way, invalidate the less verbose presentation. You're going on and
on about the details, mention ELF, Sparc, and on and on. I am keeping
this at abstract / generic level. None of what I say is untrue. Fact.

Take care?

 

[Paul]

[...]

Obviously, you didn't read what you are responding to, or you didn't
understand it.

Yes I read what you wrote re:
"Any modern linker will understand segments, in order to give you more
control of where things are placed in memory. This has nothing to do
with
how the hardware addresses things"

And I disagree with you ,

It's not really a question of opinion.

it is related to how the hardware addresses in
most modern PC's.

First, it has nothing to do with PC's, modern or otherwise.
Only one architecture is used on PC's, at least as far as I
know. Where as all of the linkers understand segments. See
http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf,
for example. (Sun has recently changed its assembler to use
section, rather than segment; the assembler still supports the

When a program is loaded the registers are set up to mirror
the program segments, on a windows implementation I know, I am
not saying this is the case on every implementation.

On the Windows implementations I use (and the Linux ones as
well), the Intel segment registers are all loaded with the same
value; the hardware segmentation is *not* used, and page mapping
is used to implement the logical segments in the executable
files. In other words, both Windows and Linux treat the Intel
architecture as if it had flat addressing.

And a code segment and a stack segment are different pages. The hardware
translates the flat address to the corresponding page table.

You're the one who has been claiming a relationship to hardware,
not me. Just a few lines above, in fact: "it is related to how
the hardware addresses in most modern PC's."

OFC its related.

So why do you say "it is related to how the hardware addresses
in most modern PC's"? You can't have it both ways. (Actually
you can. All you have to do is realize that the word "segment"
has two distinct technical meanings here.)

I can see it boths way too.
But I don't see how you can think the way a program is layed out in memory
is not related to the hardware.

All segment registers are initialized to point to the same thing
in an application program under Windows, at least in the usual
modes of operation. Windows does *not* use hardware segment
registers in any way related to segments defined in the .exe.

Yes for example in protected mode, but this does not mean the hardware has
no relationship with the text and stack segments. The hardware needs to
address different paging tables for each segment to get the real address.
This is what i mean by modern PC's , this type of paging is typical of a
modern multi-process PC and the hardware is involved in the translation from
virtual to real memory addresses , dependant on the segment or page.

The hardware works very well without the OS. It's just a lot
more work to program, at least for a lot of common uses. (I've
written code for a lot of embedded processors that didn't use an
OS. Once you've got a disk and a terminal, however, it's much
simpler to use the pre-existing code in an OS than to program
the hardware directly.)

Yes well I was talking about modern pc's which are pretty useless without an
OS.
Embedded systems don't even need software after you've programmed the ROM.

It's possible to implement an assembler/linker without segments.
It's just not very convenient.

THis is a bad description , the assembler/linker does what you tell it to
do, if you tell it to generate a program with no segments it does just that
(hopefully)

The last one I saw which didn't
support segments was for the Perkin-Elmer 8-32. The
assembler/linker for the 8080, for example, supported segments,
which allowed putting different parts of the assembled code in
ROM, RAM, EEPROM, or whatever other types of memory you might
have.

OFC the program I desribed above is for a ti calculaor which also has flash
memory, this is just a different address range and can be considered a
different segment. But this is not the same thing s as what Leigh is on
about with his "text segment" where it contains only executable code, with
some kind of write protection.

The whole subject of memory models is very complicated given the number of
different possible implementation. But I think most will agree its clear
that a function does not exist *only* in a text segement.

 

[Öö Tiib]

OFC the program I desribed above is for a ti calculaor which also has flash
memory, this is just a different address range and can be considered a
different segment. But this is not the same thing s as what Leigh is on
about with his "text segment" where it contains only executable code, with
some kind of write protection.

By C++ standard executable code may have write protection or reside in
physically read-only memory. Converting function pointer into data
pointer is undefined behavior. If you are talking about particular
specific implementation/platform where such conversion is well-defined
then it is better to discuss that in groups dedicated to that
platform. To C++ in general such exceptional logic does not extend.

The whole subject of memory models is very complicated given the number of
different possible implementation. But I think most will agree its clear
that a function does not exist *only* in a text segement.

Yes, the segment names and the whole term of "segment" is not C++
terminology. Function simply does not belong among/convert to ordinary
data in C++. It is executable code and for modifying executable code
run-time you simply lack any features in C++ language.

 

[Paul]

By C++ standard executable code may have write protection or reside in
physically read-only memory.

So if it "may" have write protection I presume it also "may not" have write
protection.

Converting function pointer into data
pointer is undefined behavior.

Interesting concept, I'll take your word for this , seems logical. I wonder
if the same is true in reverse i.e: convert a data pointer into a function
pointer.

If you are talking about particular
specific implementation/platform where such conversion is well-defined
then it is better to discuss that in groups dedicated to that
platform. To C++ in general such exceptional logic does not extend.

Ty for the advice

Yes, the segment names and the whole term of "segment" is not C++
terminology. Function simply does not belong among/convert to ordinary
data in C++. It is executable code and for modifying executable code
run-time you simply lack any features in C++ language.

I'm not so sure about that, I think it may be possible to modify executable
code in C++.
I'm not sure if you are saying that all executable code must be read only,
because you started of by saying it "may" be. If someone can modify a C++
pointer then, can they not modify any part of non-protected memory ?
For example say we had a simple non-protected program with a memory layout
like so:
[PSP][...CODE...][...DATA: int x=0; ][..STACK...]

What happens if our code does:
int* p_x = &x; /*create a pointer to beginning of DATA*/
--p; /*Decrement pointer so it now points to end of CODE*/
*p = 0xC9; /*Overwrite end of CODE with some crap*/

 

[Öö Tiib]

So if it "may" have write protection I presume it also "may not" have write
protection.

What i meant is that C++ is carefully crafted to not introduce
features that expect executable code to be read-write.

Interesting concept, I'll take your word for this , seems logical. I wonder
if the same is true in reverse i.e: convert a data pointer into a function
pointer.

Yes. The pointers to functions and objects are not convertible into
each other in standard-specified manner. You certainly can execute
data on several platforms but that is not feature of C++ language.

The platform vendors actually work against its usage in practice.
Typical practical usage is some document (say pdf) file that uses a
bug in anticipated editor's or viewer's (say acrobat reader) code that
leads to running some document data on your computer and installs bot
in it and merges it into someones botnet. So most users do not feel it
to be desirable feature.

Ty for the advice



I'm not so sure about that, I think it may be possible to modify executable
code in C++.
I'm not sure if you are saying that all executable code must be read only,
because you started of by saying it "may" be.

I did not say it must be read only. C++ is made so that no feature
contradicts with executable code being read only. That is why "may". C+
+ is also carefully crafted to leave enough ends open. If there is
some intended platform feature then we can use full power of platform.

If someone can modify a C++
pointer then, can they not modify any part of non-protected memory ?
For example say we had a simple non-protected program with a memory layout
like so:
[PSP][...CODE...][...DATA:  int x=0; ][..STACK...]

What happens if our code does:
int* p_x = &x; /*create a pointer to beginning of DATA*/
--p;    /*Decrement pointer so it now points to end of CODE*/
*p = 0xC9; /*Overwrite end of CODE with some crap*/

C++ has totally washed its hands here and does explicitly specify
nothing. If it works then that is not related to C++ so it is
advisable to put some static asserts to such places that ensure
someone does not compile it on wrong platform.

On actual concrete cases the outcome varies. It may be success of
overwriting the code or it may be guaranteed access violation signal.
The pointer addresses inside different segments of process are often
made non-sequential by platform so it often simply does not work.

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

[...]

Obviously, you didn't read what you are responding to, or you didn't
understand it.
Yes I read what you wrote re: "Any modern linker will
understand segments, in order to give you more control of
where things are placed in memory. This has nothing to do
with how the hardware addresses things"
And I disagree with you ,

It's not really a question of opinion.

it is related to how the hardware addresses in
most modern PC's.

First, it has nothing to do with PC's, modern or otherwise.
Only one architecture is used on PC's, at least as far as I
know. Where as all of the linkers understand segments. See
http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf,
for example. (Sun has recently changed its assembler to use
section, rather than segment; the assembler still supports the
earlier .seg <name> declaration, however.)

When a program is loaded the registers are set up to mirror
the program segments, on a windows implementation I know, I am
not saying this is the case on every implementation.

On the Windows implementations I use (and the Linux ones as
well), the Intel segment registers are all loaded with the same
value; the hardware segmentation is *not* used, and page mapping
is used to implement the logical segments in the executable
files. In other words, both Windows and Linux treat the Intel
architecture as if it had flat addressing.

And a code segment and a stack segment are different pages.
The hardware translates the flat address to the corresponding
page table.

There is a small ambiguity in what you just said. Each of the
logical segments will have its own set of pages, yes. The CS
and the SS registers on the Intel will both point to the same
page map, and in a real sense, the logical segments cease to
exist.

[...]

But I don't see how you can think the way a program is layed
out in memory is not related to the hardware.

Only in the most general sense, most of the time. The fact that
the hardware supports paged memory and a linear address space,
for example, implies that the linker will lay the memory out
more or less as it likes. At least, the same strategies are
used on radically different architectures.

Yes for example in protected mode, but this does not mean the hardware has
no relationship with the text and stack segments. The hardware needs to
address different paging tables for each segment to get the real address.

Except that under Windows and Linux, it doesn't. Both CS and SS
are initialized by the system to point to the same paging table.
It's the offset within the segment that determines the page.

This is what i mean by modern PC's , this type of paging is
typical of a modern multi-process PC and the hardware is
involved in the translation from virtual to real memory
addresses , dependant on the segment or page.

First, the use of segments is far from typical; Intel
architecture is the only general purpose architecture which uses
them today. And under Windows and Linux, the OS sets things up
so that you can totally ignore their presence.

THis is a bad description , the assembler/linker does what you
tell it to do, if you tell it to generate a program with no
segments it does just that (hopefully)

Also. But it's possible to write an assembler that won't let
you define segments. I've used them. (In the very distant
past.)

[...]

The whole subject of memory models is very complicated given the number of
different possible implementation. But I think most will agree its clear
that a function does not exist *only* in a text segement.

It depends on how you define a function, and what you really
mean by a "text segment". On a Sparc, for example, the segments
really are logical, and cease to exist as such once the program
is loaded. On the other hand, functions, data, and every thing
else are just bits in memory. And on a lot of the older
machines, there wasn't any distinction as to what was what: I
can remember when self-modifying code was a standard procedure.
(For that matter, what do you call the code generated by the
Java JIT compiler. It's pure executable, but it's in what the
linker considered the .bss segment under Unix.)

 

[James Kanze]

So if it "may" have write protection I presume it also "may
not" have write protection.

But anything you can do to write it (or even read it) involves
undefined behavior.

Interesting concept, I'll take your word for this , seems
logical. I wonder if the same is true in reverse i.e: convert
a data pointer into a function pointer.

The two are completely distinct. I've worked on machines where
they had different sizes.

[...]

I'm not so sure about that, I think it may be possible to modify executable
code in C++.

Not without invoking undefined behavior, but of course, anything
that involves machine code is implementation defined anyway.
Java's JIT is written in either C or C++, and it ends up
executing what was initially data; on a much smaller scale, I've
heard of C++ compilers whose generated code dynamically
generated trampolines when initializing a pointer ot member
function.

I'm not sure if you are saying that all executable code must be read only,
because you started of by saying it "may" be. If someone can modify a C++
pointer then, can they not modify any part of non-protected memory ?
For example say we had a simple non-protected program with a memory layout
like so:
[PSP][...CODE...][...DATA: int x=0; ][..STACK...]

What happens if our code does:
int* p_x = &x; /*create a pointer to beginning of DATA*/
--p; /*Decrement pointer so it now points to end of CODE*/
*p = 0xC9; /*Overwrite end of CODE with some crap*/

Undefined behavior. As far as the C++ standard is concerned,
at least; an implementation is free to define it.

 

[Paul]

[...]
Obviously, you didn't read what you are responding to, or you didn't
understand it.
Yes I read what you wrote re: "Any modern linker will
understand segments, in order to give you more control of
where things are placed in memory. This has nothing to do
with how the hardware addresses things"
And I disagree with you ,
It's not really a question of opinion.
it is related to how the hardware addresses in
most modern PC's.
First, it has nothing to do with PC's, modern or otherwise.
Only one architecture is used on PC's, at least as far as I
know. Where as all of the linkers understand segments. See
http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf,
for example. (Sun has recently changed its assembler to use
section, rather than segment; the assembler still supports the
earlier .seg <name> declaration, however.)
When a program is loaded the registers are set up to mirror
the program segments, on a windows implementation I know, I am
not saying this is the case on every implementation.
On the Windows implementations I use (and the Linux ones as
well), the Intel segment registers are all loaded with the same
value; the hardware segmentation is *not* used, and page mapping
is used to implement the logical segments in the executable
files. In other words, both Windows and Linux treat the Intel
architecture as if it had flat addressing.

And a code segment and a stack segment are different pages.
The hardware translates the flat address to the corresponding
page table.

There is a small ambiguity in what you just said. Each of the
logical segments will have its own set of pages, yes. The CS
and the SS registers on the Intel will both point to the same
page map, and in a real sense, the logical segments cease to
exist.

[...]

But I don't see how you can think the way a program is layed
out in memory is not related to the hardware.

Only in the most general sense, most of the time. The fact that
the hardware supports paged memory and a linear address space,
for example, implies that the linker will lay the memory out
more or less as it likes. At least, the same strategies are
used on radically different architectures.

Yes for example in protected mode, but this does not mean the hardware
has
no relationship with the text and stack segments. The hardware needs to
address different paging tables for each segment to get the real address.

Except that under Windows and Linux, it doesn't. Both CS and SS
are initialized by the system to point to the same paging table.
It's the offset within the segment that determines the page.

I'm not on about using segment registers here , I'm talking about how the
hardware addresses different "program segments", and how the program segs
are implemented as pages.
12 bits for the 4k page and 20 bits for something else etc.

It's bursting my brians to try and think about it in such a general case ,
there are too many variations.

First, the use of segments is far from typical; Intel
architecture is the only general purpose architecture which uses
them today. And under Windows and Linux, the OS sets things up
so that you can totally ignore their presence.

Well that reinforces my argument that functions can exisit in places other
than "text segments ", thats all I wanted to prove.

THis is a bad description , the assembler/linker does what you
tell it to do, if you tell it to generate a program with no
segments it does just that (hopefully)

Also. But it's possible to write an assembler that won't let
you define segments. I've used them. (In the very distant
past.)

[...]

The whole subject of memory models is very complicated given the number
of
different possible implementation. But I think most will agree its clear
that a function does not exist *only* in a text segement.

It depends on how you define a function, and what you really
mean by a "text segment". On a Sparc, for example, the segments
really are logical, and cease to exist as such once the program
is loaded. On the other hand, functions, data, and every thing
else are just bits in memory. And on a lot of the older
machines, there wasn't any distinction as to what was what: I
can remember when self-modifying code was a standard procedure.
(For that matter, what do you call the code generated by the
Java JIT compiler. It's pure executable, but it's in what the
linker considered the .bss segment under Unix.)

--

Again, thats all I wanted to prove
ty for your post.

 

[Paul]

[...]
Obviously, you didn't read what you are responding to, or you
didn't
understand it.

Yes I read what you wrote re: "Any modern linker will
understand segments, in order to give you more control of
where things are placed in memory. This has nothing to do
with how the hardware addresses things"

And I disagree with you ,

It's not really a question of opinion.

it is related to how the hardware addresses in
most modern PC's.

First, it has nothing to do with PC's, modern or otherwise.
Only one architecture is used on PC's, at least as far as I
know. Where as all of the linkers understand segments. See
http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf,
for example. (Sun has recently changed its assembler to use
section, rather than segment; the assembler still supports the
earlier .seg <name> declaration, however.)

When a program is loaded the registers are set up to mirror
the program segments, on a windows implementation I know, I am
not saying this is the case on every implementation.

On the Windows implementations I use (and the Linux ones as
well), the Intel segment registers are all loaded with the same
value; the hardware segmentation is *not* used, and page mapping
is used to implement the logical segments in the executable
files. In other words, both Windows and Linux treat the Intel
architecture as if it had flat addressing.

And a code segment and a stack segment are different pages.
The hardware translates the flat address to the corresponding
page table.

There is a small ambiguity in what you just said. Each of the
logical segments will have its own set of pages, yes. The CS
and the SS registers on the Intel will both point to the same
page map, and in a real sense, the logical segments cease to
exist.

[...]
But I don't see how you can think the way a program is layed
out in memory is not related to the hardware.

Only in the most general sense, most of the time. The fact that
the hardware supports paged memory and a linear address space,
for example, implies that the linker will lay the memory out
more or less as it likes. At least, the same strategies are
used on radically different architectures.

Having said that the CPU addressing mode is related to
memory segments, in many cases, even on some flat models as
I explained with the wintel example. Windows uses segment
registers in application programs of 16,32 and 64-bit
addressing modes. The registers are initialised by the
program loader to point to their respective segments as
defined in the program header.

All segment registers are initialized to point to the same thing
in an application program under Windows, at least in the usual
modes of operation. Windows does *not* use hardware segment
registers in any way related to segments defined in the .exe.

Yes for example in protected mode, but this does not mean the
hardware has
no relationship with the text and stack segments. The hardware needs to
address different paging tables for each segment to get the real
address.

Except that under Windows and Linux, it doesn't. Both CS and SS
are initialized by the system to point to the same paging table.
It's the offset within the segment that determines the page.

I'm not on about using segment registers here , I'm talking about how
the hardware addresses different "program segments", and how the program
segs are implemented as pages.
12 bits for the 4k page and 20 bits for something else etc.

It's bursting my brians to try and think about it in such a general case
, there are too many variations.

This is what i mean by modern PC's , this type of paging is
typical of a modern multi-process PC and the hardware is
involved in the translation from virtual to real memory
addresses , dependant on the segment or page.

First, the use of segments is far from typical; Intel
architecture is the only general purpose architecture which uses
them today. And under Windows and Linux, the OS sets things up
so that you can totally ignore their presence.

Well that reinforces my argument that functions can exisit in places
other than "text segments ", thats all I wanted to prove.

I dealt with segments long before the 8086 appeared, on
machines with flat addressing and no memory protection.

Yes here is one I use today:
.NOLIST
#INCLUDE "ti83plus.inc"
#DEFINE ProgStart $9D95
.LIST
.ORG ProgStart - 2
.DB t2ByteTok, tAsmCmp
b_call(_ClrLCDFull)
LD HL, 0
LD (PenCol), HL
LD HL, msg
b_call(_PutS)
b_call(_NewLine)
RET
msg:
.DB "Output text", 0
.END
.END

There are no segments its a flat memory model,

It's possible to implement an assembler/linker without segments.
It's just not very convenient.

THis is a bad description , the assembler/linker does what you
tell it to do, if you tell it to generate a program with no
segments it does just that (hopefully)

Also. But it's possible to write an assembler that won't let
you define segments. I've used them. (In the very distant
past.)

[...]
The whole subject of memory models is very complicated given the
number of
different possible implementation. But I think most will agree its
clear
that a function does not exist *only* in a text segement.

It depends on how you define a function, and what you really
mean by a "text segment". On a Sparc, for example, the segments
really are logical, and cease to exist as such once the program
is loaded. On the other hand, functions, data, and every thing
else are just bits in memory. And on a lot of the older
machines, there wasn't any distinction as to what was what: I
can remember when self-modifying code was a standard procedure.
(For that matter, what do you call the code generated by the
Java JIT compiler. It's pure executable, but it's in what the
linker considered the .bss segment under Unix.)

--

Again, thats all I wanted to prove
ty for your post.

You have proven nothing. After compilation functions (member or
otherwise) only exist as machine code in the text segment; in C++ a member
function is a member of a class not a member of an object.

I don't care about proving anything to you. You are nothing more than an
idiot, who cares what you think.