nevin1@ihlpb.ATT.COM (Liber) (01/04/89)
[followups to comp.std.c] In article <15171@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <15166@mimsy.UUCP> I suggested that >... ["register"] implies not-volatile and not-aliased; and it does so >in a way that the compiler can reasonably enforce. >You mean to say that a register could be aliased? Not in C! This seems to be very similar to the argument about const. You mean to say that a (non-volatile) const-qualified object could be modified? Not in C! >How about a volatile register? I can ask the same question about volatile const. All the volatile register means is that the alias to the variable cannot occur within the conforming C program. [Side note: I was skimming through the dpANS C, and the only place I could find restricting register to being non-aliased is in footnote #55, section 3.5.1. Since footnotes aren't an official part of the Standard, could someone please email me an official reference to this? If it is not official, then I am asking why not?] >It is a possibility, but it seems entirely unnecessary. I agree that I don't see this as being particularly useful; that doesn't make it illegal, however. >>A STORAGE CLASS by no means obviates the need for type qualifiers. >I did not say that. I said `register implies not-volatile, not- >aliased': that `volatile register' and `aliased register' are >nonsensical combinations. Register only implies non-aliased when not qualified by volatile, in much the same way that const implies non-modifiable when not qualified by volatile. Register is allowed to be aliased by hardware or by a different thread of execution, but a conforming C program cannot alias it. [Another side note: is it even possible to have a strictly conforming C program whose behavior would change by declaring any of its variables volatile? I cannot think of any examples without having to escape to having some library routines around that 'cheat'.] -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751