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

Groups > comp.std.c > #1745 > unrolled thread

null pointer constant, address constant

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

Contents

  null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2012-12-18 13:25 +0000
    Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-18 09:53 -0500
      Re: null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2012-12-18 20:06 +0000
        Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-18 15:39 -0500
          Re: null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2012-12-19 00:44 +0000
            Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-18 20:24 -0500
              Re: null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2012-12-19 10:27 +0000
                Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-19 07:15 -0500
                Re: null pointer constant, address constant Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-21 03:03 +0200
                  Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-21 12:13 -0500
                  Re: null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2013-01-09 00:44 +0000
                    Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2013-01-08 20:21 -0500
                      Re: null pointer constant, address constant Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-08 20:46 -0500
            Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 20:37 -0500
        Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 16:15 -0500
          Re: null pointer constant, address constant Keith Thompson <kst-u@mib.org> - 2012-12-18 15:52 -0800
            Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 19:12 -0500
              Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 19:51 -0500
            Re: null pointer constant, address constant Keith Thompson <kst-u@mib.org> - 2012-12-18 17:02 -0800
            Re: null pointer constant, address constant "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-12-20 05:34 -0800
              Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-20 10:33 -0500
                Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-20 12:28 -0500
                  Re: null pointer constant, address constant Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 21:13 -0800
                Re: null pointer constant, address constant Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 21:05 -0800
              Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-20 12:17 -0500
              Re: null pointer constant, address constant Keith Thompson <kst-u@mib.org> - 2012-12-20 12:10 -0800
                Re: null pointer constant, address constant Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 21:25 -0800
    Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 14:02 -0500
      Re: null pointer constant, address constant Szabolcs Nagy <nsz@port70.net> - 2012-12-18 20:09 +0000
        Re: null pointer constant, address constant James Kuyper <jameskuyper@verizon.net> - 2012-12-18 15:54 -0500
          Re: null pointer constant, address constant Shao Miller <sha0.miller@gmail.com> - 2012-12-18 16:18 -0500

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

#1768

On 12/20/2012 08:34 AM, christian.bau wrote:
> On Dec 18, 11:52�pm, Keith Thompson <ks...@mib.org> wrote:
> 
>> The standard says that a constant arithmetic expression with the value
>> 0, converted to a pointer type, yields a null pointer. �It does *not*
>> say the same thing about a non-constant arithmetic expression with the
>> value 0.
> 
> It doesn't have to. The standard doesn't have to state something
> explicitly if it follows from other rules that are stated.
> 
> Converting _any_ integer to _any_ pointer gives an implementation-
> defined result.

Not so. "An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined, ..."
6.3.2.3p5. Since null pointer constants are described in 6.3.2.3p4, they
are covered by "Except as previously specified". Conversion of
non-constant arithmetic expressions with a value of 0 is NOT covered by
that exception. This means that the implementation-defined result of
such a conversion need not match the standard-defined result for null
pointer constants.
-- 
James Kuyper

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

#1770

On 12/20/2012 10:33 AM, James Kuyper wrote:
> On 12/20/2012 08:34 AM, christian.bau wrote:
>> On Dec 18, 11:52�pm, Keith Thompson <ks...@mib.org> wrote:
>>
>>> The standard says that a constant arithmetic expression with the value
>>> 0, converted to a pointer type, yields a null pointer. �It does *not*
>>> say the same thing about a non-constant arithmetic expression with the
>>> value 0.
>>
>> It doesn't have to. The standard doesn't have to state something
>> explicitly if it follows from other rules that are stated.
>>
>> Converting _any_ integer to _any_ pointer gives an implementation-
>> defined result.
> 
> Not so. "An integer may be converted to any pointer type. Except as
> previously specified, the result is implementation-defined, ..."
> 6.3.2.3p5. Since null pointer constants are described in 6.3.2.3p4, they
> are covered by "Except as previously specified". Conversion of
> non-constant arithmetic expressions with a value of 0 is NOT covered by
> that exception. This means that the implementation-defined result of
> such a conversion need not match the standard-defined result for null
> pointer constants.

After thinking about it a little while, I realized I hadn't worded that
quite right, and that my citation was incorrect. Here's a corrected version:

Since null pointers are described in 6.3.2.3p3, they are covered by
"Except as previously specified". Conversions of integer expressions
with a value of 0 to pointer types which are not covered by 6.3.2.3p3
are therefore not covered by that exception, and need not be defined by
the implementation to produce the same result.

I think that you're assuming that there's some kind of consistency
requirement imposed by the standard on the implementation's definition
of the result. For instance, that it is determined solely by the
integer's value and the type of the pointer. The standard imposes no
such requirement. The result could depend upon the type of the integer.
It could depend upon the kind of expression used to produce that
integer. It could depend upon the phase of the moon, and whether or not
today is Friday the 13th. It could be completely random. I can't come up
with a good reason for any of those things to be true, but it would not
render the implementation non-conforming if they were.

If there were such a consistency requirement, it would depend upon the
precise wording of that requirement whether or not it requires
consistency between the result, when it's implementation-defined, and
the result when the implementation has no obligation to provide a
definition, because it's standard-defined (by 6.3.2.3p3). However, that
issue doesn't come up, because there is no such consistency requirement.

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

#1776

James Kuyper <jameskuyper@verizon.net> writes:

> On 12/20/2012 10:33 AM, James Kuyper wrote:
>> On 12/20/2012 08:34 AM, christian.bau wrote:
>>> On Dec 18, 11:52 pm, Keith Thompson <ks...@mib.org> wrote:
>>>
>>>> The standard says that a constant arithmetic expression with the value
>>>> 0, converted to a pointer type, yields a null pointer.  It does *not*
>>>> say the same thing about a non-constant arithmetic expression with the
>>>> value 0.
>>>
>>> It doesn't have to. The standard doesn't have to state something
>>> explicitly if it follows from other rules that are stated.
>>>
>>> Converting _any_ integer to _any_ pointer gives an implementation-
>>> defined result.
>> 
>> Not so. "An integer may be converted to any pointer type. Except as
>> previously specified, the result is implementation-defined, ..."
>> 6.3.2.3p5. Since null pointer constants are described in 6.3.2.3p4, they
>> are covered by "Except as previously specified". Conversion of
>> non-constant arithmetic expressions with a value of 0 is NOT covered by
>> that exception. This means that the implementation-defined result of
>> such a conversion need not match the standard-defined result for null
>> pointer constants.
>
> After thinking about it a little while, I realized I hadn't worded
> that quite right, and that my citation was incorrect.  Here's a
> corrected version:
>
> Since null pointers are described in 6.3.2.3p3, they are covered by
> "Except as previously specified".  Conversions of integer
> expressions with a value of 0 to pointer types which are not covered
> by 6.3.2.3p3 are therefore not covered by that exception, and need
> not be defined by the implementation to produce the same result.
>
> I think that you're assuming that there's some kind of consistency
> requirement imposed by the standard on the implementation's
> definition of the result.  For instance, that it is determined
> solely by the integer's value and the type of the pointer.  The
> standard imposes no such requirement.  The result could depend upon
> the type of the integer.  It could depend upon the kind of
> expression used to produce that integer.  It could depend upon the
> phase of the moon, and whether or not today is Friday the 13th.  It
> could be completely random.  I can't come up with a good reason for
> any of those things to be true, but it would not render the
> implementation non-conforming if they were.
>
> If there were such a consistency requirement, it would depend upon
> the precise wording of that requirement whether or not it requires
> consistency between the result, when it's implementation-defined,
> and the result when the implementation has no obligation to provide
> a definition, because it's standard-defined (by 6.3.2.3p3).
> However, that issue doesn't come up, because there is no such
> consistency requirement.

Longer, but still begging the same question.  The text of the
Standard does not produce this conclusion clearly enough.  At
the very least a clarifying footnote is needed.

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

#1775

James Kuyper <jameskuyper@verizon.net> writes:

> On 12/20/2012 08:34 AM, christian.bau wrote:
>> On Dec 18, 11:52 pm, Keith Thompson <ks...@mib.org> wrote:
>> 
>>> The standard says that a constant arithmetic expression with the value
>>> 0, converted to a pointer type, yields a null pointer.  It does *not*
>>> say the same thing about a non-constant arithmetic expression with the
>>> value 0.
>> 
>> It doesn't have to. The standard doesn't have to state something
>> explicitly if it follows from other rules that are stated.
>> 
>> Converting _any_ integer to _any_ pointer gives an implementation-
>> defined result.
>
> Not so.  "An integer may be converted to any pointer type.  Except
> as previously specified, the result is implementation-defined, ..."
> 6.3.2.3p5.  Since null pointer constants are described in 6.3.2.3p4,
> they are covered by "Except as previously specified".  Conversion of
> non-constant arithmetic expressions with a value of 0 is NOT covered
> by that exception.  This means that the implementation-defined
> result of such a conversion need not match the standard-defined
> result for null pointer constants.

IMO this is begging the question.  The point of Christian's
comments is to argue that what happens when converting an integer
value of zero must be consistent in the case of a null pointer
constant (which also has an integer value of zero).  Reading
just the Standard, I think a reasonable case can be made for
either point of view.  

Despite that, the conclusion James reaches agrees with what the
committee intended.  Support for this can be found in the Rationale
document (at the bottom of page 48 in the copy I have, V5.10).
I still believe though that the Standard by itself is not enough
to give an overwhelming argument either way;  otherwise why would
it need to be mentioned in the Rationale document?

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

#1769

On 12/20/2012 08:34, christian.bau wrote:
>
> Converting _any_ integer to _any_ pointer gives an implementation-
> defined result. "implementation defined" means it is defined. So the
> implementation must define what you get if you write "int x = 0; char*
> p = (char *) x; char* q = (char *) ++x; char* r = (char *) ++x;".
> There is also the requirement for the special case that an integer is,
> by chance, a null pointer constant, where the result must be a null
> pointer. So whatever definition the implementation gives, it must give
> a definition that converts 0 to a null pointer if the zero was a null
> pointer constant, therefore the definition must convert all zeroes to
> null pointers.
>

There's a jump here that I don't follow, just at the "therefore".  "So 
whatever V2 the IM gives, it must give V2 == NULL for V1 == NPC, 
therefore the IM must give V2 == NULL for V1 != NPC, also."

Since the implementation can _always_ distinguish between an NPC and a 
non-NPC, can't it satisfy the requirement without having non-NPC 0 
convert to a null pointer?  It'd seem rather useful to distinguish 
between the two, actually...

A debugger for x86 with BIOS could compare as unequal its own internal 
null pointers with a user-input-derived pointer to the Interrupt Vector 
Table.  (For example, and not that anyone does this.)

- Shao Miller

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

#1771

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:
> On Dec 18, 11:52 pm, Keith Thompson <ks...@mib.org> wrote:
>> The standard says that a constant arithmetic expression with the value
>> 0, converted to a pointer type, yields a null pointer.  It does *not*
>> say the same thing about a non-constant arithmetic expression with the
>> value 0.
>
> It doesn't have to. The standard doesn't have to state something
> explicitly if it follows from other rules that are stated.

I agree with that, but it doesn't apply here.

> Converting _any_ integer to _any_ pointer gives an implementation-
> defined result.

Right (except that the result of converting a constant arithmetic
expression with the value 0 to a pointer is not implementation-defined).

>                 "implementation defined" means it is defined. So the
> implementation must define what you get if you write "int x = 0; char*
> p = (char *) x; char* q = (char *) ++x; char* r = (char *) ++x;".

Right.  Of course that definition can be given in very general terms.

> There is also the requirement for the special case that an integer is,
> by chance, a null pointer constant, where the result must be a null
> pointer.

Right (though I'm not sure what the phrase "by chance" adds to this;
most programmers don't flip a coin to decide whether to use a null
pointer constant or not).

>          So whatever definition the implementation gives, it must give
> a definition that converts 0 to a null pointer if the zero was a null
> pointer constant,

Not really.  The conversion of a CAE with value 0 to a pointer is *not*
implementation-defined.  Look at N1570 6.3.2.3.  Paragraph 3 says:

    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.

This defines the terms "null pointer constant" and "null pointer".
(It's an incomplete definition of "null pointer", since there are ways
to obtain null pointers without using a null pointer constant, but
that's beside the point.)

And paragraph 5 says:

    An integer may be converted to any pointer type. Except as
    previously specified, the result is implementation-defined,
    [...]

So it's only integer-to-pointer conversions *other than* those
already defined in paragraph 3 (null pointer constants) that
are implementation-defined.  An implementation's documentation
needn't say anything about the result of converting a constant
0 to a pointer type; it's already implied by stating that it's a
conforming implementation.

>                   therefore the definition must convert all zeroes to
> null pointers.

This turns out not to be correct.  It's certainly very common that
converting a non-constant integer expression with value 0 to a
pointer type yields a null pointer, but it's not required.

Consider a hypothetical implementation with the following
characteristics:

    All pointer types have the same representation.

    A null pointer is represented as all-bits-one (not as the more
    common all-bits-zero).

    Except as specified by the definition of "null pointer constant",
    conversion of an integer value to a pointer type simply copies
    or reinterprets the bits of the integer's representation.
    (If the integer is smaller than a pointer, it's zero-extended;
    if it's larger, high-order bits are ignored.)

    For purposes of the following demonstration, printf's "%p"
    format produces the representation of the pointer in hexadecimal.

In this implementation, the following program:

    #include <stdio.h>
    
    static void show(char *name, void *p) {
        printf("%-15s = %p is %sa null pointer\n",
               name, p, p == NULL ? "" : "NOT ");
    }
    
    int main(void) {
        unsigned int zero = 0;
        unsigned int all_ones = -1;
        show("(void*)0", (void*)0);
        show("(void*)zero", (void*)zero);
        show("(void*)all_ones", (void*)all_ones);
        return 0;
    }

would produce this output:

    (void*)0        = 0xffffffff is a null pointer
    (void*)zero     = 0x00000000 is NOT a null pointer
    (void*)all_ones = 0xffffffff is a null pointer

How would this implementation violate the C standard?

The point of controversy is whether an integer-to-pointer conversion
for a constant 0 is required to yield the same result as a conversion
for a non-constant 0.  I assert that it isn't.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#1777

Keith Thompson <kst-u@mib.org> writes:

> "christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:
>> On Dec 18, 11:52 pm, Keith Thompson <ks...@mib.org> wrote:
>>> The standard says that a constant arithmetic expression with the value
>>> 0, converted to a pointer type, yields a null pointer.  It does *not*
>>> say the same thing about a non-constant arithmetic expression with the
>>> value 0.
>>
>> It doesn't have to. The standard doesn't have to state something
>> explicitly if it follows from other rules that are stated.
>
> I agree with that, but it doesn't apply here.
>
>> Converting _any_ integer to _any_ pointer gives an implementation-
>> defined result.
>
> Right (except that the result of converting a constant arithmetic
> expression with the value 0 to a pointer is not implementation-defined).
>
>>                 "implementation defined" means it is defined. So the
>> implementation must define what you get if you write "int x = 0; char*
>> p = (char *) x; char* q = (char *) ++x; char* r = (char *) ++x;".
>
> Right.  Of course that definition can be given in very general terms.
>
>> There is also the requirement for the special case that an integer is,
>> by chance, a null pointer constant, where the result must be a null
>> pointer.
>
> Right (though I'm not sure what the phrase "by chance" adds to this;
> most programmers don't flip a coin to decide whether to use a null
> pointer constant or not).
>
>>          So whatever definition the implementation gives, it must give
>> a definition that converts 0 to a null pointer if the zero was a null
>> pointer constant,
>
> Not really.  The conversion of a CAE with value 0 to a pointer is *not*
> implementation-defined.  Look at N1570 6.3.2.3.  Paragraph 3 says:
>
>     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.
>
> This defines the terms "null pointer constant" and "null pointer".
> (It's an incomplete definition of "null pointer", since there are ways
> to obtain null pointers without using a null pointer constant, but
> that's beside the point.)
>
> And paragraph 5 says:
>
>     An integer may be converted to any pointer type. Except as
>     previously specified, the result is implementation-defined,
>     [...]
>
> So it's only integer-to-pointer conversions *other than* those
> already defined in paragraph 3 (null pointer constants) that
> are implementation-defined.  [snip elaboration]

The question is whether the case previously covered implies a
conversion for the value zero.  IMO that quesstion can be argued
either way, ie, the Standard is not clear enough.  I agree with
your conclusion as to intent, because of a statement found in the
Rationale document, but I don't think an airtight argument can be
made based just on the text in the Standard.  Furthermore the
conclusion, even if it does reflect the intent of the committee,
is unexpected and counter-intuitive;  surely it is a deficiency
of the Standard that such a circumstance exists without any
overt mention, and that deficiency deserves acknowledging -- we
are, after all, discussing the point in comp.std.c.

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

#1747

On 12/18/2012 08:25, Szabolcs Nagy wrote:
>
> but it seems
>
>   0 ? (void*)0 : (void*)0
>
> is not a null pointer constant, nor an address constant
>
> it is mildly unexpected that this cannot be used as a
> null pointer constant
> (this matters when determining the type of ?: (6.5.15)
> expressions, assigning it to function pointers (6.5.16.1)
> or comparing it to function pointers (6.5.9))
>

It seems more useful as a "constant null pointer" than as a "null 
pointer constant," which is trivial.  This construct seems to allow you 
to sneak out of NPC semantics if desired, while still using a null 
pointer value, a 'void *' type, and no identifiable objects.

To follow your notes:

   x ? ptr : CNP

now has type 'void *' instead of the type of 'ptr',

   funcptr = CNP

contrasts a function type with an incomplete object type, and so do

   funcptr == CNP
   funcptr != CNP

> but (for me at least) it's more surprising that this is
> not even a constant expression that can be used in
> initializers, ie.
>
>   void *p = 0?(void*)0:(void*)0;
>

Why not?  6.6p7 says an initializer can evaluate to an address constant. 
  6.6p9 says an address constant can be a null pointer.  Your ternary 
yields one or the other of two such address constants that were created 
by a cast of a null pointer constant.  Could you point out what I've missed?

> another similar surprising case is
>
>   void *q = (void*)((char*)1 - (char*)1);
>

This doesn't surprise me.  The most portable code cannot assume that 
'(char *) 1' means anything.  I would not expect an implementation to 
deal with anything other than null pointer values and the addresses of 
actual functions and objects, at translation-time.  In the code you've 
shared, it bounces out of the realm of portability temporarily with the 
hope of returning to it, but I don't think it can be so.

- Shao Miller

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

#1749

Shao Miller <sha0.miller@gmail.com> wrote:
> On 12/18/2012 08:25, Szabolcs Nagy wrote:
>> but (for me at least) it's more surprising that this is
>> not even a constant expression that can be used in
>> initializers, ie.
>>
>>   void *p = 0?(void*)0:(void*)0;
>>
> 
> Why not?  6.6p7 says an initializer can evaluate to an address constant. 
>  6.6p9 says an address constant can be a null pointer.  Your ternary 

you are rigth, thanks

i was wrong about initializers

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

#1751

On 12/18/2012 03:09 PM, Szabolcs Nagy wrote:
> Shao Miller <sha0.miller@gmail.com> wrote:
>> On 12/18/2012 08:25, Szabolcs Nagy wrote:
>>> but (for me at least) it's more surprising that this is
>>> not even a constant expression that can be used in
>>> initializers, ie.
>>>
>>>   void *p = 0?(void*)0:(void*)0;
>>>
>>
>> Why not?  6.6p7 says an initializer can evaluate to an address constant. 
>>  6.6p9 says an address constant can be a null pointer.  Your ternary 
> 
> you are rigth, thanks
> 
> i was wrong about initializers

"An address constant ... shall be created explicitly using
the unary & operator or an integer constant cast to pointer type, or
implicitly by the use of an expression of array or function type."
(6.6p9). (void*)0 fits the second option, so that expression contains
two address constants as sub-expressions, but the ?: expression itself
doesn't fit any of the three options.

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

#1753

On 12/18/2012 15:54, James Kuyper wrote:
> On 12/18/2012 03:09 PM, Szabolcs Nagy wrote:
>> Shao Miller <sha0.miller@gmail.com> wrote:
>>> On 12/18/2012 08:25, Szabolcs Nagy wrote:
>>>> but (for me at least) it's more surprising that this is
>>>> not even a constant expression that can be used in
>>>> initializers, ie.
>>>>
>>>>    void *p = 0?(void*)0:(void*)0;
>>>>
>>>
>>> Why not?  6.6p7 says an initializer can evaluate to an address constant.
>>>   6.6p9 says an address constant can be a null pointer.  Your ternary
>>
>> you are rigth, thanks
>>
>> i was wrong about initializers
>
> "An address constant ... shall be created explicitly using
> the unary & operator or an integer constant cast to pointer type, or
> implicitly by the use of an expression of array or function type."
> (6.6p9). (void*)0 fits the second option, so that expression contains
> two address constants as sub-expressions, but the ?: expression itself
> doesn't fit any of the three options.
>

If you'd unplonk me, I might suggest that you review the second sentence 
of p7, as well as the syntax in p1.  Perhaps someone else can suggest it.

- Shao Miller

[toc] | [prev] | [standalone]

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

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

csiph-web