Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #73265 > unrolled thread

Pointers as error values

Back to article view | Back to comp.lang.c

Contents

  Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-19 00:53 -0700
    Re: Pointers as error values gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-19 08:26 +0000
      Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-19 02:27 -0700
      Re: Pointers as error values Richard Damon <Richard@Damon-Family.org> - 2015-10-19 23:38 -0400
    Re: Pointers as error values jacobnavia <jacob@jacob.remcomp.fr> - 2015-10-19 10:34 +0200
      Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-19 02:29 -0700
      Re: Pointers as error values mark.bluemel@gmail.com - 2015-10-19 05:53 -0700
    Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 10:00 +0000
    Re: Pointers as error values Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 14:00 +0000
    Re: Pointers as error values gwowen <gwowen@gmail.com> - 2015-10-19 08:02 -0700
      Re: Pointers as error values James Kuyper <jameskuyper@verizon.net> - 2015-10-19 11:53 -0400
    Re: Pointers as error values Ken Brody <kenbrody@spamcop.net> - 2015-10-19 11:25 -0400
    Re: Pointers as error values supercat@casperkitty.com - 2015-10-19 08:41 -0700
    Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-19 08:59 -0700
      Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-21 07:32 +0200
        Re: Pointers as error values Ian Collins <ian-news@hotmail.com> - 2015-10-21 19:17 +1300
          Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-21 08:31 +0200
        Re: Pointers as error values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 12:46 +0100
        Re: Pointers as error values Robert Wessel <robertwessel2@yahoo.com> - 2015-10-21 09:35 -0500
          Re: Pointers as error values Ken Brody <kenbrody@spamcop.net> - 2015-10-21 15:24 -0400
            Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:44 +0000
        Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-21 10:41 -0700
          Re: Pointers as error values supercat@casperkitty.com - 2015-10-21 11:28 -0700
        Re: Pointers as error values John Temples <usenet@xargs-spam.com> - 2015-10-21 17:45 +0000
          Re: Pointers as error values James Kuyper <jameskuyper@verizon.net> - 2015-10-21 14:15 -0400
            Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-29 16:59 +0100
              Re: Pointers as error values supercat@casperkitty.com - 2015-10-29 12:35 -0700
                Re: Pointers as error values raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:45 +0000
                  Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-30 06:09 +0100
                    Re: Pointers as error values Rosario19 <Ros@invalid.invalid> - 2015-10-30 08:59 +0100
                      Re: Pointers as error values Rosario19 <Ros@invalid.invalid> - 2015-10-30 09:07 +0100
                      Re: Pointers as error values Rosario19 <Ros@invalid.invalid> - 2015-10-30 09:38 +0100
                        Re: Pointers as error values Rosario19 <Ros@invalid.invalid> - 2015-10-30 09:40 +0100
                    Re: Pointers as error values Robert Wessel <robertwessel2@yahoo.com> - 2015-10-30 04:56 -0500
                    Re: Pointers as error values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 11:00 +0000
              Re: Pointers as error values Robert Wessel <robertwessel2@yahoo.com> - 2015-10-29 23:48 -0500
                Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-30 11:05 +0100
                  Re: Pointers as error values Richard Damon <Richard@Damon-Family.org> - 2015-10-30 07:45 -0400
                    Re: Pointers as error values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-30 05:04 -0700
                      Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-30 16:09 +0100
                        Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-30 11:16 -0700
                          Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-30 20:58 +0000
                            Re: Pointers as error values Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-30 17:12 -0400
                            Re: Pointers as error values supercat@casperkitty.com - 2015-10-30 14:54 -0700
                            Re: Pointers as error values Robert Wessel <robertwessel2@yahoo.com> - 2015-10-30 18:48 -0500
                              Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-01 04:00 +0000
                                Re: Pointers as error values Robert Wessel <robertwessel2@yahoo.com> - 2015-11-01 01:24 -0500
                          Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-31 20:35 +0100
                            Re: Pointers as error values supercat@casperkitty.com - 2015-10-31 13:33 -0700
                        Re: Pointers as error values Richard Damon <Richard@Damon-Family.org> - 2015-10-30 22:19 -0400
                    Re: Pointers as error values supercat@casperkitty.com - 2015-10-30 08:22 -0700
                  Re: Pointers as error values Geoff <geoff@invalid.invalid> - 2015-10-30 13:11 -0700
                    Re: Pointers as error values Geoff <geoff@invalid.invalid> - 2015-10-30 13:23 -0700
        Re: Pointers as error values Geoff <geoff@invalid.invalid> - 2015-10-21 11:13 -0700
          Re: Pointers as error values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 20:31 +0100
            Re: Pointers as error values Geoff <geoff@invalid.invalid> - 2015-10-22 07:13 -0700
          Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-26 07:16 +0100
            Re: Pointers as error values Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-26 09:37 +0000
        Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:38 +0000
          Re: Pointers as error values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-22 13:51 +0100
          Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-22 08:29 -0700
            Re: Pointers as error values supercat@casperkitty.com - 2015-10-22 09:21 -0700
              Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-22 10:52 -0700
                Re: Pointers as error values "Morten W. Petersen" <morphex@gmail.com> - 2015-10-26 07:20 +0100
                  Re: Pointers as error values Keith Thompson <kst-u@mib.org> - 2015-10-26 08:09 -0700
                    Re: Pointers as error values supercat@casperkitty.com - 2015-10-26 08:40 -0700
                    Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:02 +0000
                      Re: Pointers as error values supercat@casperkitty.com - 2015-10-26 13:56 -0700
            Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 21:58 +0000
              Re: Pointers as error values James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:12 -0400
              Re: Pointers as error values asetofsymbols@gmail.com - 2015-10-22 18:36 -0700
                Re: Pointers as error values asetofsymbols@gmail.com - 2015-10-29 12:47 -0700
    Re: Pointers as error values Lőrinczy Zsigmond <nospam@for.me> - 2015-10-20 17:06 +0200
      Re: Pointers as error values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-20 19:45 +0100
        Re: Pointers as error values supercat@casperkitty.com - 2015-10-20 14:19 -0700
          Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:28 +0000
            Re: Pointers as error values supercat@casperkitty.com - 2015-10-21 05:48 -0700
              Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:52 +0000
            Re: Pointers as error values Ken Brody <kenbrody@spamcop.net> - 2015-10-21 15:19 -0400
              Re: Pointers as error values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 06:06 +0000

Page 4 of 4 — ← Prev page 1 2 3 [4]

#73561

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Morten W. Petersen <morphex@gmail.com> wrote:
>> On 19.10.2015 17:59, Keith Thompson wrote:
>
> (snip)
>
>>> Not 100% portably.  A small non-zero integer converted to a pointer
>>> type is unlikely to match a valid pointer value, but there's no
>>> guarantee.  Even accessing an invalid pointer (without dereferencing
>>> it) can have undefined behavior.
>  
>> Hmm, OK.  That dereferencing wouldn't work was expected, but why would
>> working with an address value not work?
>  
>> What is a real-life example where using 1-7 as pointer return values
>> would not work?
>
> C guarantees that no valid pointer will have the value equal to a null
> pointer.

Emphasis: no *valid* pointer.

> On small systems, or larger systems in small memory model, C has to
> guarantee that no pointer is NULL, so won't ever use the otherwise
> valid pointer (void*)0.  C doesn't guarantee that no pointer is
> equal to (void*)1. 

C doesn't guarantee that `(void*)0 != (void*)1`.  An implementation
could plausibly use a representation equivalent to 0x1 for null
pointers.  (void*)1 could reinterpret the representation of the
operand 1, yielding a null pointer; (void*)0 yields a null pointer
by definition.

> Also, as previously noted, using <, <=, >, >=, might give surprising
> results.

Not just surprising results; the behavior is undefined unless both
operands point into or just past the same object.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#73563

On Thursday, October 22, 2015 at 10:29:57 AM UTC-5, Keith Thompson wrote:
> C doesn't guarantee that `(void*)0 != (void*)1`.  An implementation
> could plausibly use a representation equivalent to 0x1 for null
> pointers.  (void*)1 could reinterpret the representation of the
> operand 1, yielding a null pointer; (void*)0 yields a null pointer
> by definition.

Does C guarantee that if "intptr_t" exists, that (intptr_t_)(void*)0 == 0 and
that given intptr_t x=0, (void*)x == 0?  I recall having read that casts or
comparisons to a constant literal zero are special, and that even when a
platform defines conversions between pointers and numbers they need not be
consistent with that.

That having been said, I do think it would be helpful if C were to define
a macro to indicate whether all-bits-zero was a valid representation for
a null pointer, and if equal pointer are guaranteed to have equivalent
bitwise representations; the former would allow code to "calloc" an array
of pointers without having to expressly set each pointer in the array to
null, and the latter would allow "memcmp" to efficiently compare large
groups of pointers against each other.  While I fully understand that
there exist implementations where such guarantees wouldn't hold, programs
that aren't expecting to run on such platforms shouldn't have to generate
code to deal with them unless or until a need emerges to use such programs
on those platforms.

[toc] | [prev] | [next] | [standalone]

#73565

supercat@casperkitty.com writes:
> On Thursday, October 22, 2015 at 10:29:57 AM UTC-5, Keith Thompson wrote:
>> C doesn't guarantee that `(void*)0 != (void*)1`.  An implementation
>> could plausibly use a representation equivalent to 0x1 for null
>> pointers.  (void*)1 could reinterpret the representation of the
>> operand 1, yielding a null pointer; (void*)0 yields a null pointer
>> by definition.
>
> Does C guarantee that if "intptr_t" exists, that (intptr_t_)(void*)0 == 0 and
> that given intptr_t x=0, (void*)x == 0?

No.  It only guarantees that (N1570 7.20.1.4p1)

    any valid pointer to void can be converted to this type, then
    converted back to pointer to void, and the result will compare
    equal to the original pointer

where "this type" is either intptr_t or uintptr_t.

You do yave a copy of N1570, don't you?  This would have been easy to
look up.

>                                          I recall having read that casts or
> comparisons to a constant literal zero are special, and that even when a
> platform defines conversions between pointers and numbers they need not be
> consistent with that.

N1570 6.3.2.3p3:

    An integer constant expression with the value 0, or such
    an expression cast to type void *, is called a null pointer
    constant. If a null pointer constant is converted to a pointer
    type, the resulting pointer, called a null pointer, is guaranteed
    to compare unequal to a pointer to any object or function.

Integer-to-pointer conversions are otherwise implementation-defined
(same section, paragraph 5).

Which means that given:

    int zero = 0;
    void *p0 = (void*)0;
    void *p1 = (void*)zero;

the value of p0 is guaranteed to be a null pointer, but it's not
guaranteed that p0 == p1.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#73824

On 22.10.2015 19:52, Keith Thompson wrote:
> supercat@casperkitty.com writes:
[...]
>>                                           I recall having read that casts or
>> comparisons to a constant literal zero are special, and that even when a
>> platform defines conversions between pointers and numbers they need not be
>> consistent with that.
>
> N1570 6.3.2.3p3:
>
>      An integer constant expression with the value 0, or such
>      an expression cast to type void *, is called a null pointer
>      constant. If a null pointer constant is converted to a pointer
>      type, the resulting pointer, called a null pointer, is guaranteed
>      to compare unequal to a pointer to any object or function.
>
> Integer-to-pointer conversions are otherwise implementation-defined
> (same section, paragraph 5).
>
> Which means that given:
>
>      int zero = 0;
>      void *p0 = (void*)0;
>      void *p1 = (void*)zero;
>
> the value of p0 is guaranteed to be a null pointer, but it's not
> guaranteed that p0 == p1.

This can be tested, that the different pointers and pointer < 8 works;
the only thing I don't see a way to test, is whether it is possible that
a pointer that is <8 could point to a valid address.

-Morten

[toc] | [prev] | [next] | [standalone]

#73861

"Morten W. Petersen" <morphex@gmail.com> writes:
> On 22.10.2015 19:52, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
> [...]
>>>                                           I recall having read that
>>> casts or comparisons to a constant literal zero are special, and
>>> that even when a platform defines conversions between pointers and
>>> numbers they need not be consistent with that.
>>
>> N1570 6.3.2.3p3:
>>
>>      An integer constant expression with the value 0, or such
>>      an expression cast to type void *, is called a null pointer
>>      constant. If a null pointer constant is converted to a pointer
>>      type, the resulting pointer, called a null pointer, is guaranteed
>>      to compare unequal to a pointer to any object or function.
>>
>> Integer-to-pointer conversions are otherwise implementation-defined
>> (same section, paragraph 5).
>>
>> Which means that given:
>>
>>      int zero = 0;
>>      void *p0 = (void*)0;
>>      void *p1 = (void*)zero;
>>
>> the value of p0 is guaranteed to be a null pointer, but it's not
>> guaranteed that p0 == p1.
>
> This can be tested, that the different pointers and pointer < 8 works;
> the only thing I don't see a way to test, is whether it is possible that
> a pointer that is <8 could point to a valid address.

It can't be tested *reliably*.  Even if (ptr != (void*)7) works reliably
when you test it on your system, that's no guarantee that it will work
when your code is recompiled for some other system, or even when it's
run on a differently configured system without recompilation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#73863

On Monday, October 26, 2015 at 10:09:14 AM UTC-5, Keith Thompson wrote:
> It can't be tested *reliably*.  Even if (ptr != (void*)7) works reliably
> when you test it on your system, that's no guarantee that it will work
> when your code is recompiled for some other system, or even when it's
> run on a differently configured system without recompilation.

Further, while it used to be that someone who understood C in general and
understood a machine architecture could pretty well predict how compilers
for that architecture would behave in cases where the Standard imposed no
requirements (and this also meant different compilers would be relatively
compatible when producing code for the same architecture) that has become
much less true over the last ten years.

Since the Standard doesn't recognize any distinction between a compiler
and the underlying CPU architecture, nothing in it implies that guarantees
which would be inherent in an architecture should be exposed to the
programmer.  Even if there would be a clear and obvious translation from
the code "if (ptr != (void*)7) foo();" to

    cmp  r4,#7  ; Assume ptr was optimized to register 4
    beq  skipTrueBranch
    bl   foo
skipTrueBranch:

there's nothing in the Standard which would prevent a compiler from saying
that since "ptr" is of a type which requires four-byte alignment and 7 is
not a multiple of four, therefore 7 cannot yield a valid pointer value and
may be regarded as a trap representation.  Since the Standard imposes no
requirements about what must happen when code tries to do anything with a
trap representation, nothing would forbid a compiler from simply omitting
not just the comparison and the controlled block, but also all code which
followed it (after the controlled block), and any code leading up to it
which would inevitably result in the comparison against 7.  Since the code
serves no purpose (from the point of view of the Standard) the program will
be more "efficient" without it.

Unless one is familiar with all the inner details of every compiler to which
code might be ported, it will no longer be safe to use such constructs unless
or until the Standard defines some means of distinguishing between compilers
which promise to uphold various guarantees with regard to certain behaviors
and those which do not.

[toc] | [prev] | [next] | [standalone]

#73906

Keith Thompson <kst-u@mib.org> wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:

(snip on using pointers as flags)

>> This can be tested, that the different pointers and pointer < 8 works;
>> the only thing I don't see a way to test, is whether it is possible that
>> a pointer that is <8 could point to a valid address.
 
> It can't be tested *reliably*.  Even if (ptr != (void*)7) works reliably
> when you test it on your system, that's no guarantee that it will work
> when your code is recompiled for some other system, or even when it's
> run on a differently configured system without recompilation.

If you know details about the system, you can often figure it out.

That doesn't help if you want to port to a different system.

For small model 8086, with a 16 bit address space, to make the most
use of the space, the system tries to make the most use of the
space available. It is relatively likely that (void*)7 could be
an actual pointer, though (void*)4 and (void*)8 might be more likely.

For large model protected mode 80286, and assuming that you use all 32
bits of the pointer, you are safe if you test for equality.
The whole segment selector 0 is reserved as the null segment by 
the hardware.  You are not safe with tests like <, as only the
offset is (usually) compared. 

Many current systems reserve half of the address space for the OS,
and if that is the part with (void*)7, and you are not addressing
OS space, you should be safe. (I don't know which ones use the low,
and which the high addresses, for OS space.)

Seems that the most reliable method is with a global char array.
But even in that case, you can't rely on < and > tests. You need
to test for equality for each element.

Seems to me that you do a little better if you cast to (intptr_t)
first. That should allow you to do < and > tests on the whole pointer
instead of just the offset.  If you cast a pointer to an element
of a global array to (intptr_t) it seems likely, though maybe not
certain, that all elements would be >= the lowest element and >=
the highest element.

But maybe not all systems can cast to (intptr_t).

-- glen

[toc] | [prev] | [next] | [standalone]

#73911

On Monday, October 26, 2015 at 3:02:18 PM UTC-5, glen herrmannsfeldt wrote:
> If you know details about the system, you can often figure it out.

Compiler writers used to pretty consistently abide by the philosophy that in
cases where a particular hardware platform would behave a certain way in
circumstances where the Standard would impose no requirements, compilers
should avoid behaving in ways that those familiar with the platform would
regard as "astonishing".

Unfortunately, a new hyper-modern philosophy seems to be taking hold, which
is that compilers should feel free to do anything they like in cases where
the Standards impose no requirements, even if the underlying platform has
a clear and natural behavior.

Unless one knows that one's code will never be be used with a hyper-modern
compiler, knowing the details of the target system won't be sufficient; one
will have to know which details of the target system the compiler is willing
to expose.

[toc] | [prev] | [next] | [standalone]

#73573

Keith Thompson <kst-u@mib.org> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Morten W. Petersen <morphex@gmail.com> wrote:

(snip)

>>>> guarantee.  Even accessing an invalid pointer (without dereferencing
>>>> it) can have undefined behavior.
  
>>> Hmm, OK.  That dereferencing wouldn't work was expected, but why would
>>> working with an address value not work?
  
>>> What is a real-life example where using 1-7 as pointer return values
>>> would not work?

>> C guarantees that no valid pointer will have the value equal to a null
>> pointer.
 
> Emphasis: no *valid* pointer.

Some time I should learn how to add emphasis.
 
>> On small systems, or larger systems in small memory model, C has to
>> guarantee that no pointer is NULL, so won't ever use the otherwise
>> valid pointer (void*)0.  C doesn't guarantee that no pointer is
>> equal to (void*)1. 

More specifically, "x"==(char*)1  might be true.
 
> C doesn't guarantee that `(void*)0 != (void*)1`.  An implementation
> could plausibly use a representation equivalent to 0x1 for null
> pointers.  (void*)1 could reinterpret the representation of the
> operand 1, yielding a null pointer; (void*)0 yields a null pointer
> by definition.

For protected mode x86, x>=2, null pointers have segement selector 0,
and offset zero. Since valid pointers can't have selector 0, one
could test just the selector for a null pointer. I don't remember
compilers doing that, but I don't see why not.

Compilers that I remember could generate code for either protected
mode or real mode, mostly without knowing which one. Since the
segment part could be zero in real mode, they should test both.
 
>> Also, as previously noted, using <, <=, >, >=, might give surprising
>> results.
 
> Not just surprising results; the behavior is undefined unless both
> operands point into or just past the same object.

They might just return 0 or 1 in ways that are not consistent.

Or they could do any of those things noted in the past for undefined
behavior. 


-- glen

[toc] | [prev] | [next] | [standalone]

#73576

On 10/22/2015 05:58 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
...
>> Not just surprising results; the behavior is undefined unless both
>> operands point into or just past the same object.
> 
> They might just return 0 or 1 in ways that are not consistent.
> 
> Or they could do any of those things noted in the past for undefined
> behavior.

They could also do any thing that has never been noted in the past for
undefined behavior.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#73581

the 'impossible pointers'

it would be -1 or
0xFFFFFFFF for 32 bit
because it has not a next
address

and 0 because it has not a 
preceding address

[toc] | [prev] | [next] | [standalone]

#74198

But if are too many error values
why not instead of
T* this(args)
This function:
i32  isteadThis(&pointerResult, args)

Where one call that in this way
T  *pointerResult;
i32      r;
r=isteadThis(&pointerResult, args)
if(r== 0) ok
if(r==-1) error
if(r==-2) error2
  ....
I am not think good in use
1,2,3 as address error
but for me is ok using only
-1 as address error
I make errors, I'm not strong logic
disclaimer 

[toc] | [prev] | [next] | [standalone]

#73408

On 2015.10.19. 9:53, Morten W. Petersen wrote:
> Hi.
>
> I was thinking the other day, that NULL pointers indicate an error.  That got me
> wondering, is it possible to use a low number range as valid error indicators?

SIG_IGN comes in my mind: it is tipically (somefunpointer)1

[toc] | [prev] | [next] | [standalone]

#73431

Lőrinczy Zsigmond <nospam@for.me> writes:

> On 2015.10.19. 9:53, Morten W. Petersen wrote:
>>
>> I was thinking the other day, that NULL pointers indicate an error.
>> That got me wondering, is it possible to use a low number range as
>> valid error indicators?
>
> SIG_IGN comes in my mind: it is tipically (somefunpointer)1

Often it is, yes, but I Morten is, I think, concerned about maximum
portability, and what a particular implementation might do is not a good
guide for what portable software should do.

If you were implementing something like the signal interface in a
portable library, your simplest option is to return something of the
right type.  Thus you might define actual functions call __sig_ign_f__
and __sig_dfl_f__ so that you can

  #define SIG_IGN __sig_ign_f__

An equivalent idea has already been suggested I think; namely to define
specific, static, objects of the right XML structure types so that
pointers to them can be returned to indicate some errors.

The trouble (also covered I think) is that if you use several there is
no simple way to test if a pointer is one of them other than to test all
of the for equality.  If you use the (xml_element *)3 hack, you can (on
many systems) test for the return value being in the error range.

But if the object type is a union, you can define a new type for an
error object, and create a few of these for the specific errors that you
want to signal.  Your functions never now return NULL and the test for
an error becomes

  if (ptr->type == XmlError) ...

though there is nothing to prevent you (where it makes sense) from
making a pointer comparison with one of these objects

  if (ptr != &Xml_Out_Of_Mem_Error) ...

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#73432

On Tuesday, October 20, 2015 at 1:46:14 PM UTC-5, Ben Bacarisse wrote:
> The trouble (also covered I think) is that if you use several there is
> no simple way to test if a pointer is one of them other than to test all
> of the for equality.  If you use the (xml_element *)3 hack, you can (on
> many systems) test for the return value being in the error range.

On systems which define a global ranking among all pointers (which happens by
default on linear-address systems, and can often be implemented easily on
segmented-address systems) one need not rely upon any particular details of
integer-to-pointer conversion if one does something like:

#define NUM_ERRORS 23
const char ERRORS[NUM_ERRORS];

    if ((char*)retval >= ERRORS && (char*)retval < ERRORS+sizeof ERRORS)
    {
       int error_code = (char*)retval-errors;
    }

Unfortunately, the C Standard does not presently define any means by which
an program can inquire whether an implementation supports a global ranking
among all pointers.

[toc] | [prev] | [next] | [standalone]

#73448

supercat@casperkitty.com wrote:
> On Tuesday, October 20, 2015 at 1:46:14 PM UTC-5, Ben Bacarisse wrote:
>> The trouble (also covered I think) is that if you use several there is
>> no simple way to test if a pointer is one of them other than to test all
>> of the for equality.  If you use the (xml_element *)3 hack, you can (on
>> many systems) test for the return value being in the error range.
 
> On systems which define a global ranking among all pointers 
> (which happens by default on linear-address systems, and can 
> often be implemented easily on segmented-address systems) 

I suspect that segmented address systems only compare the offset
when <, <=, >, >=, are used, but never actually looked.

Note that for IA32, (and the 80286 before it) segment selector
zero is special to the hardware, as the null selector. 

> one need not rely upon any particular details of 
> integer-to-pointer conversion if one does something like:

> #define NUM_ERRORS 23
> const char ERRORS[NUM_ERRORS];
 
>    if ((char*)retval >= ERRORS && (char*)retval < ERRORS+sizeof ERRORS)
>    {
>       int error_code = (char*)retval-errors;
>    }
 
> Unfortunately, the C Standard does not presently define any means by which
> an program can inquire whether an implementation supports a global ranking
> among all pointers.

But it always works for equality tests. 

-- glen

[toc] | [prev] | [next] | [standalone]

#73479

On Wednesday, October 21, 2015 at 12:28:24 AM UTC-5, glen herrmannsfeldt wrote:
> supercat wrote:
> > On systems which define a global ranking among all pointers 
> > (which happens by default on linear-address systems, and can 
> > often be implemented easily on segmented-address systems) 
> 
> I suspect that segmented address systems only compare the offset
> when <, <=, >, >=, are used, but never actually looked.

Some segmented-system compilers offer an option to either compare only the
offset portion, or to compare the entire thing.  Comparing only the offset
portion is faster, and will suffice to make pointers yield a ranking, though
not a unique ranking much less a non-overlapping one.  Comparing the whole
pointer value (with priority given to the segment) will make the pointers
yield a non-overlapping unique ranking.

There may be hardware platforms where it would be difficult for a compiler
to offer a unique non-overlapping ranking, but I don't know of any in
particular.

[toc] | [prev] | [next] | [standalone]

#73534

supercat@casperkitty.com wrote:

(snip, I wrote)
>> I suspect that segmented address systems only compare the offset
>> when <, <=, >, >=, are used, but never actually looked.
 
> Some segmented-system compilers offer an option to either compare only the
> offset portion, or to compare the entire thing.  Comparing only the offset
> portion is faster, and will suffice to make pointers yield a ranking, though
> not a unique ranking much less a non-overlapping one.  Comparing the whole
> pointer value (with priority given to the segment) will make the pointers
> yield a non-overlapping unique ranking.
 
> There may be hardware platforms where it would be difficult for a compiler
> to offer a unique non-overlapping ranking, but I don't know of any in
> particular.

JVM.

For JVM, you can compare object references for equality or inequality,
but no other operations.

An implementation of C pointers might have an array object reference
and offset. Pointer arithmetic would only work on the offset.

I suppose one could add an additional field that would be a unique
value for each pointer, just for comparison. But C doesn't
require that.

-- glen

[toc] | [prev] | [next] | [standalone]

#73511

On 10/21/2015 1:28 AM, glen herrmannsfeldt wrote:
> supercat@casperkitty.com wrote:
>> On Tuesday, October 20, 2015 at 1:46:14 PM UTC-5, Ben Bacarisse wrote:
>>> The trouble (also covered I think) is that if you use several there is
>>> no simple way to test if a pointer is one of them other than to test all
>>> of the for equality.  If you use the (xml_element *)3 hack, you can (on
>>> many systems) test for the return value being in the error range.
>
>> On systems which define a global ranking among all pointers
>> (which happens by default on linear-address systems, and can
>> often be implemented easily on segmented-address systems)
>
> I suspect that segmented address systems only compare the offset
> when <, <=, >, >=, are used, but never actually looked.

I have, and they do.

(Unless you're dealing with "huge" pointers, rather than just "far" 
pointers.  Note, too, that "near" pointers do not include a segment/selector 
in the first place.)

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#73535

Ken Brody <kenbrody@spamcop.net> wrote:
>> supercat@casperkitty.com wrote:

(snip)
>>> On systems which define a global ranking among all pointers
>>> (which happens by default on linear-address systems, and can
>>> often be implemented easily on segmented-address systems)

(snip, then I wrote)
>> I suspect that segmented address systems only compare the offset
>> when <, <=, >, >=, are used, but never actually looked.
 
> I have, and they do.
 
> (Unless you're dealing with "huge" pointers, rather than just "far" 
> pointers.  Note, too, that "near" pointers do not include a segment/selector 
> in the first place.)

I used to do a lot of large model 80286 programming with OS/2, but never
needed huge.

One program I worked on had large 2D arrays, which were allocated, as
usual, as arrays of pointers.  64K per row was always enough.

I had 7MB on an 80286 system in 1990, which was large at the time.

An 8192 by 8192 matrix of double would be 512MB, probably larger than
the virtual memory (even the disk) on my system.

Not so much later, I had a 486 machine with 16MB, still running OS/2 1.x.

On that system, I would use the OS/2 segment allocator, put an offset
of zero, and use that as a far pointer. The segment was allocated to the
exact lengths, such that a hardware exception was generated reading or
writing outside an array.

If processors had a segment desriptor cache, such operations might have
been fast enough, but they didn't, and don't.

-- glen

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web