arithmetic on a void * pointer

[Seebs]

For example ...?

Some Big Iron is not naturally byte-addressed, so (void *) has to have
a regular address plus an offset, same as (char *).

Basically, it really comes across as though you have little to no
experience with a broad range of systems or compilers, and you're just
looking for a fight, but you haven't even suggested a single reason
for which you shouldn't just use (unsigned char *) for the kinds of
operations you appear to wish to perform.

-s

 

[Seebs]

Apparently -Wall really only means -Wsome.

Yeah. I think there's a few warnings you get with plain -W that aren't in
-Wall either.

-s

 

[Seebs]

Is it now. The size in what units? void has no size. So how do we
know the size of the units a void * points to? Is that size the number
of int's? Of struct foo's?

In bytes, because that's what sizeof() yields.

Ah, always in bytes you say. Excellent. Now we know the implicit size
of void.

No. void is an incomplete type that cannot be completed.

A "void *" is not a pointer to a byte, it's a pointer to an object of
unknown type which may consist of multiple bytes.

-s

 

[Mark]

The problem is that C's "standardised formality" is bought by
simultaneously calling things undefined and permitting vendors to
continue to support the "undefined" concepts. C is simply not
formalized save in the most "Platonist" sense as opposed to the
"Intuitionist" sense, where Platonism in the philosophy of mathematics
is the belief that mathematical objects exist *in reality* whether or
not we know them, whereas Intuitionism is the belief that it doesn't
exist until it's constructed.

Now, it would seem that Intuitionism would be the philosophy of the
competent programmer.

I guess that there is an issue of context, as I suggested elsewhere.
If you want to use C within one context (one where you treat the
behaviour of a particular implementation as being the de-facto
definition of "C" - which may not be an unreasonable approach, depending
on the situation), you view it one way. If you want any chance of
writing something that will behave in a predictable way in a different
environment (different compiler/OS/whatever) or when underlying
assumptions change (word sizes changing on your platform, for example),
you take a different view.

I accept that you take the view that there is no such thing as
portability when it comes to C. (I'd also agree that if you take the
first approach, you're right.)

[And at this point let me mention my sadness on hearing that Dik
Winter has passed away, for this type of statement is what he loved to
jump on: perhaps as a Dutch person he felt a special connection with
Intuitionism, and he always had something interesting to contribute to
the discussion, especially when I mentioned Brouwer or Dijkstra.]

Applying this to programming, to say "doing arithmetic on a void
pointer has no result" is Platonic since Adler showed (constructively
and in an intuitive/Intuitionist way) how this has a sensible meaning:
the sizeof a void pointer is the sizeof the smallest unit of memory.
It is Platonist to insist on the (unconstructed) possibility of an
alternative interpretation.

Clearly, doing arithmetic on a void pointer produces a result, but
whether it's useful or reliable is a different issue.

Read Fowler/Burchfield Modern English Usage. Fowler makes no attempt
whatsoever to legislate what English should be, only what literate
people do. For example, Burchfield usefully notes that UK speakers
have FINALLY (as of the latest edition) given us an English
"construct" that is sorely needed: a reflexive pronoun that means
"himself or herself". "Themself" has been spotted by Burchfield:
"someone has hurt themself". Likewise, Adler's idiom makes perfect
sense.

Sure - I've read Fowler, though it's a few years since I picked it up.

It describes some ways that people use English, with the recognition
that natural language evolves and changes. Indeed, in the case of
English, there is a good bit of parallel development because of the
number of large, but geographically separated, first-language users of
English.

But I'm still not convinced that we should try to map between languages
for humans and languages for machines in quite this way at this stage in
language development.

Your last statement is literally untrue in most cases, in C. There is
no runtime check, and there are cases of code that dereferences "bad"
pointers and gets away with it,.

Yes, it is true that you can often get away with all sorts of things.
If, however, you read it in conjunction with the paragraphs just above,
you see the problem; you might get away with it today, tomorrow or the
next decade. When the situation changes (word sizes, pointer handling,
whatever), your code suddenly doesn't work as you intended (and how it
had been behaving) and the vendor may or may not feel that it's there
responsibility to reproduce the old (but undocumented) behaviour in
newer iterations of the compiler.

Sticking to behaviours that are documented should avoid these problems.

All very true but irrevelant to Adler's (Intuitionist) point: that one
test of a construct is whether we can construct a working runtime
model.

Fair enough - but the delivery the right output isn't a good basis on
which to judge the correctness/appropriateness of the inputs or the
process applied. Language features shouldn't be black boxes.

Whereas an earlier generation of C programmers (myself included)
graduated into C (and out of it in my case when I realized its
limitations) from assembler, many posters here started with C and may
have been crippled by it to the extent that they assault authors like
Schildt for speaking of stacks and heaps.

I would agree that there are people who have not experience a
wide-enough range of language-types and have tunnel-vision on the
"right" way to do things based on a narrow definition of "right"ness.

I haven't read Schildt (so I can't and won't comment on him), but I have
found it to be the case in a fair number of other language guides and
references. I have particular experience of this in C++* where the
quality of the commentary varied wildly, and the language was often
misrepresented -- not that C++ doesn't have lots of things to dislike in
any case. ;-)

Where authors present concepts or actual code which mislead readers
about norms within the language standards (without acknowledging that
fact), I have problems with it - and that includes cases where it has
been done to assist the beginner. If we believe a feature is wrong, we
should say so up front. If we choose to simplify for a beginner, we
should state that and (I would argue) it should probably be corrected
later in the book once the beginner is at a point where they can manage
the unsimplified version.

The practical outcome of misleading students used to come up from time
to time. For example, I would set exercises and find that students
would present solutions which only worked when compiled with a specific
compiler and/or executed on a specific platform**.

Simplification for the beginner is a good thing, but it shouldn't be
that the beginner gets a nasty surprise later on when someone says
"You're doing that wrong!". It can be very embarrassing for them.

* I taught it at Undergraduate level for a number of years, and was sent
dozens of books for review, and there were many that were just bad in
a variety of different ways.
** The worst case of this, I had to find an old version of Windows,
compile it with an obscure compiler and it still didn't work
properly. The student felt hard-done-by that he lost a lot of marks (I
wrote the markscheme so that I could still give marks for concepts - it
was an SE module which explicitly used C++ rather than a C++ module)
because the book he used (which was designed to go with this compiler)
contained examples which he based his submission on. It just didn't
match the language and didn't work as advertised.
I *had* warned them that I would be testing them with g++ on Linux
and VC++ on Windows (with specified versions), so I wasn't just being
mean.

 

[BGB / cr88192]

write() is not part of the C standard.

FWIW, it is part of POSIX, which FWIW is almost as much a definition of "the
truth of the matter" as the C standard, given that both are of a comparable
age and are of similar origins.

nevermind that not all OS's are POSIX conformant, which more sets a
practical limit than a formal one.


it is all about which standard has more weight and more authority and in
what context.
for the Windows' developer, every word from MS's mouth is gold, and every
value of every flag is etched in stone...

And actually, no. size_t is the size-in-bytes, canonically, since that's
what sizeof(x) yields.

I think the point is that it is inconsistent to pass one type but give a
measurement in another.

to think that 'void' is purely without size would essentially make giving a
size in bytes as a semantic inconsistency. to accept that the pointer-type
is 'void *', yet that the size is bytes, thus "strongly implies" the
existence of a size (even if one does not exist in someones' formalistic
notions...).

It works, but it's dumbing things down -- it's encouraging sloppy thinking
about pointer types, and that ain't good.

it makes sense to the CPU, and in the end, it is this which is what matters.

maybe the "slopiness" is humans for believing in a world with "objects"
which are anything other than bytes?... (much as they believe in a physical
world composed of things too far above the level of individual particles and
the internal reactions of so many fields?...).

it may well be the formality which is what is incorrect, rather than that of
the world being formalized.
since, a formalized world may well allow things which are impossible in the
actual world, and in this case, it is the formalism said to be incorrect
rather than the world being incorrect for not causing the formal definition
to work exactly as expected.

"all hail Von Neumann..."


nevermind that for many practical reasons, one may confine themselves to
these alternative formalistic realities. the fantasy of types apart from
representation, of value-propagation apart from a set of mutable states, ...

only that any such definition is not an equivalent of the reality in
question, merely a sort of tool, be it for mental or practical application
(a sort of self-deciet as it were, to live in realities where one knows they
are not really the case, none the less it is all the case that one live and
behave as if they were...).


or such...

 

[Ersek, Laszlo]

Yeah. I think there's a few warnings you get with plain -W that aren't in
-Wall either.

For debug builds, I like to use these gcc options:

-pipe -ansi -pedantic -fhosted -fno-builtin -Wall -Wextra -Wfloat-equal \
-Wundef -Wshadow -Wlarger-than-32767 -Wpointer-arith -Wbad-function-cast \
-Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wformat=2 \
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls \
-Wnested-externs -Wunreachable-code -Winline -Wlong-long

Adding -O2 may or may not be useful. Both -Wall and -Wextra depend on
the selected optimization level. For example, -Wuninitialized is
included by either of them iff the optimization level is at least 1.
Sometimes -Wuninitialized catches real errors, at other times it
produces false warnings.

Cheers,
lacos

 

[Keith Thompson]

Mark Adler wrote: [...]

Apparently -Wall really only means -Wsome.

No, it means exactly what it says, show all warnings for the current
setting of the other flags. As you chose not to set any other flags
you get the default version of gcc which happens to include a number
of extensions and is not standard conforming.

No, -Wall is equivalent to a specific set of other warning flags.
"gcc -Wall" enables warnings that "gcc" by itself does not.

See "info gcc" or
<http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Warning-Options.html>.

 

[Eric Sosman]

[...]
And actually, no. size_t is the size-in-bytes, canonically, since that's
what sizeof(x) yields.

There are, however, functions in the Standard library taking
size_t parameters that do not specify byte counts. calloc(),
qsort(), bsearch(), fwrite(), and fread() come to mind immediately,
and there may be others.

 

[Kenny McCormack]

Mark Adler wrote: [...]

Apparently -Wall really only means -Wsome.

No, it means exactly what it says, show all warnings for the current
setting of the other flags. As you chose not to set any other flags
you get the default version of gcc which happens to include a number
of extensions and is not standard conforming.

No, -Wall is equivalent to a specific set of other warning flags.
"gcc -Wall" enables warnings that "gcc" by itself does not.

See "info gcc" or
<http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Warning-Options.html>.

Francis's post was obviously confused and bewildered.
I don't think it was really necessary to rebut it.

 

[Keith Thompson]

Is it now. The size in what units? void has no size. So how do we
know the size of the units a void * points to? Is that size the
number of int's? Of struct foo's?


Ah, always in bytes you say. Excellent. Now we know the implicit
size of void.

No, we don't, because void has no implicit size. We know the units
specified for the size in those specific functions because it's
documented. The units for the size argument are give by the function
not by the void* argument.

fread(), fwrite(), and calloc() all take size_t arguments that denote
sizes in objects, not in bytes.

[...]

Anyway, I like Keith's proposal better, which is to have a "byte" type
which would combine the type behavior of char (or better yet unsigned
char) with the casting behavior of void.

Thanks. I'm not entirely sure I do. }

[...]

Anyway, this has been enjoyable and instructive for me, so thank you
all for your time. Some people seem to get a little ruffled in these
religious discussions, so I hope I didn't offend anybody. So as to
not waste any more of your time, I'll leave you alone and go back to
working on the next release of zlib, which now has two occurences of
buf = (char *)buf + n.

One thing that I find a bit offputting (I wouldn't say offensive)
is the idea that these discussions are "religious". C is just
a language; this newsgroup is, for me at least, just a hobby.
Very likely you're being facetious and I'm overreacting, but we've
had people here who really do treat this like a religious argument.

 

[Keith Thompson]

Oops - cause for confusion there. To disambiguate: the term
"assignable lvalue" apparently used by Eric Sosman (I didn't see his
article, so I'm taking the dangerous course of relying on the accuracy
of the quoted material) is more formally known as "modifiable
lvalue". An array is, of course, an example of an lvalue that is *not*
modifiable.

Small quibble: An expression of array type is (usually) an example of
an lvalue that is not modifiable. In C, lvalues are a subset of
expressions; an object (I assume that by "array" you meant "array
object") cannot be an lvalue.

 

[Kenny McCormack]

One thing that I find a bit offputting (I wouldn't say offensive)
is the idea that these discussions are "religious". C is just
a language; this newsgroup is, for me at least, just a hobby.
Very likely you're being facetious and I'm overreacting, but we've
had people here who really do treat this like a religious argument.

And you are the prototype for it, and the prototypical instance.

 

[Antoninus Twink]

One thing that I find a bit offputting (I wouldn't say offensive) is
the idea that these discussions are "religious".

Does that mean you're going to take a step back and reflect on the way
you make them "religious"?

No, thought not.

this newsgroup is, for me at least, just a hobby.

Yeah, sure. And I'm Elvis Presley.

This group is your life, Keith. It's what gives your cold, autistic life
meaning. No insult intended - it's just a blindingly obvious fact.

Very likely you're being facetious and I'm overreacting, but we've had
people here who really do treat this like a religious argument.

Do you really have such little self-awareness, Keith? One can only
imagine what it must be like to be trapped in your autistic head - a sad
and frightening thought. Once again, no insult intended - I mean that
sincerely.

 

[Keith Thompson]

it makes sense to the CPU, and in the end, it is this which is what matters.

What matters more is what makes sense to the programmer and to the
reader of the code. What matters is constructing a consistent model
for computation, and letting the compiler map that model onto some
particular hardware.

If we only cared about what makes sense to the CPU, we wouldn't have
more than a handful of types, all defined by the system, and portable
code would be a pipe dream.

[...]

 

[Beej Jorgensen]

Apparently -Wall really only means -Wsome.

"We're safe. We're in the hold of one of the ships of the Vogon
Constructor Fleet."

"Ah. This is obviously some strange definition of the word 'safe' I
hadn't previously been aware of."

-- Ford and Arthur, The Hitchhikers Guide to the Galaxy

Yeah... It's not exactly well-named. Here's what I use to compile stuff
when I'm testing for compliance:

alias c99='gcc -Wall -Wextra -std=c99 -pedantic'

But even that might not be enough to get /all/ the warnings; by the gcc
man page:

Note that some warning flags are not implied by -Wall. Some of them
warn about constructions that users generally do not consider
questionable, but which occasionally you might wish to check for;
others warn about constructions that are necessary or hard to avoid
in some cases, and there is no simple way to modify the code to
suppress the warning. Some of them are enabled by -Wextra but many
of them must be enabled individually.

The man page says this about -pedantic:

Issue all the mandatory diagnostics listed in the C standard. Some
of them are left out by default, since they trigger frequently on
harmless code.

-Beej

 

[BGB / cr88192]

What matters more is what makes sense to the programmer and to the
reader of the code. What matters is constructing a consistent model
for computation, and letting the compiler map that model onto some
particular hardware.

If we only cared about what makes sense to the CPU, we wouldn't have
more than a handful of types, all defined by the system, and portable
code would be a pipe dream.

granted, but these are still secondary, since if the CPU could not
understand the code or the data, the program would not run.

no matter how elegant the conceptual model, it would be pointless to have SW
which doesn't run...


the CPU is inescapable, as noted by how people may still end up needing to
fall back to using assembler in many situations, and just the same, it is
sometimes / often needed to make use of these low-level details of how data
is represented on particular HW to have much of any real hope of making the
app work effectively...

universal portability for non-trivial apps IS a "pipe dream", apart from the
fact that luckily most HW tends to represent most things in similar enough
ways that one can gloss over the details in the majority of cases (and fall
back to good old "#ifdef" for most of the rest...).

and so, abstraction is a tower built on top of the HW, and not the other way
around.


none of this really changes the end case, that in the end it is the CPU
which matters...

if what were important were appeasing the mind of the reader of the code,
then people would be authors, not programmers, and the end result would be a
novella, rather than a codebase...

 

[Keith Thompson]

granted, but these are still secondary, since if the CPU could not
understand the code or the data, the program would not run.

no matter how elegant the conceptual model, it would be pointless to have SW
which doesn't run...

Sure, but the particular abstractions we're talking about, such as
having void* be a raw pointer type that doesn't let you access what it
points to without first converting the pointer, don't prevent the
software from running. Implementers and programmers are entirely
capable of writing working software using the abstractions defined by
the C language.

the CPU is inescapable, as noted by how people may still end up needing to
fall back to using assembler in many situations, and just the same, it is
sometimes / often needed to make use of these low-level details of how data
is represented on particular HW to have much of any real hope of making the
app work effectively...

I don't think that's as common as you imply. I don't remember the
last time I needed to resort to assembler. (For a lot of my own
programming, I don't even resort to C, but that's another story.)

universal portability for non-trivial apps IS a "pipe dream", apart from the
fact that luckily most HW tends to represent most things in similar enough
ways that one can gloss over the details in the majority of cases (and fall
back to good old "#ifdef" for most of the rest...).

and so, abstraction is a tower built on top of the HW, and not the other way
around.

The abstraction level provided by standard C seems to be just about
right for a lot of purposes, and I don't find that it gets in the way
of writing efficient code in most cases. And in cases where it does,
you can often write non-portable code, making additional
implementation-specific assumptions, without leaving the language.

I really wouldn't want to make C any lower level than it already is.

none of this really changes the end case, that in the end it is the CPU
which matters...

if what were important were appeasing the mind of the reader of the code,
then people would be authors, not programmers, and the end result would be a
novella, rather than a codebase...

For the software I work on, I spend a lot more time maintaining it
than running it. It's not a work of literature, but clarity and
legibility are vitally important if I'm going to finish the job
quickly enough for performance on the CPU to matter.

 

[BGB / cr88192]

[...]
I would argue that alternatively we could eliminate this mixed
message
of void both implicitly having a size and not having a size by
changing
the C standard to give void a size, i.e. one. sizeof(void) == 1.
Nothing would break -- this would just add to the things that can be
expressed, in a way that is consistent with how library functions use
void * arguments. (The void type would still not be allowed by
itself,
and so function(void) would still mean no arguments.) In fact, in
the
evil gcc, n = sizeof(void); sets n to 1, and it seems to work fine.

It works, but it's dumbing things down -- it's encouraging sloppy
thinking
about pointer types, and that ain't good.

it makes sense to the CPU, and in the end, it is this which is what
matters.

What matters more is what makes sense to the programmer and to the
reader of the code. What matters is constructing a consistent model
for computation, and letting the compiler map that model onto some
particular hardware.

If we only cared about what makes sense to the CPU, we wouldn't have
more than a handful of types, all defined by the system, and portable
code would be a pipe dream.

granted, but these are still secondary, since if the CPU could not
understand the code or the data, the program would not run.

no matter how elegant the conceptual model, it would be pointless to have
SW
which doesn't run...

Sure, but the particular abstractions we're talking about, such as
having void* be a raw pointer type that doesn't let you access what it
points to without first converting the pointer, don't prevent the
software from running. Implementers and programmers are entirely
capable of writing working software using the abstractions defined by
the C language.

granted.

however, C was also designed to run well on actual computers...

I don't think that's as common as you imply. I don't remember the
last time I needed to resort to assembler. (For a lot of my own
programming, I don't even resort to C, but that's another story.)

ASM is, in my case, my second most commonly used language (after C), the 3rd
is C++.
some also goes into very-specialized mini-languages (the most complex and
general of which, at this point, is my compilers' IL, but there are many
cases where I use very limited notations which usually drive specialized
state machines, ...).

many of these specialized mini-languages are used in close proximity to
machine code, either in encoding or decoding machine instructions, or in
some cases driving logic which essentially produces machine code from them.

most of my use of ASM is mixed up with the use of C, where a lot of C code
exists which produces ASM fragments (probably by far my largest-scale use of
ASM at this point).

it is fairly rare that I produce non-trivial amounts of standalone ASM code,
since for what I do, "ASM metaprogramming" is generally more useful.

the weak point though is that a lot of this code has to be either duplicated
or tweaked for every target (so, I don't often use it needlessly...).

use command strings to drive state-machines (typically specialized and
tweaked for a specific target or use) which produce ASM, which is in turn
sent to a dynamic assembler, which may parse it and produce machine code
(this process itself done with more specialized string-driven state
machines), and then linked into the running image. from this point, one may
fetch function pointers and call into the code, or maybe produce yet more
machine code from yet so many more strings...

apart from this, there are a few natural limitations to C which would be
very problematic to work around...


similarly, it is often very useful to be able to treat memory and data (and,
sometimes, machine code) as raw collections of bytes...

The abstraction level provided by standard C seems to be just about
right for a lot of purposes, and I don't find that it gets in the way
of writing efficient code in most cases. And in cases where it does,
you can often write non-portable code, making additional
implementation-specific assumptions, without leaving the language.

I really wouldn't want to make C any lower level than it already is.

granted, but C is also one of the lower-level languages around...


it seemed to me like you were trying to invert the "grand ontology", as in,
another of those people who try to claim that computers are based on the
formal notions humans have about them, ... which to me seems absurd.

but, these types also tend to promote pure FPL's, such as Haskell, ...

I guess, it is the great thing where, as I see it, the basis of reality is
reality...

For the software I work on, I spend a lot more time maintaining it
than running it. It's not a work of literature, but clarity and
legibility are vitally important if I'm going to finish the job
quickly enough for performance on the CPU to matter.

granted...

well, it is not like I am advocating writing tangled horrors of code either,
as I have also seen plenty of nasty enough code around.


but, I have also seen people try to promote "English-based" programming
languages, and have almost just as often seen these languages go nowhere...

maybe, it is that computers don't do English well, or, more likely, it is
that English is a very bad choice to try to base a programming language on.


but, if humans were in-fact the primary concern, then likely it would have
caught on regardless, considering how much easier of a time most people have
with English than with programming languages...

the fact that they have not, likely indicates that the primary concerns lie
elsewhere.

I personally suspect that it is the computer which remains primary...

humans adapt their mind to the computer, and not the computer around their
mind.

this is probably preferable anyways, as most peoples' minds are fluid and
vague, and it would probably suck if the everything were random and
ambiguous...

 

[spinoza1111]

And you are the prototype for it, and the prototypical instance.

Sure. The strategy being to say it's all a joke AFTER you've destroyed
people's reputations. They is just good old boys. They's just having
fun.

 

[spinoza1111]

OK, there are differences. However, the alternative (C as math or a
formal language) fails to fit the facts.

The problem is that C's "standardised formality" is bought by
simultaneously calling things undefined and permitting vendors to
continue to support the "undefined" concepts. C is simply not
formalized save in the most "Platonist" sense as opposed to the
"Intuitionist" sense, where Platonism in the philosophy of mathematics
is the belief that mathematical objects exist *in reality* whether or
not we know them, whereas Intuitionism is the belief that it doesn't
exist until it's constructed.

Now, it would seem that Intuitionism would be the philosophy of the
competent programmer.

[And at this point let me mention my sadness on hearing that Dik
Winter has passed away, for this type of statement is what he loved to
jump on: perhaps as a Dutch person he felt a special connection with
Intuitionism, and he always had something interesting to contribute to
the discussion, especially when I mentioned Brouwer or Dijkstra.]

Applying this to programming, to say "doing arithmetic on a void
pointer has no result" is Platonic since Adler showed (constructively
and in an intuitive/Intuitionist way) how this has a sensible meaning:
the sizeof a void pointer is the sizeof the smallest unit of memory.

No it isn't. The sizeof any pointer is the number of bytes used to store
a pointer value (generalised address). The size of a void* is required
to be the same size as the size of a char*. On most systems it is 4 or
8.  That is not the same as the size of the thing pointed to. And that

We know that.

is the point, a void* object holds a location not the address of an

This is Scholastic pettifogging in service of the false proposition
that C is strongly typed. The location is the address. You're trying
to give a punning language a false respectability. C committs so many
crimes against common sense (such as the preprocessor) it wouldn't
hurt to allow void pointers of sizeof 4 or 8 on many machines,
pointing at the smallest addressable unit of storage, something with
sizeof==1. It would allow us to use C as a truly portable assembly
language. Not that I want to.

object. If the programmer knows what is at that location they can
convert the location information into an appropriate pointer value.

This is not rocket science and is generally well understood by qualified
computer scientists (i.w. those with CS degrees) who have learnt C.


No it isn't. Both Platonists and Intuitionists along with several other
schools of mathematical philosophy well understand the difference
between the container and the contents, the reference and the referee.

Hmm, there are only three according to Stefan Korner's out of print
survey: logicism-Platonism, Intuitionism, and formalism. Stewart
Shapiro (The Oxford Handbook of Philosophy of Mathematics and Logic)
lists only five: logicism, Mills' and Quine's empiricism, nominalism,
intuitionism and structuralism. I regard Korner's as the better
taxonomy as long as you add empiricism, better in the sense of being
mutually exclusive and exhaustive.

The existence or nonexistence of personae who well understand is a
rather shadowy argument, that uses poppets to "prove" that
everything's under control. The question is whether you can understand
in the sense of explain.

Most American universities socialize their students into Platonism (cf
Robert M Pirsig's experience at the University of Chicago as
documented in Zen and the Art of Motorcycle Maintenance). This is
because to function in the world as upper middle class high earners,
the students must accept the existence of Platonic Ideas in the form
of immortal corporations with actual human rights under the Fourteenth
Amendment.

This causes people here to treat any sort of assertion *with which
they agree* as of equal value with more informative and intuitionist-
in-the-sense-of-constructive assertions. It's why it's the height of
wisdom to groan that something's "undefined" and that one may not
assign void pointers a dereferencing meaning.