casts and lvalues

Discussion in 'C Programming' started by jacob navia, Jun 24, 2007.

  1. jacob navia

    jacob navia Guest

    Continuing the discussion about casts, I would like to know
    your opinions about the hairy subject of casts as lvalues, i.e.

    > int main(void)
    > {
    > long long a;
    > char *n;
    >
    > (char *)a = n;
    > }


    This will fail under lcc-win32, but MSVC and gcc will
    accept it. I know that the standard prescribes the behavior
    that lcc-win32 uses, but I left that behavior after a big
    discussion about this several years ago. I had modified it,
    and some people raised hell.

    What are the problems of doing this? I mean not the usual
    "the standard says so" but what problems would arise within the
    language if this would be accepted?

    Apparently gcc and msvc are still used, and this doesn't seem
    to produce any big problems.

    Thanks in advance for your comments, and I thank all people
    that participated in the discussion yesterday.

    jacob
     
    jacob navia, Jun 24, 2007
    #1
    1. Advertising

  2. jacob navia wrote:
    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues, i.e.
    > [...]
    > What are the problems of doing this? I mean not the usual
    > "the standard says so" but what problems would arise within the
    > language if this would be accepted?


    int a = 1;
    void f(double *d) {
    if (a == 1) *d = 2;
    if (a == 2) *d = 0;
    }
    int main(void) {
    f(&(double) a);
    return a;
    }

    What would this program return?
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jun 24, 2007
    #2
    1. Advertising

  3. jacob navia said:

    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues


    It isn't a matter of opinion. They're not legal C. A cast yields a
    value, but not an lvalue.

    <snip>

    > What are the problems of doing this?


    It doesn't compile.

    > I mean not the usual
    > "the standard says so" but what problems would arise within the
    > language if this would be accepted?


    Implementors jumped at C89 like a pack of starving stoats on a squirrel.
    But they have stayed away from C99 in droves. I don't see them suddenly
    all agreeing to support a particular extension, all with the same
    syntax and semantics. So the fundamental problem would be that your
    proposal wouldn't be accepted.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jun 24, 2007
    #3
  4. jacob navia

    Joe Wright Guest

    Harald van Dijk wrote:
    > jacob navia wrote:
    >> Continuing the discussion about casts, I would like to know
    >> your opinions about the hairy subject of casts as lvalues, i.e.
    >> [...]
    >> What are the problems of doing this? I mean not the usual
    >> "the standard says so" but what problems would arise within the
    >> language if this would be accepted?

    >
    > int a = 1;
    > void f(double *d) {
    > if (a == 1) *d = 2;
    > if (a == 2) *d = 0;
    > }
    > int main(void) {
    > f(&(double) a);
    > return a;
    > }
    >
    > What would this program return?


    It doesn't compile here. You seem to want to pretend a is a double.

    f((double*)&a);

    will at least compile.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, Jun 24, 2007
    #4
  5. jacob navia

    jacob navia Guest

    Richard Heathfield wrote:
    > jacob navia said:
    >
    >> Continuing the discussion about casts, I would like to know
    >> your opinions about the hairy subject of casts as lvalues

    >
    > It isn't a matter of opinion. They're not legal C. A cast yields a
    > value, but not an lvalue.
    >
    > <snip>
    >
    >> What are the problems of doing this?

    >
    > It doesn't compile.
    >
    >> I mean not the usual
    >> "the standard says so" but what problems would arise within the
    >> language if this would be accepted?

    >
    > Implementors jumped at C89 like a pack of starving stoats on a squirrel.
    > But they have stayed away from C99 in droves. I don't see them suddenly
    > all agreeing to support a particular extension, all with the same
    > syntax and semantics. So the fundamental problem would be that your
    > proposal wouldn't be accepted.
    >


    But this is just politics. I do not want to do any proposal nor do
    I want to modify anything. I just want to know what TECHNICAL problems
    could arise if that extension (that is provided at least by the
    compilers I mentioned) would be part of the language.

    Why are casts not lvalues? What TECHNICAL reasons exist for that?
    That is my question.
     
    jacob navia, Jun 24, 2007
    #5
  6. In article <467ec2c7$0$5075$>,

    >> int main(void)
    >> {
    >> long long a;
    >> char *n;
    >>
    >> (char *)a = n;
    >> }


    >This will fail under lcc-win32, but MSVC and gcc will
    >accept it.


    Gcc has, I think, always warned about this if you give enough flags,
    and seems to reject it by default in recent versions.

    >What are the problems of doing this? I mean not the usual
    >"the standard says so" but what problems would arise within the
    >language if this would be accepted?


    So long as you can specifiy exactly what it means, there would be no
    problem adding it to the language. Of course, once you've specified
    exactly what it means it's easy enough to manage without it.

    I've always thought its use in implementing a "program counter"
    variable was reasonable, where a generic pointer is cast to various
    types and incremented by the same amount, e.g.

    op = *((operator *)pc)++;
    switch(op)
    {
    ...
    case ADD:
    arg1 = *((int *)pc)++;
    arg2 = *((int *)pc)++;
    whatever = arg1 + arg2;
    ...

    But those writing this style of code can easily enough work around it.

    >Apparently gcc and msvc are still used, and this doesn't seem
    >to produce any big problems.


    Apparently gcc's implementors see sufficient problems to not accept it
    by default, but those problems may just be compatibility ones.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Jun 24, 2007
    #6
  7. On Sun, 24 Jun 2007 23:20:03 +0200, in comp.lang.c , jacob navia
    <> wrote:

    (of
    long long a;
    char *n;

    (char *)a = n;
    )

    >Why are casts not lvalues? What TECHNICAL reasons exist for that?
    >That is my question.


    Because its meaningless in my view. What exactly does the above do?

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Jun 24, 2007
    #7
  8. jacob navia

    jacob navia Guest

    Mark McIntyre wrote:
    > On Sun, 24 Jun 2007 23:20:03 +0200, in comp.lang.c , jacob navia
    > <> wrote:
    >
    > (of
    > long long a;
    > char *n;
    >
    > (char *)a = n;
    > )
    >
    >> Why are casts not lvalues? What TECHNICAL reasons exist for that?
    >> That is my question.

    >
    > Because its meaningless in my view. What exactly does the above do?
    >

    Moves the contents of n (an address) into the memory locations of a,
    that can hold a pointer is sizeof(void *) <= sizeof(long long);

    I am not saying that this is nice/the best thing since sliced bread
    but that is what it does.
     
    jacob navia, Jun 24, 2007
    #8
  9. jacob navia <> writes:
    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues, i.e.
    >
    >> int main(void)
    >> {
    >> long long a;
    >> char *n;
    >> (char *)a = n;
    >> }

    >
    > This will fail under lcc-win32, but MSVC and gcc will
    > accept it. I know that the standard prescribes the behavior
    > that lcc-win32 uses, but I left that behavior after a big
    > discussion about this several years ago. I had modified it,
    > and some people raised hell.
    >
    > What are the problems of doing this? I mean not the usual
    > "the standard says so" but what problems would arise within the
    > language if this would be accepted?

    [...]

    This extension doesn't seem to me to be particularly useful. The
    above would be more clearly written as:

    long long a;
    char *n;
    a = (long long)n;

    Another problem with this, as with any extension, is that it
    encourages programmers to write non-portable code that depends on it.

    --
    Keith Thompson (The_Other_Keith) <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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 24, 2007
    #9
  10. In article <>,
    Mark McIntyre <> wrote:

    > long long a;
    > char *n;
    >
    > (char *)a = n;


    >>Why are casts not lvalues? What TECHNICAL reasons exist for that?
    >>That is my question.


    >Because its meaningless in my view.


    C constructs are no natural phenomena. They are meaningful if people
    assign meaning to them. And several compilers *have* assigned meaning
    to casts as lvalues,

    >What exactly does the above do?


    I believe that it's intended to be equivalent to "a = (long long)n'.
    As such, it's not very useful. Some more complicated uses are more
    obviously useful, as I've noted elsewhere.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Jun 24, 2007
    #10
  11. jacob navia

    jacob navia Guest

    Keith Thompson wrote:
    > jacob navia <> writes:
    >> Continuing the discussion about casts, I would like to know
    >> your opinions about the hairy subject of casts as lvalues, i.e.
    >>
    >>> int main(void)
    >>> {
    >>> long long a;
    >>> char *n;
    >>> (char *)a = n;
    >>> }

    >> This will fail under lcc-win32, but MSVC and gcc will
    >> accept it. I know that the standard prescribes the behavior
    >> that lcc-win32 uses, but I left that behavior after a big
    >> discussion about this several years ago. I had modified it,
    >> and some people raised hell.
    >>
    >> What are the problems of doing this? I mean not the usual
    >> "the standard says so" but what problems would arise within the
    >> language if this would be accepted?

    > [...]
    >
    > This extension doesn't seem to me to be particularly useful. The
    > above would be more clearly written as:
    >
    > long long a;
    > char *n;
    > a = (long long)n;
    >


    Granted.

    It is clearer but the question is not if this is pleasing but if there
    would be any problems (in the sense of contradictions or buggy language
    specifications) if casts could be lvalues.

    > Another problem with this, as with any extension, is that it
    > encourages programmers to write non-portable code that depends on it.
    >


    Yes, of course. lcc-win32 doesn't even support this extension. But
    if I would add support for it, are there any TECHNICAL drawbacks?
    I mean, if somebody asks me to support overloading addition
    with

    int operator+(struct FOO *a,int b);

    I would say NO that can't be done because addition of a pointer and
    an integer is already used in the language to access the nth element
    using a pointer as base, i.e.
    struct FOO *p;
    p + 6
    addresses the sixth element after the element pointed by p. If I would
    implement such an extension I would introduce an ambiguity in the
    language.

    Is that the case with casts as lvalues?
     
    jacob navia, Jun 24, 2007
    #11
  12. jacob navia

    Chris Torek Guest

    [from article <467ec2c7$0$5075$>: gcc accepts:]
    >>> int main(void)
    >>> {
    >>> long long a;
    >>> char *n;
    >>>
    >>> (char *)a = n;
    >>> }


    In article <f5mnub$2cic$>
    Richard Tobin <> wrote:
    >Gcc has, I think, always warned about this if you give enough flags,


    Indeed.

    >and seems to reject it by default in recent versions.


    Yes. This illustrates one of the dangers of relying on compiler
    extensions: the compiler-writer may eventually realize the folly
    of that particular extension, and remove it. (The extension, not
    the folly. :) )

    GCC's old definition of (cast)obj = expr was:

    ((cast)(obj = (T)(expr)))

    where T is the type of the object "obj", -- so the code above, with
    "a" being "long long", really "meant":

    (char *)(a = (long long)n);

    Many programmers seemed to have expected it to mean:

    *(char *)&a = n;

    which, on a typical 32-bit-pointer, 64-bit-"long long" machine,
    sets just half of the object "a", leaving the other half unmodified.
    GCC's old interpretation sets all 64 bits. The overly-clever
    programmer, believing it set only 32 bits, set the other 32 bits
    to something useful first, and then was surprised when those bits
    were clobbered.

    (If you use Standard C to write "what you mean", you will not be
    surprised by whatever bizarre interpretation some compiler-writer
    uses for his or her particular extension.)

    >I've always thought its use in implementing a "program counter"
    >variable was reasonable, where a generic pointer is cast to various
    >types and incremented by the same amount, e.g.
    >
    > op = *((operator *)pc)++;
    > switch(op)
    > {
    > ...
    > case ADD:
    > arg1 = *((int *)pc)++;
    > arg2 = *((int *)pc)++;
    > whatever = arg1 + arg2;
    > ...
    >
    >But those writing this style of code can easily enough work around it.


    Yes -- and, assuming "void *pc" for the above and that "operator" is
    a typedef-name for a type smaller than plain "int", the above tends
    to malfunction on various machines. So it might not be the best
    way to write the code, even with the more verbose workaround:

    op = *(operator *)pc, pc = (unsigned char *)pc + sizeof(operator);
    switch (op)
    {
    ...
    case ADD:
    arg1 = *(int *)pc, pc = (unsigned char *)pc + sizeof(int);
    arg2 = *(int *)pc, pc = (unsigned char *)pc + sizeof(int);
    whatever = arg1 + arg2;

    where the comma-expression versions above might be hidden behind
    a macro and then modified a bit:

    #define FETCH(ty, pc) \
    (pc = (unsigned char *)(pc) + sizeof(ty), ((ty *)pc)[-1])

    Note: giving "pc" type "unsigned char *" simplifies this even
    further:

    #define FETCH(ty, pc) (((ty *)(pc += sizeof(ty)))[-1])

    switch (FETCH(operator, pc)) {
    ...
    case ADD:
    arg1 = FETCH(int, pc);
    whatever = arg1 + FETCH(int, pc);
    ...

    The alignment trap remains, however: for this to work in general,
    the pointer must remain aligned for each type "ty". The simplest
    way to guarantee such alignment is to use just a single type, in
    this case, "int". If "pc" is always going to refer to "int"s, we
    can remove the FETCH macro's "ty" argument, change "pc" to "int
    *", and simply use *pc++ -- and thus remove all need for the FETCH
    macro itself.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jun 24, 2007
    #12
  13. jacob navia <> writes:
    > Richard Heathfield wrote:
    >> jacob navia said:
    >>
    >>> Continuing the discussion about casts, I would like to know
    >>> your opinions about the hairy subject of casts as lvalues

    >> It isn't a matter of opinion. They're not legal C. A cast yields a
    >> value, but not an lvalue.
    >> <snip>
    >>
    >>> What are the problems of doing this?

    >> It doesn't compile.
    >>
    >>> I mean not the usual
    >>> "the standard says so" but what problems would arise within the
    >>> language if this would be accepted?

    >> Implementors jumped at C89 like a pack of starving stoats on a
    >> squirrel. But they have stayed away from C99 in droves. I don't see
    >> them suddenly all agreeing to support a particular extension, all
    >> with the same syntax and semantics. So the fundamental problem would
    >> be that your proposal wouldn't be accepted.

    >
    > But this is just politics. I do not want to do any proposal nor do
    > I want to modify anything. I just want to know what TECHNICAL problems
    > could arise if that extension (that is provided at least by the
    > compilers I mentioned) would be part of the language.
    >
    > Why are casts not lvalues? What TECHNICAL reasons exist for that?
    > That is my question.


    Why *should* casts be lvalues?

    For any proposed addition to the language, the burden is on its
    advocates to demonstrate that its advantages outweigh the costs of
    updating the standard *and* of updating every implementation to
    support it.

    The main technical problem, in my opinion, is the difficulty of
    defining the semantics in all possible cases, something that must be
    done if this is to become a language feature. I see no particular
    advantage that outweighs this difficulty; I know of no use of
    cast-as-lvalue that can't be written equivalently in legal C.

    A cast specifies a conversion of a given value (the result of
    evaluating an expression) to a specified type. That's relatively
    simple to describe and to understand. Allowing casts as lvalues would
    require a much more complex model of what casts mean.

    I presume you're proposing that a cast would be an lvalue only if the
    operand is itself an lvalue. That's just one of the many details that
    must be specified before any such proposal can be taken seriously.

    Even if such a feature were added to a future version of the standard,
    there's a real risk that some obscure corner case could be neglected,
    leading to a flaw in the standard. In two attempts a decade apart,
    the commitee hasn't even managed to come up with a coherent definition
    of the word "lvalue".

    --
    Keith Thompson (The_Other_Keith) <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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 24, 2007
    #13
  14. jacob navia

    Old Wolf Guest

    On Jun 25, 8:54 am, Joe Wright <> wrote:
    > Harald van Dijk wrote:
    > > jacob navia wrote:
    > >> Continuing the discussion about casts, I would like to know
    > >> your opinions about the hairy subject of casts as lvalues, i.e.
    > >> [...]
    > >> What are the problems of doing this? I mean not the usual
    > >> "the standard says so" but what problems would arise within the
    > >> language if this would be accepted?

    >
    > > int a = 1;
    > > void f(double *d) {
    > > if (a == 1) *d = 2;
    > > if (a == 2) *d = 0;
    > > }
    > > int main(void) {
    > > f(&(double) a);
    > > return a;
    > > }

    >
    > > What would this program return?

    >
    > It doesn't compile here. You seem to want to pretend a is a double.


    Did you read the text you quoted? The point of
    this thread is to ask what problems would occur
    if the above code were made legal.
     
    Old Wolf, Jun 25, 2007
    #14
  15. jacob navia

    pete Guest

    jacob navia wrote:
    >
    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues, i.e.


    I don't like it because the semantics are srewed up.
    An lvalue converted to a different type,
    refers to memory that was never reserved.

    --
    pete
     
    pete, Jun 25, 2007
    #15
  16. jacob navia

    CBFalconer Guest

    jacob navia wrote:
    >
    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues, i.e.
    >
    >> int main(void) {
    >> long long a;
    >> char *n;
    >>
    >> (char *)a = n;
    >> }

    >
    > This will fail under lcc-win32, but MSVC and gcc will
    > accept it. I know that the standard prescribes the behavior
    > that lcc-win32 uses, but I left that behavior after a big
    > discussion about this several years ago. I had modified it,
    > and some people raised hell.


    Don't know about MSVC, but gcc (later versions) will also reject
    this. A cast cannot be a lvalue. Also you have the types
    confused.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 25, 2007
    #16
  17. jacob navia

    CBFalconer Guest

    jacob navia wrote:
    >

    .... snip ...
    >
    > Why are casts not lvalues? What TECHNICAL reasons exist for that?
    > That is my question.


    A cast requires a destination (i.e. a lvalue) to receive the
    converted object. Without a destination, such does not exist.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 25, 2007
    #17
  18. CBFalconer said:

    > jacob navia wrote:
    >>

    > ... snip ...
    >>
    >> Why are casts not lvalues? What TECHNICAL reasons exist for that?
    >> That is my question.

    >
    > A cast requires a destination (i.e. a lvalue) to receive the
    > converted object.


    No, it doesn't. No object is converted by a cast, and casts do not
    *require* lvalues to receive their results. For example, there is no
    lvalue in the (pointless but legal) statement:

    toupper((unsigned char)c);

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jun 25, 2007
    #18
  19. jacob navia

    Jack Klein Guest

    On Sun, 24 Jun 2007 21:13:40 +0200, jacob navia
    <> wrote in comp.lang.c:

    > Continuing the discussion about casts, I would like to know
    > your opinions about the hairy subject of casts as lvalues, i.e.
    >
    > > int main(void)
    > > {
    > > long long a;
    > > char *n;
    > >
    > > (char *)a = n;
    > > }

    >
    > This will fail under lcc-win32, but MSVC and gcc will
    > accept it. I know that the standard prescribes the behavior
    > that lcc-win32 uses, but I left that behavior after a big
    > discussion about this several years ago. I had modified it,
    > and some people raised hell.


    I just tried this with Visual Studio 2005 Express, and indeed you have
    to set the warning level to maximum (/W4) to even get it to issue a
    misleadingly incorrectly worded error massage:

    "warning C4213: nonstandard extension used : cast on l-value"

    ....but it still produces a 32-bit executable. When I initialize a to
    a value and n to NULL, it sets the low 32 bits of a to its
    representation of a NULL pointer (0), and leaves the high 32 bits
    unchanged.

    The only version of gcc that I have installed at the moment is 3.4.2,
    (mingw), and it gives me these two diagnostics:

    "warning: cast to pointer from integer of different size"
    "warning: use of cast expressions as lvalues is deprecated"

    > What are the problems of doing this? I mean not the usual
    > "the standard says so" but what problems would arise within the
    > language if this would be accepted?


    What do you do with:

    (char *)(3LL + 5LL) = n;

    ....???

    > Apparently gcc and msvc are still used, and this doesn't seem
    > to produce any big problems.


    Well, actually it does produce the big problem of continuing to allow
    programmers to write incorrect and quite possibly unsafe code. What
    happens when they cast a value with a narrower representation to one
    with a wider representation?

    > Thanks in advance for your comments, and I thank all people
    > that participated in the discussion yesterday.


    Personally, I'm against this. If the cast is to a type with more bits
    than the original, you risk overwriting memory incorrectly, with all
    of the defect and security issues that involves. If the cast is to a
    type with more bits than the original, you risk creating an invalid
    trap value in the object.

    And, of course, if somebody really needs to do this, or at least
    thinks that they do, it is perfectly legal to write:

    *(char *)(&a) = n;

    This is hideously ugly and stands out like a sore thumb, as well it
    should.

    If you start down this path, you open a can of worms that means you
    need to scrutinize all operators that currently yield (r)values rather
    than lvalues. Where and why do you stop?

    Given:

    void func(int *ip);

    What should happen with:

    int x = 3;
    func(&(x + 2));

    You could indeed do this, at the expense of turning C into BASIC (or
    other languages), that will construct a temporary object for you.

    I just don't think the gain is worth the change, especially since
    there is a valid way to write a statement that does the same thing.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jun 25, 2007
    #19
  20. On Mon, 25 Jun 2007 00:17:39 +0200, in comp.lang.c , jacob navia
    <> wrote:

    >Mark McIntyre wrote:
    >> On Sun, 24 Jun 2007 23:20:03 +0200, in comp.lang.c , jacob navia
    >> <> wrote:
    >>
    >> (of
    >> long long a;
    >> char *n;
    >>
    >> (char *)a = n;
    >> )
    >>
    >>> Why are casts not lvalues? What TECHNICAL reasons exist for that?
    >>> That is my question.

    >>
    >> Because its meaningless in my view. What exactly does the above do?
    >>

    >Moves the contents of n (an address) into the memory locations of a,


    with you so far...

    >that can hold a pointer is sizeof(void *) <= sizeof(long long);


    .... but not here.
    The value of n is assigned to a. Ok. If n is larger than *a, there's a
    memory overwrite. How does this 'cast' help with this???

    >I am not saying that this is nice/the best thing since sliced bread
    >but that is what it does.


    I probably misunderstand, because to me the above is gibberish.
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Jun 25, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mantorok Redgormor

    lvalues -> incomplete types

    Mantorok Redgormor, Feb 6, 2004, in forum: C Programming
    Replies:
    7
    Views:
    441
  2. Replies:
    23
    Views:
    1,463
    Skarmander
    Sep 21, 2006
  3. Lvalues and Rvalues

    , Oct 14, 2006, in forum: C Programming
    Replies:
    3
    Views:
    369
    SM Ryan
    Oct 14, 2006
  4. Nicklas Karlsson

    lvalues and rvalues

    Nicklas Karlsson, Apr 6, 2010, in forum: C Programming
    Replies:
    127
    Views:
    2,715
    Tim Rentsch
    May 5, 2010
  5. BartC

    Casts on lvalues

    BartC, Dec 2, 2012, in forum: C Programming
    Replies:
    74
    Views:
    1,050
Loading...

Share This Page