C objects

[Keith Thompson]

Re: standards documents off-topic in comp.lang.c

Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <lnvffi3jth.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[/color]
[...][color=blue][color=green]
> >Most such implementations provide a mode in which they
> >conform as closely as possible to the standard without extensions,
> >such as gcc's "-ansi -pedantic -W -Wall" or "-std=c99 -pedantic -W -Wall"
> >mode.[/color]
>
> You're confused/confusing here. First, the -W and -Wall options have
> absolutely nothing to do with standard conformance: they enable *only*
> diagnostics that are NOT required by any C standard. gcc has only one
> standard conforming mode and this is enabled using -ansi -pedantic, or,
> equivalently, -std=c89 -pedantic (I'm deliberately ignoring the option
> for C94 conformance, to keep things as simple as possible). -ansi
> disables gcc's deviations from the standard and -pedantic enables some
> required diagnostics that gcc doesn't generate by default.[/color]

I had assumed that "-W -Wall" enabled some required diagnostics, but
if you say "-ansi -pedantic" suffices, I'll take your word for it.

(Using "-W -Wall" as well is generally a good idea, but that's not
necessarily related to conformance.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

Re: C objects

Mabden wrote:
[color=blue]
> E. Robert Tisdale wrote:
>[color=green]
>>I believe that, currently, *all* viable C compilers
>>use all-bits-zero for NULL
>>so this is something that you don't need to worry about.[/color]
>
> But I am assured this is not the case! You may NOT use the word "ALL".[/color]

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

[CBFalconer]

Re: C objects

"E. Robert Tisdale" wrote:[color=blue]
> Mabden wrote:[color=green]
>> E. Robert Tisdale wrote:
>>[color=darkred]
>>> I believe that, currently, *all* viable C compilers
>>> use all-bits-zero for NULL
>>> so this is something that you don't need to worry about.[/color]
>>
>> But I am assured this is not the case! You may NOT use the
>> word "ALL".[/color]
>
> Please cite an example of a standard conforming C compiler
> that does *not* use all-bits-zero for NULL.[/color]

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

Now please cease the trolling.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Keith Thompson]

Re: C objects

CBFalconer <cbfalconer@yah oo.com> writes:[color=blue]
> "E. Robert Tisdale" wrote:[color=green]
> > Mabden wrote:[color=darkred]
> >> E. Robert Tisdale wrote:
> >>
> >>> I believe that, currently, *all* viable C compilers
> >>> use all-bits-zero for NULL
> >>> so this is something that you don't need to worry about.
> >>
> >> But I am assured this is not the case! You may NOT use the
> >> word "ALL".[/color]
> >
> > Please cite an example of a standard conforming C compiler
> > that does *not* use all-bits-zero for NULL.[/color]
>
> Any one for the 8086/8 in normal segmented mode. Writing to the
> interrupt vector table is considered poor technique.[/color]

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table? Are you saying that code that
*accidentally* attempts to write through a null pointer will clobber
the interrupt vector table, thus messing up the system rather than
just crashing the offending program? (I'm not familiar with the
systems in question.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Re: C objects

CBFalconer <cbfalconer@yah oo.com> writes:
[color=blue]
> "E. Robert Tisdale" wrote:[color=green]
>> Please cite an example of a standard conforming C compiler
>> that does *not* use all-bits-zero for NULL.[/color]
>
> Any one for the 8086/8 in normal segmented mode. Writing to the
> interrupt vector table is considered poor technique.[/color]

Every MS-DOS compiler I used had null pointers as all-bits-zero.
What did yours use, and which compiler was it?
--
Here's a tip: null pointers don't have to be *dull* pointers!

[RCollins]

Re: C objects



CBFalconer wrote:[color=blue]
> "E. Robert Tisdale" wrote:
>[color=green]
>>Mabden wrote:
>>[color=darkred]
>>>E. Robert Tisdale wrote:
>>>
>>>
>>>>I believe that, currently, *all* viable C compilers
>>>>use all-bits-zero for NULL
>>>>so this is something that you don't need to worry about.
>>>
>>>But I am assured this is not the case! You may NOT use the
>>>word "ALL".[/color]
>>
>>Please cite an example of a standard conforming C compiler
>>that does *not* use all-bits-zero for NULL.[/color]
>
>
> Any one for the 8086/8 in normal segmented mode. Writing to the
> interrupt vector table is considered poor technique.
>
> Now please cease the trolling.
>[/color]

Trolling or not, it's a good question. Just because 0:0 was an
interrupt table, doesn't mean the common C compilers of the day
used a different NULL constant.

So, just off hand, does anyone remember what NULL was defined to
be on any of those compilers: Turbo C, Power C, etc?

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Ben Pfaff]

Re: C objects

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> CBFalconer <cbfalconer@yah oo.com> writes:[color=green]
>> "E. Robert Tisdale" wrote:[color=darkred]
>> > Please cite an example of a standard conforming C compiler
>> > that does *not* use all-bits-zero for NULL.[/color]
>>
>> Any one for the 8086/8 in normal segmented mode. Writing to the
>> interrupt vector table is considered poor technique.[/color]
>
> How would using all-bits-zero for null pointers result in writing to
> the interrupt vector table?[/color]

In real mode on an x86, the interrupt table is at the bottom of
physical memory. Real mode has a 1:1 mapping from virtual to
physical addresses, so writing through a null pointer will indeed
modify the interrupt vector table.
[color=blue]
> Are you saying that code that *accidentally* attempts to write
> through a null pointer will clobber the interrupt vector table,
> thus messing up the system rather than just crashing the
> offending program? (I'm not familiar with the systems in
> question.)[/color]

It's actually worse than that. The first few interrupts in the
table aren't all that important (e.g. the first one is the
"divide by zero" exception vector), so it's possible that writing
to a null pointer won't even mess up the system *quickly*.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[Keith Thompson]

Re: C objects

Ben Pfaff <blp@cs.stanfor d.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:[color=green]
> > CBFalconer <cbfalconer@yah oo.com> writes:[color=darkred]
> >> "E. Robert Tisdale" wrote:
> >> > Please cite an example of a standard conforming C compiler
> >> > that does *not* use all-bits-zero for NULL.
> >>
> >> Any one for the 8086/8 in normal segmented mode. Writing to the
> >> interrupt vector table is considered poor technique.[/color]
> >
> > How would using all-bits-zero for null pointers result in writing to
> > the interrupt vector table?[/color]
>
> In real mode on an x86, the interrupt table is at the bottom of
> physical memory. Real mode has a 1:1 mapping from virtual to
> physical addresses, so writing through a null pointer will indeed
> modify the interrupt vector table.
>[color=green]
> > Are you saying that code that *accidentally* attempts to write
> > through a null pointer will clobber the interrupt vector table,
> > thus messing up the system rather than just crashing the
> > offending program? (I'm not familiar with the systems in
> > question.)[/color]
>
> It's actually worse than that. The first few interrupts in the
> table aren't all that important (e.g. the first one is the
> "divide by zero" exception vector), so it's possible that writing
> to a null pointer won't even mess up the system *quickly*.[/color]

So using a non-all-bits-zero value for the null pointer (on the system
in question) is a mechanism for defending the system against buggy
code. Cool.

(Of course, if somebody uses memset() to set a pointer to
all-bits-zero, assuming that it's a null pointer, and then
accidentally writes through it, it's going to clobber the system
anyway. Presumably anyone who would do such a thing won't be allowed
anywhere near the system.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[RCollins]

Re: C objects



Keith Thompson wrote:[color=blue]
> Ben Pfaff <blp@cs.stanfor d.edu> writes:
>[color=green]
>>Keith Thompson <kst-u@mib.org> writes:
>>[color=darkred]
>>>CBFalconer <cbfalconer@yah oo.com> writes:
>>>
>>>>"E. Robert Tisdale" wrote:
>>>>
>>>>>Please cite an example of a standard conforming C compiler
>>>>>that does *not* use all-bits-zero for NULL.
>>>>
>>>>Any one for the 8086/8 in normal segmented mode. Writing to the
>>>>interrupt vector table is considered poor technique.
>>>
>>>How would using all-bits-zero for null pointers result in writing to
>>>the interrupt vector table?[/color]
>>
>>In real mode on an x86, the interrupt table is at the bottom of
>>physical memory. Real mode has a 1:1 mapping from virtual to
>>physical addresses, so writing through a null pointer will indeed
>>modify the interrupt vector table.
>>
>>[color=darkred]
>>>Are you saying that code that *accidentally* attempts to write
>>>through a null pointer will clobber the interrupt vector table,
>>>thus messing up the system rather than just crashing the
>>>offending program? (I'm not familiar with the systems in
>>>question.)[/color]
>>
>>It's actually worse than that. The first few interrupts in the
>>table aren't all that important (e.g. the first one is the
>>"divide by zero" exception vector), so it's possible that writing
>>to a null pointer won't even mess up the system *quickly*.[/color]
>
>
> So using a non-all-bits-zero value for the null pointer (on the system
> in question) is a mechanism for defending the system against buggy
> code. Cool.
>
> (Of course, if somebody uses memset() to set a pointer to
> all-bits-zero, assuming that it's a null pointer, and then
> accidentally writes through it, it's going to clobber the system
> anyway. Presumably anyone who would do such a thing won't be allowed
> anywhere near the system.)
>[/color]

There are millions of ways to clobber a system ... writing to an
invalid memory address is just one of them.

Who would do such a thing? Well, (need I say it?), none of us are
perfect, I'm sure we've all made our share of bone-headed errors.
(That weekend in Tiajuana ... well, never mind).

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[CBFalconer]

Re: C objects

Keith Thompson wrote:[color=blue]
> CBFalconer <cbfalconer@yah oo.com> writes:[color=green]
>> "E. Robert Tisdale" wrote:
>>[/color][/color]
.... snip ...[color=blue][color=green][color=darkred]
>>>
>>> Please cite an example of a standard conforming C compiler
>>> that does *not* use all-bits-zero for NULL.[/color]
>>
>> Any one for the 8086/8 in normal segmented mode. Writing to the
>> interrupt vector table is considered poor technique.[/color]
>
> How would using all-bits-zero for null pointers result in writing to
> the interrupt vector table? Are you saying that code that
> *accidentally* attempts to write through a null pointer will clobber
> the interrupt vector table, thus messing up the system rather than
> just crashing the offending program? (I'm not familiar with the
> systems in question.)[/color]

The pointers consist of seg:offset, combined as 16*seg+offset =
address in the 0 to 1 meg range. If those are all 0's the result
is absolute address 0, which is where the int 0 interrupt vector
resides. There is no memory protection whatsoever in '86 or '186,
nor, I believe, in the x86 at boot time, when they come up in real
mode.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[CBFalconer]

Re: C objects

Ben Pfaff wrote:[color=blue]
> CBFalconer <cbfalconer@yah oo.com> writes:[color=green]
>> "E. Robert Tisdale" wrote:[/color]
>[color=green][color=darkred]
>>> Please cite an example of a standard conforming C compiler
>>> that does *not* use all-bits-zero for NULL.[/color]
>>
>> Any one for the 8086/8 in normal segmented mode. Writing to the
>> interrupt vector table is considered poor technique.[/color]
>
> Every MS-DOS compiler I used had null pointers as all-bits-zero.
> What did yours use, and which compiler was it?[/color]

I _never_ write through a NULL pointer :-) It might be an
experiment to get Borlands TC from the museum and run it through
some experiments on pure MsDOS. I expect int0 will be affected.
A virtual MsDos on W98 won't do.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dan Pop]

Re: standards documents off-topic in comp.lang.c

In <ln657hvfg4.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:[color=green]
>> In <lnvffi3jth.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[/color]
>[...][color=green][color=darkred]
>> >Most such implementations provide a mode in which they
>> >conform as closely as possible to the standard without extensions,
>> >such as gcc's "-ansi -pedantic -W -Wall" or "-std=c99 -pedantic -W -Wall"
>> >mode.[/color]
>>
>> You're confused/confusing here. First, the -W and -Wall options have
>> absolutely nothing to do with standard conformance: they enable *only*
>> diagnostics that are NOT required by any C standard. gcc has only one
>> standard conforming mode and this is enabled using -ansi -pedantic, or,
>> equivalently, -std=c89 -pedantic (I'm deliberately ignoring the option
>> for C94 conformance, to keep things as simple as possible). -ansi
>> disables gcc's deviations from the standard and -pedantic enables some
>> required diagnostics that gcc doesn't generate by default.[/color]
>
>I had assumed that "-W -Wall" enabled some required diagnostics, but
>if you say "-ansi -pedantic" suffices, I'll take your word for it.[/color]

You don't have to, it's well documented in the gcc man page.
[color=blue]
>(Using "-W -Wall" as well is generally a good idea, but that's not
>necessarily related to conformance.)[/color]

It is -Wall -O that is a good idea. -Wall fails to identify the usage
of uninitialised variables if optimisation is not turned on and -W
generates objectionable warnings (that's why its functionality was
not included into -Wall in the first place).

-W is fine for experienced people who understand the underlying issues
and agree with them. Its diagnostics, however, could be confusing
to newbies and lead them to break perfectly good code, in order to
shut them up.

I wouldn't recommend -W to newbies or to anyone else who doesn't have a
clear understanding of its effects (and those who do, don't need anyone
else's recommendations in order to decide whether to use it or not).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Joe Wright]

Re: C objects

CBFalconer wrote:[color=blue]
> Ben Pfaff wrote:
>[color=green]
>>CBFalconer <cbfalconer@yah oo.com> writes:
>>[color=darkred]
>>>"E. Robert Tisdale" wrote:[/color]
>>[color=darkred]
>>>>Please cite an example of a standard conforming C compiler
>>>>that does *not* use all-bits-zero for NULL.
>>>
>>>Any one for the 8086/8 in normal segmented mode. Writing to the
>>>interrupt vector table is considered poor technique.[/color]
>>
>>Every MS-DOS compiler I used had null pointers as all-bits-zero.
>>What did yours use, and which compiler was it?[/color]
>
>
> I _never_ write through a NULL pointer :-) It might be an
> experiment to get Borlands TC from the museum and run it through
> some experiments on pure MsDOS. I expect int0 will be affected.
> A virtual MsDos on W98 won't do.
>[/color]

I have not snipped anything from Chuck's post. I fear we are
wandering off point if not off topic. In no particular order I offer
various considerations for the null pointer value being zero.

1. It is useful to have functions return an error indication if the
function fails. Consider malloc(). It returns the address of
allocated memory if it succeeds. What shall we have it do if there
is no memory available? Return a value which cannot be a valid address.

2. Given an address, perhaps stored in a pointer, how might we
examine it to determine its validity? Sadly, we can't. C programmers
see pointer values as unsigned integers with no upper bound.

So, if we need a single pointer value within the domains of unsigned
integers of various widths, we are limited to the lower bound, 0.

This is not a bad choice. Usually 0 is an important address to the
underlying OS and we shouldn't write to it in any case. Reserving
address 0 for our NULL pointer constant is perfect. We are warned
that writing or even reading address zero might cause your house to
burn down, and so we don't do it.

Tell me why any C implementation would have a null pointer other
than zero? So that writing through NULL might be safer? Nonsense.
Writing through NULL is the ultimate sin. So why?

--
Joe Wright mailto:joewwrig ht@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Re: C objects

Joe Wright <joewwright@com cast.net> writes:
[...][color=blue]
> Tell me why any C implementation would have a null pointer other than
> zero? So that writing through NULL might be safer? Nonsense. Writing
> through NULL is the ultimate sin. So why?[/color]

In a typical system, there are huge numbers of invalid pointer values;
the null pointer is only of them. But since it's easy to generate a
null pointer in a C program, a given invalid pointer is more likely to
have the value null than any other value. Therefore, a buggy program
that writes through an invalid pointer is more likely to write through
a null pointer than through any other invalid pointer value. If the
system happens to have world-writable critical data at address
all-bits-zero, such that a buggy program can damage the system by
clobbering it, can be made somewhat more secure by using a value other
than all-bits-zero as a null pointer.

Of course, bug-free programs aren't affected by this -- which is fine
if you only run bug-free programs on your system. (The best way to do
that is to pull the power plug.)

If reading or writing through address all-bits-zero is guaranteed to
cause a trap that affects the offending program, then all-bits-zero is
probably an excellent value for the null pointer. But if the
all-bits-zero address doesn't trap (say, because there's real memory
there), and some other address does (say, because it points to memory
that doesn't exist), then the trapping value is probably a better choice.

Many years ago, I worked on a 68K-based system programmed in Pascal
(no C compiler). It used the value 1 for the nil pointer because an
attempt to deference an odd address would cause a trap. (Of course,
Pascal doesn't have all the confusion caused by C's use of a literal 0
to represent a null pointer; it just uses the "nil" keyword.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Re: C objects

Joe Wright wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> So, if we need a single pointer value within the domains of unsigned
> integers of various widths, we are limited to the lower bound, 0.[/color]

not so, see below.[color=blue]
>
> This is not a bad choice. Usually 0 is an important address to the
> underlying OS and we shouldn't write to it in any case. Reserving
> address 0 for our NULL pointer constant is perfect. We are warned
> that writing or even reading address zero might cause your house to
> burn down, and so we don't do it.
>
> Tell me why any C implementation would have a null pointer other
> than zero? So that writing through NULL might be safer? Nonsense.
> Writing through NULL is the ultimate sin. So why?[/color]

I remember one system that used the value 1 for the NULL pointer.
Conceded, it was not a C system, however the same reasons apply.
I forget the details, but it was essential in the architecture.

Using any such value is perfectly possible, it is only necessary
that the system never assign that space to anything, including
statics, automatics, malloced, and even code (which may be needed
for constants and/or immediate addressing instructions).

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!