From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: Lawrence Kirby Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/09/03 Message-ID: <841794239snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 178331275 x-nntp-posting-host: genesis.demon.co.uk references: <31FBC584.4188@ivic.qc.ca> <4vroh3$17f@goanna.cs.rmit.edu.au> <50650h$rek@goanna.cs.rmit.edu.au> <506v0c$ne8@solutions.solon.com> x-mail2news-path: genesis.demon.co.uk organization: none reply-to: fred@genesis.demon.co.uk newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-09-03T00:00:00+00:00 List-Id: In article <506v0c$ne8@solutions.solon.com> seebs@solon.com "Peter Seebach" writes: ... >There's a possible weakness. Assume sig_atomic_t is an int. Assume we >have an array of sig_atomic_t somewhere. Assume we decide to, as we >are permitted by the standard, treat it as an array of characters. The >first sig_atomic_t in the array may be overwritten by a signal handler >we have installed. We make sure the 2nd s_a_t in the array contains at least >one null byte, so strlen((char *) sat_array) will be zero, and pass >the array to dupcat as both a and b. (Suitably cast to (char *).) > >It is entirely possible that, even though a and b are the same pointer, >that a signal handler will change the NTBS they point to between a >strlen(a) and a strlen(b) in the above, or between statements. However the compiler doesn't have to worry about this. If you access a volatile object through a non-volatile lvalue you get undefined behaviour (6.5.3). Since signal handlers can only access static variables of type volatile sig_atomic_t and strlen does not treat the character array as volatile the compiler doesn't have to make the strlen code signal safe. Consider the situation where the signal handler changed the string while strlen was running, it could easily miss the null character terminator completely. This is simply not a sensible thing for code to do. >The problem is unique to (char *), which may point to things other than >arrays of characters, because you may treat any object as an array of >characters. That is certainly a general aliasing problem. On the other hand it may be that a lot of those situations can't occur in strictly conforming programs so, again, the compiler is not obliged to deal with them to be conforming, although the compiler writer may not want the trouble of convincing irate customers about this. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------